I am cloning the production database to another one, lets say CLONEDB, in a regular basis. I am using rman duplicate database script like:

run {
duplicate target database to CLONEDB
SET ....
  GROUP 1 (
  ) SIZE 100M,

Before running the script I am doing an archivelog rman backup of the CLONEDB (it deletes backed up archivelogs) and DROP DATABASE CLONEDB.

While running duplicate database, rman copies datafiles and archivelogs from the source database. For example, I can see that such file has been copied:

input archived log thread=1 sequence=666 ...
output file name=+DYSK/archivelog/2015_01_16/thread_1_seq_666
channel ORA_DISK_1: archived log copy complete, elapsed time: 00:00:01

Then rman recovers database (via set until scn 666666; recover clone database delete archivelog;), so the archivelog above is applied to the database:

starting media recovery
archived log for thread 1 with sequence 666 is already on disk as file +DYSK/archivelog/2015_01_16/thread_1_seq_666
archived log file name=+DYSK/archivelog/2015_01_16/thread_1_seq_666 thread=1 sequence=666
media recovery complete, elapsed time: 00:00:02
Finished recover at 2015.01.16 16:21:57
Oracle instance started

Everything is OK, database starts up, users are happy. But the archivelog file (in this example thread_1_seq_666) stays on the disk. And because rman changes the database incarnation after duplicate process, this file is never deleted during the backup process, as it belogns to the previous incarnation.

So from time to time I must do the housekeeping and delete old, orphaned archivelogs directly from the disk. Of course I would like to do it automatically, with the duplication script. I could add rm command from asmcmd for the old files, but maybe there is a way to convince rman to do it for me during the duplicate database?

  • 1
    After cloning, on the copy database, you can do as is described here : community.oracle.com/thread/2323257 . Any archived log redo file that remains in the archived redo log directory, can then safely be removed. Maybe the DUPLICATE command itself can not include, but if you run a { } script anyway, the RMAN commands can be added easily.
    – tvCa
    Commented Jan 28, 2015 at 15:57
  • It won't work, because 1) the incarnation of the database changed and 2) the archive logs are from the source database, so there is an error "Reason: Foreign database file DBID: 3602082828 Database Name: SOURCESID"
    – Grych
    Commented Jan 28, 2015 at 16:04

2 Answers 2


The duplicate database ... from active database is designed to work without any existing backup. I would expect Oracle to clean up the archivelogs which were used during the clone process.

So I would say this is an unexpected behavior. Try to log a Service Request at Oracle.

I cannot recall if I had to clean up archivelogs after a clone processes. Well, I can say that I never did delete archivelogs after a db clone because I did not check for any. I rarely clone from active database. I normally clone from backup location without a connection to the primary database. I somehow prefer that.

As workaround I would delete them with a script afterwards.

  • 1
    I already made a SR at Oracle, I will share the results if they find it.
    – Grych
    Commented Jan 28, 2015 at 17:00
  • The Oracle answer was: "we reproduced the issue, but we can't do anything before you upgrade to the latest patchset". I am going to script the deletion of orphaned archive logs
    – Grych
    Commented Feb 3, 2015 at 12:39
  • hmm not very helpful. This leaves a lot space to speculate if the problem is fixed in the latest version. I'll keep it in mind when I clone a 12c next time.
    – o0x258
    Commented Feb 11, 2015 at 11:04

Try increasing the value of control_file_record_keep_time. You can also try deleting the archive logs and backups with force before dropping the database.

SQL> show parameter control_file_record_keep_time

NAME                             TYPE      VALUE
-------------------------------- --------- ------
control_file_record_keep_time    integer   7

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.