Block Change Tracking and Duplicate: avoid ORA-19755

If you use Block Change Tracking on your production database and try to duplicate it, you there are good possibilities that you will encounter this error:

The problem is caused by the block change tracking file entry that exists in the target controlfile, but Oracle can’t find the file because the directory structure on the auxiliary server changes.

After the restore and recovery of the auxiliary database, the duplicate process tries to open the DB but the bct file doesn’t exist and the error is thrown.

If you do a quick google search you will find several workarounds:

  • disable the block change tracking after you get the error and manually open the auxiliary instance (this prevent the possibility to get the duplicate outcome from the rman return code)
  • disable the BCT on the target before running the duplicate (this forces your incremental backups to read all your target database!)
  • Richard Harrison proposed another workaround, you can read more about it here.

There is another workaround that I like more (and that you can also find as comment in Richard’s post):

  • Disable the Block Change Tracking on the auxiliary while it’s doing the restore/recovery (in mounted status)

(This solutions isn’t coming from me, but as far as I know, the father of this solution is a colleague working at Trivadis.)

You can easily fork a process before running the duplicate command that:

  • loops and checks the auxiliary instance status
  • run the disable as soon as the auxiliary is mounted

I’ve worked out this script that does the job:

Run it  just before the duplicate! e.g.



The following two tabs change content below.


Principal Product Manager at Oracle
Ludovico is a member of the Oracle Database High Availability (HA), Scalability & Maximum Availability Architecture (MAA) Product Management team in Oracle. He focuses on Oracle Data Guard, Flashback technologies, and Cloud MAA.

11 thoughts on “Block Change Tracking and Duplicate: avoid ORA-19755

  1. Wouldn’t this not work since the Auxiliary database would be unmounted until the RMAN script re-creates the control file?
    Since we are using ASM on our Source and Auxiliary database, we drop the Auxiliary database prior to running duplicate.

    • Hi Mark, I see it more like a non-implemented feature. The conversion of file names does not work for the BCT. I did not check if the behavior changed in 12cR2, I will do it soon and blog about it 🙂

  2. It appears that the command “set newname for block change tracking file” did not help either. We will try the suggested work-around from Ludovic. I am hoping that Oracle has already identified this as a bug and will fix it soon.

  3. Hey, thanks, this saved my ass today! Anyways, I should set it to off on the source DB, that’s a DataGuard, and I backup the secondary, so BCT doesn’t do anything.

  4. Thanks for sharing I was able to add this into our automated rman dupliate jobs for our ZDLRA and this helped!

  5. Hi Ludo

    In 12c and with some 11gR2 patches there is a new RMAN syntax:
    “set newname for block change tracking file…”
    Furthermore what you can use always and in my opinion the easiest approach is db_file_name_convert. That works very well for the BCT file.

    Cheers Roland

    • Hi Roland, thank you for your comment! 🙂
      Unfortunately, sometimes the db_file_name_convert doesn’t work as expected and I encounter the ORA-19755 error despite the convert is correctly set.
      I wasn’t aware of the new syntax “set newname for block change tracking file”, I’ll definitely try it, but this would require additional checks prior to run the duplicate (if version > 11.2.0.x and BCT is enabled on the source).

  6. Pingback: Block Change Tracking and Duplicate: avoid ORA-19755 - Ludovico Caldara - Blogs - triBLOG

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.