We all know that in certain recovery situations we need to use backup control files.And after the recovery, Oracle requires a RESETLOGS operation because Oracle needs to update certain structures in the backup control file before opening the database and resetting the logs.Let's try to understand what is updated and why? But let me first tell you what a backup control file is not : -An OS copy of the Control file taken when the database close. -An OS copy of the Control file taken when the database open. -An OS copy of the Control file taken when the database mounted. -A trace of the control file taken with the command 'Alter database backup controlfile to trace;' A backup control file is an image of the control file with some distinctive features of it's own. -It contains a file type flag(value=4) that tells oracle that it is a backup control file. -It is consistent with respect to a single point in time. -the stop SCN markers for each data file record are set to "0xffff.ffffffff". This means "not available". The above mentioned qualities ensure that the integrity of the control file is preserved. The file type flag of the control file tells oracle to ignore it's redo thread, checkpoint progress and log file records.By instructing Oracle to recover using a backup control file you are telling Oracle to avoid the redo thread records and log file records in the control file – and you know why. So, when we backup the control file to trace and generate the control file creation script,can we create a backup control file? The answer is yes. If you remember the script, there are are two sets of control file creation statements, one with resetlogs and another with noresetlogs.The one with resetlogs creates the backup control file. You can get the file type information by using the oradebug command Code (Text): sql>oradebug setmypid; Statement processed. sql>oradebug dump controlf 10; Statement processed. You will get the dump file at your user_dump_dest location. Be careful about using the backup control file command during recovery, as it may turn your current control file to a backup control file thereby destroying the log sequence ancestry via the resetlogs command. So why does one needs to do a resetlogs after recovery with backup control file ? Well the answer is as below Within each control file there are checkpoint progress records that provide Oracle with the on-disk RBA (redo byte address). This tells Oracle the offset into the current redo log file(s) that the LGWR has flushed the redo thread. Let’s suppose Oracle permitted you to open the database without a RESETLOGS after recovery using a backup control file. Then Oracle must use what it knows to be true about its online redo thread: the log file records, redo stream records and checkpoint progress records. If the redo log files remained intact during your restore and recovery then they probably have previously generated redo. If you have 3 online redo log groups and your backup control file states that the on-disk RBA is half way into group 2 and the existing (non-reset) redo log for group 2 is full of previously generated redo, Oracle would start writing redo to its last know on-disk RBA. Hopefully you see where this is going. Potentially, the last half of redo written to group 2 would correspond to changes post-recovery, i.e. you would have a redo log that is corrupt. There could be a major gap in SCNs between the last entry pre-recovery and the first entry post-recovery within the same redo log file. For this reason, Oracle needs to update the redo thread, log file and checkpoint progress records in accord with the new incarnation of the database. Cheers My heartful thanks to Eric S. Emrick, the author of the article "Backup Control Files- Are they Special ?", who , so beautifully, explained the concept of Backup control file.