SQL BackTrack and Flash Recovery Area

Posted in: Technical Track

Is your database in archive log mode?

Is your database in flashback mode?

Have you defaulted your archive location to the flash recovery area?

Is your ORACLE_SID lowercase?

Do you use SQL BackTrack?

If your answer is yes to all these questions then beware!

There is a bug in SQL BackTrack (at least in version 6.8) that prevents your backing up of the archive logs from the flash recovery area. This will result in the inability to recover from any online backups that you have taken if you somehow lose those archive logs.

You do not receive any obvious errors when doing the backup but, if you are observant, you may spot the fact that the backup report does not show that it backed up any archive logs. To really check whether you are suffering from this problem then you need to check the $DTBASE/obacktrack/log/datatools.log. This is the log that gets written whenever any SQL BackTrack command is run. You will see an error such as

17:29:16.61 obacktrack[839826](2835/oramisc.cpp): Unable to open directory: '/home/oracle/data/test/test/archivelog'

You will know if you have been caught by this bug when you try to restore and you get messages that look something like this.

BMCBKO4802051E: The following Oracle error occurred during
BMCBKO4802051E: SQL-BackTrack processing : 'ORA-01195: online backup of file 1 needs more recovery to be consistent'
BMCBKO4802051E: The following Oracle error occurred during
BMCBKO4802051E: SQL-BackTrack processing : 'ORA-01110: data file 1: '/home/oracle/data/test/system01.dbf''
BMCBKO4805906E: Unable to perform recovery.

The problem arises when Oracle creates a directory in the flash recovery area that correspond to the database name. This directory is in uppercase. So, in my case, my ORACLE_SID is test and the init.ora parameter db_recovery_file_dest='/home/oracle/data/test'.

Oracle creates the directory

However when SQL BackTrack sees that the archive location is defaulted to the flash recovery area it tries to look in the directory

This fails … silently!

There are 2 workarounds to this issue that I have tested.

  1. Create a symbolic(soft) link to point to the real directory using ln -s
  2. Explicitly set the archive location using the init.ora parameter log_archive_dest_n

The workaround suggested by BMC (the supplier of SQL BackTrack) is to change the database name to uppercase. This will work too, but I haven’t tested it.



Want to talk with an expert? Schedule a call with our team to get the conversation started.

About the Author

I am currently one of the Oracle Internal Principal Consultants at Pythian. I have been working as a DBA since Oracle V6 for over 30 years and also dabble in various languages and tools such as bash, Perl, PL/SQL, C, Python, Ansible, Terraform and Go.

3 Comments. Leave new

Another option is to use HyperBac (www.hyperbac.com) instead of SQL BackTrack. It directly integrates with RMAN and will provide better in line compression for RMAN backups including archivelog backups, much more cost effective option for older Oracle systems than BackTrack.


sql-backtrack is not just about backup, It has lot more to offer than backup. One of the coolest feature is guided database recovery, also not to forget database duplication or cloning feature.
There is one more additional feature called ‘Incremental Database Duplication’.


HyperBac is just a wrapper on RMAN, SQL BT is far superior compare to any other tool for backup/recovery even when compare to RMAN, its very fast to gel will TSM or networker and faster backup/recovery compare to any other product


Leave a Reply

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