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.

HTH

Ludovico

The following two tabs change content below.

Ludovico

Oracle ACE Director and Computing Engineer at CERN
Ludovico is an Oracle ACE Director, frequent speaker and community contributor, working as Computing Engineer at CERN, the European Organization for Nuclear Research, in Switzerland.

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

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

  2. 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

  3. 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).

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

  5. 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.

  6. 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.

  7. 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.

  8. 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 🙂

  9. Thank you Ludovico: our tool team implemented both ‘set newname for block change tracking file to new;’ for 12c and your shell script for prior-to-12c versions.

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.