Tag Archives: Recovery

RMAN | ORA-19755: could not open change tracking file

Problem Description for ORA-19755

While performing a RMAN recovery on a database, you may receive an error “RMAN-03002: failure of recover command […]” followed by “ORA-19755: could not open change tracking file

A complete error stack example:

RMAN-00571: =========================================================== 
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== 
RMAN-00571: =========================================================== 
RMAN-03002: failure of recover command at 03/24/2015 11:59:21
ORA-00283: recovery session canceled due to errors
RMAN-11003: failure during parse/execution of SQL statement: alter database recover logfile '+BACKUP/arc_logs/1_56029_749586072.dbf'
ORA-00283: recovery session canceled due to errors
ORA-19755: could not open change tracking file
ORA-19750: change tracking file: '+DATA/blocktracking/blocktracking.log'
ORA-17503: ksfdopn:2 Failed to open file +DATA/blocktracking/blocktracking.log 
ORA-15173: entry 'blocktracking.log' does not exist in directory 'blocktracking'


The database block change tracking is enabled. It’s most likely that you are recovering from a complete disk failure, or transferring your database to another location where the log file was not created. This error will appear shortly after the restore operation, the moment where media recovery (database recovery phase) begins. Recovery operation start to rollup archive logs thus making modifications to datafiles’ blocks. This is where the block change tracking kicks in. But due to missing log file the recovery process to aborts.

The log file is created at first when the block tracking is enabled by alter database command. When recovering from disk failure, the pfile/spfile already has this information. Therefore, the file is expected to exist.


Login to the sqlplus and disable block tracking by issuing

alter database disable block change tracking;

Should you wish to keep the block tracking, you can easily re-enable it. First, ensure that the directory where the block tracking log file should reside exists. “+DATA/blocktracking/” In this case.

Then, issue

alter database enable block change tracking;

Restart the recovery operation in the RMAN. You may skip database restore and go to database recovery right away.

RAID Bad Stripe Corruption and VMFS Recovery

In the early Monday morning, we have found our VMware ESXi 5.0 server showing all VMFS datastores located on direct-attached storage disks (DAS) as offline. The disks themselves were offline as well. The server appeared to function bull all local disks were gone. A graceful shutdown attempt was in vain. After a cold boot one of the VMFS was still offline. The underlying RAID volume was online though.

Controller Status

This server uses Adaptec RAID 51245 controller so we use ARCCONF utility for monitoring and management. A quick glance at the controller’s state and configuration didn’t reveal much: no failed or degraded disks, the number of logical disk is correct.

Continue reading