Hemant K Chitale http://hemantoracledba.blogspot.

com Incomplete Recovery with a BACKUP CONTROLFIE : RollForward through future ArchiveLogs : This document was published in my blog on 14-Feb-2008 at
http://hemantoracledba.blogspot.com/2008/02/database-recovery-rollforward-from.html

Every once in a while we come across questions about Database Recovery posed by new DBAs. Furthermore, DBAs experienced with RMAN only might wonder how Oracle can apply ArchiveLogs which are not included in RMAN BackupSets (eg created since the last RMAN backup but yet available on disk) to continue a database recovery as far as possible. How does the RECOVER command know which ArchiveLog , which SCN generated at which time is required to be applied when rolling forward using a Backup Controlfile ? Knowledge of ArchiveLogs would be available if you are using a current controlfile or an RMAN Repository (the RMAN Repository still doesnt know the ArchiveLogs generated after the last backup which updated the repository). What if you have neither ? The Backup Controlfile could be either of : a. A binary backup controlfile that was older then the ArchiveLogs, so information about the ArchiveLogs generated after the backup is not available in the controlfile b. A trace backup from which I run a CREATE CONTROLFILE. This would have no information whatsoever about ArchiveLogs even of those generated before the trace backup was executed. There are 3 components to the manner in which the RECOVER command prompts us for the Archive Log files : 1. Log_Archive_Dest 2. Log_Archive_Format 3. Log Sequence Numbers, SCNs, Timestamps For example, if I restore to another server and use a different directory for the Log_Archive_Dest in the initora/spfileora when I STARTUP MOUNT, the RECOVER command would use this new path to prompt me for the ArchiveLogs to be applied. If my Log_Archive_Format is different, it uses this new format to construct the file names. What about the Sequence,SCN,Timestamp ? Well come back to these later. Heres how I build my proof that the RECOVER command can work without prior knowledge of ArchiveLogs. {Note : In the RMAN listings the date/timestamp appears in the format 09_FEB_08_23_21_50 because I explicitly set NLS_DATE_FORMAT in the environment when I run RMAN commands}. SCENARIO A : With a Binary Backup Controlfile

 Hemant K Chitale http://hemantoracledba.blogspot.com Step 1: I take a backup of the database, using RMANs BACKUP DATABASE. This goes, by default, to my db_recovery_file_dest (the FlashRecoveryArea), configured in 10gR2.
Spooling started in log file: RMAN_Backup_of_DB.Log Recovery Manager10.2.0.1.0 RMAN> connected to target database: OR10G2DB (DBID=138573118) RMAN> Starting backup at 09_FEB_08_23_21_46 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=60 devtype=DISK channel ORA_DISK_1: starting full datafile backupset channel ORA_DISK_1: specifying datafile(s) in backupset input datafile fno=00001 name=C:\OR10G2DB\SYSTEM01.DBF input datafile fno=00003 name=C:\OR10G2DB\SYSAUX01.DBF input datafile fno=00002 name=C:\OR10G2DB\UNDOTBS01.DBF input datafile fno=00004 name=C:\OR10G2DB\USERS01.DBF input datafile fno=00005 name=C:\OR10G2DB\EXAMPLE01.DBF channel ORA_DISK_1: starting piece 1 at 09_FEB_08_23_21_50 channel ORA_DISK_1: finished piece 1 at 09_FEB_08_23_24_15 piece handle=C:\OR10G2DB_FLASH\OR10G2DB\BACKUPSET\2008_02_09\O1_MF_NNNDF_TAG20080209T232148_3TV K8HRF_.BKP tag=TAG20080209T232148 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:02:26 Finished backup at 09_FEB_08_23_24_15 Starting Control File and SPFILE Autobackup at 09_FEB_08_23_24_16 piece handle=C:\OR10G2DB_FLASH\OR10G2DB\AUTOBACKUP\2008_02_09\O1_MF_S_646269856_3TVKF1SW_.BKP comment=NONE Finished Control File and SPFILE Autobackup at 09_FEB_08_23_24_19 RMAN> Recovery Manager complete.

I also take a separate binary backup of the controlfile.

SQL> set echo on SQL> alter database backup controlfile to 'C:\ORACLE_EXERCISES\cntrlfile_bak.dbf'; Database altered. SQL> spool off

Step 2: I run some transactions on the database to ensure that a number of log switches and SCN changes occur.
SQL> SQL> SQL> SQL> SQL> SQL> SQL> set linesize 130 set pages60 col name format a45 col First_Time format a19 select to_char(sysdate,'DD-MON-RR HH24:MI') from dual;

TO_CHAR(SYSDATE --------------09-FEB-08 23:32 SQL> SQL> select group#, sequence#, first_change#, status from v$log order by sequence#;

 Hemant K Chitale http://hemantoracledba.blogspot.com

GROUP# SEQUENCE# FIRST_CHANGE# STATUS ---------- ---------- ------------- ---------------3 7 1540484 INACTIVE 1 8 1540669 INACTIVE 2 9 1540888 CURRENT SQL> SQL> select recid, name, sequence#, to_char(first_time,'DD-MON-RR HH24:MI') First_Time, first_change# 2 from v$archived_log 3 where first_time > trunc(sysdate) 4 order by first_time; no rows selected

At this point, there are NO archivelogs of today. The CURRENT Online Redo Log is Sequence#9. [Note : If you are confused as to why the SCN difference between the Logfiles is so low (ie very few SCNs are incremented from one Sequence# to the next Sequence#, it is because I had, in the past, issued a few ALTER SYSTEM SWITCH LOGFILE commands with very few transactions in each LogFile].
SQL> SQL> select dbid, name, checkpoint_change#, current_scn from v$database; DBID NAME CHECKPOINT_CHANGE# CURRENT_SCN ---------- --------------------------------------------- ------------------ ----------138573118 OR10G2DB 1543675 1544669

My current SCN and the SCN as of the last checkpoint

SQL> SQL> REM Begin Transactions here ======================================================== SQL> SQL> SQL> drop table hemant.test_txn_table ; Table dropped. SQL> SQL> 2 3 4 5 create table hemant.test_txn_table as select * from dba_objects union select * from dba_objects /

Table created. SQL> SQL> update hemant.test_txn_table 2 set object_id=object_id+1, owner=substr(owner,1,3)||'_HKC' ; 51582 rows updated. SQL> commit; Commit complete. SQL> SQL> create index hemant.test_txn_tbl_ndx on hemant.test_txn_table(owner); Index created. SQL> SQL> delete hemant.test_txn_table 2 where owner = 'SYS_HKC'; 24692 rows deleted.

 Hemant K Chitale http://hemantoracledba.blogspot.com

SQL> rollback; Rollback complete. SQL> SQL> update hemant.test_txn_table 2 set object_id=object_id+1, owner=substr(owner,1,3)||'_HKC2' 3 where owner = 'SYS_HKC'; 24692 rows updated. SQL> commit; Commit complete. SQL> alter system switch logfile; System altered. SQL> SQL> select group#, status from v$log order by status; GROUP# ---------2 3 1 STATUS ---------------ACTIVE ACTIVE CURRENT

SQL> SQL> select recid, name, sequence#, to_char(first_time,'DD-MON-RR HH24:MI') First_Time ,first_change# 2 from v$archived_log 3 where first_time > trunc(sysdate) 4 order by sequence#;
RECID ---------569 570 571 572 573 NAME SEQUENCE# FIRST_TIME FIRST_CHANGE# --------------------------------------------- ---------- ------------------- ------------C:\OR10G2DB\ARCH\MY_ARC_10_645627350_1.BAK 10 09-FEB-08 23:32 1544764 C:\OR10G2DB\ARCH\MY_ARC_11_645627350_1.BAK 11 09-FEB-08 23:32 1545127 C:\OR10G2DB\ARCH\MY_ARC_12_645627350_1.BAK 12 09-FEB-08 23:32 1545530 C:\OR10G2DB\ARCH\MY_ARC_13_645627350_1.BAK 13 09-FEB-08 23:32 1545558 C:\OR10G2DB\ARCH\MY_ARC_14_645627350_1.BAK 14 09-FEB-08 23:32 1545567

Note that the above list does not show me Sequence#9 because the FIRST_TIME for this file is before trunc(sysdate). This file was actually the CURRENT Online RedoLog at the time that I began this testing and did get archived out as MY_ARC_9_645627350_1.BAK.
SQL> SQL> select dbid, name, checkpoint_change#, current_scn from v$database; DBID NAME CHECKPOINT_CHANGE# CURRENT_SCN ---------- --------------------------------------------- ------------------ ----------138573118 OR10G2DB 1545818 1546226 SQL> SQL> spool off

I have generated Log Sequences 10 to 14 and significantly incremented the SCNs from 1544669 to 1546226.

Step 3: I crash the database, remove the Database and Online Redo Logs.

 Hemant K Chitale http://hemantoracledba.blogspot.com Step 4: I restore the controlfile alone from my binary backup (manually copying it backup as CONTROL0[1-3].CTL) and verify its contents.
SQL> set pages600 SQL> set linesize 132 SQL> set echo on SQL> startup mount ORACLE instance started. Total System Global Area 268435456 bytes Fixed Size 1248504 bytes Variable Size 171967240 bytes Database Buffers 92274688 bytes Redo Buffers 2945024 bytes Database mounted. SQL> SQL> select group#, status from v$log order by status; GROUP# ---------2 1 3 STATUS ---------------CURRENT INACTIVE INACTIVE

SQL> SQL> select recid, name, sequence#, to_char(first_time,'DD-MON-RR HH24:MI') First_Time, first_change# 2 from v$archived_log 3 where first_time > trunc(sysdate) 4 order by first_time; no rows selected SQL> SQL> select dbid, name, checkpoint_change#, current_scn from v$database; DBID NAME CHECKPOINT_CHANGE# CURRENT_SCN ---------- --------- ------------------ ----------138573118 OR10G2DB 1543675 0 SQL> spool off

I can see that this controlfile only knows the last checkpoint (SCN 1543675) before I began transactions. It does not know of any archivelogs generated today. {Why is CURRENT_SCN=0 ? Interesting. Well see it again later}.

Step 5: I restore the database. I use the RMAN Restore database command.
Spooling started in log file: RMAN_Restore_DB.Log Recovery Manager10.2.0.1.0 RMAN> connected to target database: OR10G2DB (DBID=138573118, not open) RMAN> Starting restore at 09_FEB_08_23_46_15 Starting implicit crosscheck backup at 09_FEB_08_23_46_15 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=57 devtype=DISK Crosschecked 7 objects Finished implicit crosscheck backup at 09_FEB_08_23_46_18

 Hemant K Chitale http://hemantoracledba.blogspot.com

Starting implicit crosscheck copy at 09_FEB_08_23_46_18 using channel ORA_DISK_1 Finished implicit crosscheck copy at 09_FEB_08_23_46_18 searching for all files in the recovery area cataloging files... no files cataloged using channel ORA_DISK_1 channel ORA_DISK_1: starting datafile backupset restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set restoring datafile 00001 to C:\OR10G2DB\SYSTEM01.DBF restoring datafile 00002 to C:\OR10G2DB\UNDOTBS01.DBF restoring datafile 00003 to C:\OR10G2DB\SYSAUX01.DBF restoring datafile 00004 to C:\OR10G2DB\USERS01.DBF restoring datafile 00005 to C:\OR10G2DB\EXAMPLE01.DBF channel ORA_DISK_1: reading from backup piece C:\OR10G2DB_FLASH\OR10G2DB\BACKUPSET\2008_02_09\O1_MF_NNNDF_TAG20080209T232148_3TVK8HRF_. BKP channel ORA_DISK_1: restored backup piece 1 piece handle=C:\OR10G2DB_FLASH\OR10G2DB\BACKUPSET\2008_02_09\O1_MF_NNNDF_TAG20080209T232148_3TV K8HRF_.BKP tag=TAG20080209T232148 channel ORA_DISK_1: restore complete, elapsed time: 00:02:16 Finished restore at 09_FEB_08_23_48_37 RMAN> Recovery Manager complete.

Note that I have only issued the RESTORE command. Not the RECOVER command yet. However, Ive also re-run the recovery with RMAN which well see later. Why I prefer SQL is obvious when you see the range of queries and commands available in SQL.

Step 6: I go back to my SQLPlus command line and issue the RECOVER command. Before that, to test my contention about how it constructs the ArchiveLog file name, I even change the Log_Archive_Format.
SQL> show parameter log_Archive_format NAME TYPE VALUE ------------------------------------ ----------- -----------------------------log_archive_format string MY_ARC_%s_%r_%t.BAK SQL> show parameter log_archive_dest_1 NAME TYPE VALUE ------------------------------------ ----------- -----------------------------log_archive_dest_1 string LOCATION=C:\OR10G2DB\ARCH log_archive_dest_10 string SQL> alter system set log_archive_format='OR10G2DB_%s_%r_%t.ARC' scope=SPFILE; System altered. SQL> shutdown ORA-01109: database not open Database dismounted. ORACLE instance shut down. SQL> startup mount ORACLE instance started.

 Hemant K Chitale http://hemantoracledba.blogspot.com

Total System Global Area 268435456 bytes Fixed Size 1248504 bytes Variable Size 171967240 bytes Database Buffers 92274688 bytes Redo Buffers 2945024 bytes Database mounted. SQL> show parameter log_archive_format; NAME TYPE VALUE ------------------------------------ ----------- -----------------------------log_archive_format string OR10G2DB_%s_%r_%t.ARC SQL> select dbid, name, checkpoint_change#, current_scn from v$database; DBID NAME CHECKPOINT_CHANGE# CURRENT_SCN ---------- --------- ------------------ ----------138573118 OR10G2DB 1543675 0

Still verifying the last known Checkpoint SCN. Also, note that the Log_Archive_Format is now different.
SQL> recover database using backup controlfile until cancel; ORA-00279: change 1544306 generated at 02/09/2008 23:21:50 needed for thread 1 ORA-00289: suggestion : C:\OR10G2DB\ARCH\OR10G2DB_9_645627350_1.ARC ORA-00280: change 1544306 for thread 1 is in sequence #9 Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

Interesting. It picked up the new Log_Archive_Format. It also knew about change#1544306 that was later then the last checkpointed one in the controlfile. And it also knew the ArchiveLog Sequence# [9]. I have copied in the original ArchiveLogs using the new filename format, so I proceed with the Recovery.
ORA-00279: ORA-00289: ORA-00280: ORA-00278: needed for change 1544764 generated at 02/09/2008 23:32:31 needed for thread 1 suggestion : C:\OR10G2DB\ARCH\OR10G2DB_10_645627350_1.ARC change 1544764 for thread 1 is in sequence #10 log file 'C:\OR10G2DB\ARCH\OR10G2DB_9_645627350_1.ARC' no longer this recovery

Specify log: {<RET>=suggested | filename | AUTO | CANCEL} ORA-00279: ORA-00289: ORA-00280: ORA-00278: needed for change 1545127 generated at 02/09/2008 23:32:35 needed for thread 1 suggestion : C:\OR10G2DB\ARCH\OR10G2DB_11_645627350_1.ARC change 1545127 for thread 1 is in sequence #11 log file 'C:\OR10G2DB\ARCH\OR10G2DB_10_645627350_1.ARC' no longer this recovery

Specify log: {<RET>=suggested | filename | AUTO | CANCEL} ORA-00279: ORA-00289: ORA-00280: ORA-00278: needed for change 1545530 generated at 02/09/2008 23:32:39 needed for thread 1 suggestion : C:\OR10G2DB\ARCH\OR10G2DB_12_645627350_1.ARC change 1545530 for thread 1 is in sequence #12 log file 'C:\OR10G2DB\ARCH\OR10G2DB_11_645627350_1.ARC' no longer this recovery

Specify log: {<RET>=suggested | filename | AUTO | CANCEL} CANCEL Media recovery cancelled.

What have I done ? I actually had transactions going upto Log Sequence 14 and Checkpoint Change#1545818 but Ive stopped at Sequence# 11 and Change#1545529 !

 Hemant K Chitale http://hemantoracledba.blogspot.com As long as all the Datafiles are consistent, I will be allowed to open the database. This is an Incomplete Recovery, after all.
SQL> alter database open resetlogs; Database altered. SQL> select dbid, name, checkpoint_change#, current_scn from v$database; DBID NAME CHECKPOINT_CHANGE# CURRENT_SCN ---------- --------- ------------------ ----------138573118 OR10G2DB 1545532 1545853 SQL> shutdown abort; ORACLE instance shut down.

Dont worry about the Shutdown Abort here. Let me verify the database and also understand why I got the CURRENT_SCN=0 earlier.
SQL> startup; ORACLE instance started. Total System Global Area 268435456 bytes Fixed Size 1248504 bytes Variable Size 171967240 bytes Database Buffers 92274688 bytes Redo Buffers 2945024 bytes Database mounted. Database opened. SQL> select dbid, name, checkpoint_change#, current_scn from v$database; DBID NAME CHECKPOINT_CHANGE# CURRENT_SCN ---------- --------- ------------------ ----------138573118 OR10G2DB 1565850 1565974 SQL> shutdown abort ORACLE instance shut down. SQL> startup mount ORACLE instance started. Total System Global Area 268435456 bytes Fixed Size 1248504 bytes Variable Size 171967240 bytes Database Buffers 92274688 bytes Redo Buffers 2945024 bytes Database mounted. SQL> select dbid, name, checkpoint_change#, current_scn from v$database; DBID NAME CHECKPOINT_CHANGE# CURRENT_SCN ---------- --------- ------------------ ----------138573118 OR10G2DB 1565850 0 SQL> alter database open; Database altered. SQL> select dbid, name, checkpoint_change#, current_scn from v$database; DBID NAME CHECKPOINT_CHANGE# CURRENT_SCN ---------- --------- ------------------ ----------138573118 OR10G2DB 1586058 1586148 SQL>

So, if a database is Mounted but not Open, the CURRENT_SCN is shown as 0.

 Hemant K Chitale http://hemantoracledba.blogspot.com Note how Oracle has significantly bumped up the SCNs now ! Instance Recovery and Startup increment the SCN. You will also notice that a Checkpoint is also issued automatically by Oracle. Alternate RESTORE and RECOVER using RMAN only : I could also have used the RMAN RESTORE CONTROLFILE FROM AUTOBACKUP command as I have enabled Autobackups. Since this is a 10g database, I am using db_recovery_file_dest=C:\OR10G2DB_FLASH (with a db_recovery_file_dest_size=7812M limit). This is my FRA FlashRecoveryArea. Note two advantages with this : a) Oracle can automatically search for backupsets b) Oracle can identify the Controlfile using the DB_NAME even though I do not have the DBID. {Only 1 database has backups in the FRA). After having restored the Controlfile, I issue the RESTORE DATABASE and then RECOVER DATABASE commands. Note how the RESTORE requires the Database to be mounted RESTORE needs access to the Controlfiles which is available in the MOUNT stage.
Spooling started in log file: RMAN_Restore_CntrlFile.LOG Recovery Manager10.2.0.1.0 RMAN> connected to target database: OR10G2DB (not mounted) RMAN> [command : RESTORE CONTROLFILE] Starting restore at 10_FEB_08_00_39_13 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=60 devtype=DISK RMAN-00571: RMAN-00569: RMAN-00571: RMAN-03002: RMAN-06563: =========================================================== =============== ERROR MESSAGE STACK FOLLOWS =============== =========================================================== failure of restore command at 02/10/2008 00:39:14 control file or SPFILE must be restored using FROM AUTOBACKUP

RMAN> [command : RESTORE CONTROLFILE FROM AUTOBACKUP] Starting restore at 10_FEB_08_00_39_20 using channel ORA_DISK_1 recovery area destination: \OR10G2DB_FLASH database name (or database unique name) used for search: OR10G2DB channel ORA_DISK_1: autobackup found in the recovery area channel ORA_DISK_1: autobackup found: C:\OR10G2DB_FLASH\OR10G2DB\AUTOBACKUP\2008_02_09\O1_MF_S_646269856_3TVKF1SW_.BKP channel ORA_DISK_1: control file restore from autobackup complete output filename=C:\OR10G2DB\CONTROL01.CTL output filename=C:\OR10G2DB\CONTROL02.CTL output filename=C:\OR10G2DB\CONTROL03.CTL Finished restore at 10_FEB_08_00_39_23 RMAN> [command : RESTORE DATABASE] Starting restore at 10_FEB_08_00_39_39 using channel ORA_DISK_1 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of restore command at 02/10/2008 00:39:40 ORA-01507: database not mounted RMAN> [command : ALTER DATABASE MOUNT, which is an SQL command]

 Hemant K Chitale http://hemantoracledba.blogspot.com

sql statement: alter database mount released channel: ORA_DISK_1 RMAN> [command : RESTORE DATABASE] Starting restore at 10_FEB_08_00_40_06 Starting implicit crosscheck backup at 10_FEB_08_00_40_06 allocated channel: ORA_DISK_1 channel ORA_DISK_1: sid=57 devtype=DISK Crosschecked 6 objects Finished implicit crosscheck backup at 10_FEB_08_00_40_08 Starting implicit crosscheck copy at 10_FEB_08_00_40_08 using channel ORA_DISK_1 Finished implicit crosscheck copy at 10_FEB_08_00_40_08 searching for all files in the recovery area cataloging files... cataloging done List of Cataloged Files ======================= File Name: C:\OR10G2DB_FLASH\OR10G2DB\AUTOBACKUP\2008_02_09\O1_MF_S_646269856_3TVKF1SW_.BKP using channel ORA_DISK_1 channel ORA_DISK_1: starting datafile backupset restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set restoring datafile 00001 to C:\OR10G2DB\SYSTEM01.DBF restoring datafile 00002 to C:\OR10G2DB\UNDOTBS01.DBF restoring datafile 00003 to C:\OR10G2DB\SYSAUX01.DBF restoring datafile 00004 to C:\OR10G2DB\USERS01.DBF restoring datafile 00005 to C:\OR10G2DB\EXAMPLE01.DBF channel ORA_DISK_1: reading from backup piece C:\OR10G2DB_FLASH\OR10G2DB\BACKUPSET\2008_02_09\O1_MF_NNNDF_TAG20080209T232148_3TVK8HRF_. BKP channel ORA_DISK_1: restored backup piece 1 piece handle=C:\OR10G2DB_FLASH\OR10G2DB\BACKUPSET\2008_02_09\O1_MF_NNNDF_TAG20080209T232148_3TV K8HRF_.BKP tag=TAG20080209T232148 channel ORA_DISK_1: restore complete, elapsed time: 00:02:16 Finished restore at 10_FEB_08_00_42_27 RMAN> [command : RECOVER DATABASE] Starting recover at 10_FEB_08_00_43_19 using channel ORA_DISK_1 starting media recovery archive log filename=C:\OR10G2DB\ARCH\OR10G2DB_9_645627350_1.ARC thread=1 sequence=9 archive log filename=C:\OR10G2DB\ARCH\OR10G2DB_10_645627350_1.ARC thread=1 sequence=10 archive log filename=C:\OR10G2DB\ARCH\OR10G2DB_11_645627350_1.ARC thread=1 sequence=11 archive log filename=C:\OR10G2DB\ARCH\OR10G2DB_11_645627350_1.ARC thread=1 sequence=12 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of recover command at 02/10/2008 00:43:29 RMAN-11003: failure during parse/execution of SQL statement: alter database recover logfile 'C:\OR10G2DB\ARCH\OR10G2DB_11_645627350_1.ARC' ORA-00310: archived log contains sequence 11; sequence 12 required ORA-00334: archived log: 'C:\OR10G2DB\ARCH\OR10G2DB_11_645627350_1.ARC' RMAN> [command : ALTER DATABASE OPEN RESETLOGS] database opened RMAN>

 Hemant K Chitale http://hemantoracledba.blogspot.com The RECOVER could not find the Sequence#12 file as I had not renamed it to the new log_archive_format (file name format). Therefore, it re-read the Sequence#11 file thinking it to be for Sequence#12 and errored on it.

Summary : There we have it ! The Database is actually recovered to a consistent point in time. We have not applied ALL the ArchiveLogs (Sequence#14) but still do have a consistent database (as of Sequence#11). Obviously, this is an Incomplete Recovery as we have not continued applying Logs till the last Online Log. Could I have recovered right up to Change#1546226 {which was the CURRENT_SCN when the database was crashed and deleted} ? No. The last few transactions were still in the Online Redo Logs. I could have recovered upto the last SCN in the last available ArchiveLog (Sequence #14). Note how the Current_SCN is visible only after we OPEN the database. Since we have done a RESETLOGS, the database has diverged. If we want to reapply Sequence#12 to Sequence#14, we need to know the procedure for a Recovery Through ResetLogs.

Getting the SCNs and Timestamps (and Sequence#s) : But the question still arises : How did Oracle know the SCN and Timestamp with the Sequence# of the next archivelog file yet to be applied ? If my controlfile is older than the archivelogs and I do not use a Repository, where does Oracle get the information to construct the message change <number> generated at <timestamp> needed for thread 1 ? The fact of the matter is that information this informaton is in the DataFiles and Log files (remember : Online Redo or Archive Log files have the same format) ! These are from the datafile headers :
SQL> 2 3* SQL> select file#, checkpoint_change#, to_char(checkpoint_time,'DD/MM/YYYY HH24:MI:SS') from v$datafile_header order by file# /

FILE# CHECKPOINT_CHANGE# TO_CHAR(CHECKPOINT_ ---------- ------------------ ------------------1 1544306 09/02/2008 23:21:50 2 1544306 09/02/2008 23:21:50 3 1544306 09/02/2008 23:21:50 4 1544306 09/02/2008 23:21:50 5 1544306 09/02/2008 23:21:50 SQL>

These are from a dump of the SYSTEM01.DBF datafile :

V10 STYLE FILE HEADER: Compatibility Vsn = 169869568=0xa200100 Db ID=138573118=0x842753e, Db Name='OR10G2DB' Activation ID=0=0x0

 Hemant K Chitale http://hemantoracledba.blogspot.com

Control Seq=6451=0x1933, File size=71680=0x11800 File Number=1, Blksiz=8192, File Type=3 DATA Tablespace #0 - SYSTEM rel_fn:1 Creation at scn: 0x0000.00000009 08/30/2005 13:50:22 Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0 reset logs count:0x267b7dd6 scn: 0x0000.00177396 reset logs terminal rcv data:0x0 scn: 0x0000.00000000 prev reset logs count:0x267aaf08 scn: 0x0000.0016ff67 prev reset logs terminal rcv data:0x0 scn: 0x0000.00000000 recovered at 02/11/2008 23:04:13 status:0x2000 root dba:0x00400179 chkpt cnt: 867 ctl cnt:866 begin-hot-backup file size: 0 Checkpointed at scn: 0x0000.00179072 02/09/2008 23:21:50 thread:1 rba:(0x9.15a9.10)

Thus, the Datafiles identify the SCN being the lowest to be recovered (0x 179072, which is 1544306 in Decimal). That is the first change to be recovered. (Note : It is higher than the Checkpoint_Change# of the ControlFile meaning that there had been a Checkpoint after the ControlFile was backed up). The active log sequence at the time was 0x9. Therefore, Oracle identifies that it needs to recover from SCN 1544306 in Log file Sequence#9.
{If you find it curious that the Checkpoint_Change# 1544306 in the V$DATAFILE_HEADER view is actually higher than that 1543675 in the V$DATABASE listing obtained after the Datafiles backup, see the section titled Different Checkpoint_Change# values further below}.

Here are some lines of the header from a dump of the archivelog C:\OR10G2DB\ARCH\ OR10G2DB_9_645627350_1.ARC (which was the archived copy of Redo Log Sequence#9) :
DUMP OF REDO FROM FILE 'C:\OR10G2DB\ARCH\OR10G2DB_9_645627350_1.ARC' Opcodes *.* RBAs: 0x000000.00000000.0000 thru 0xffffffff.ffffffff.ffff SCNs: scn: 0x0000.00000000 thru scn: 0xffff.ffffffff Times: creation thru eternity FILE HEADER: Compatibility Vsn = 169869568=0xa200100 Db ID=138573118=0x842753e, Db Name='OR10G2DB' Activation ID=195152594=0xba1cad2 Control Seq=6498=0x1962, File size=16384=0x4000 File Number=2, Blksiz=512, File Type=2 LOG descrip:"Thread 0001, Seq# 0000000009, SCN 0x000000178318-0x00000017923c" thread: 1 nab: 0x3ef2 seq: 0x00000009 hws: 0x5 eot: 0 dis: 0 <lines deleted> Low scn: 0x0000.00178318 (1540888) 02/02/2008 15:12:40 Next scn: 0x0000.0017923c (1544764) 02/09/2008 23:32:31 <lines deleted>

And this is from a dump of archivelog C:\OR10G2DB\ARCH\ OR10G2DB_10_645627350_1.ARC :

DUMP OF REDO FROM FILE 'C:\OR10G2DB\ARCH\OR10G2DB_10_645627350_1.ARC' Opcodes *.* RBAs: 0x000000.00000000.0000 thru 0xffffffff.ffffffff.ffff SCNs: scn: 0x0000.00000000 thru scn: 0xffff.ffffffff Times: creation thru eternity FILE HEADER: Compatibility Vsn = 169869568=0xa200100 Db ID=138573118=0x842753e, Db Name='OR10G2DB' Activation ID=195152594=0xba1cad2 Control Seq=6501=0x1965, File size=16384=0x4000 File Number=3, Blksiz=512, File Type=2 LOG descrip:"Thread 0001, Seq# 0000000010, SCN 0x00000017923c-0x0000001793a7"

 Hemant K Chitale http://hemantoracledba.blogspot.com

thread: 1 nab: 0x3df5 seq: 0x0000000a hws: 0x2 eot: 0 dis: 0 <lines deleted> Low scn: 0x0000.0017923c (1544764) 02/09/2008 23:32:31 Next scn: 0x0000.001793a7 (1545127) 02/09/2008 23:32:35 <lines deleted>

Thus, it becomes obvious that when Oracle does a Log Switch (eg from Sequence#9 to Sequence#10), it increments the SCN and updates the header of the previous log file (Sequence#9) with information about the new SCN (1544764) and its Timestamp and uses the new SCN as the Low SCN of the next log file (Seq #10). Therefore, the Sequence#9 log file effectively has a pointer to Sequence#10. Generating the file name itself depends on the LOG_ARCHIVE_FORMAT as Ive shown, if I change the LOG_ARCHIVE_FORMAT, Oracle prompts for a file name with the new format. Different Checkpoint Change# values : Why is it that the datafiles backed up before the transaction show a Checkpoint_Change# 1544306 when the query on V$DATABASE when beginning the transactions after the backup of the datafiles still shows a lower Checkpoint_Change# 1543675 ? The CURRENT_SCN when beginning transactions was 1544669, which is higher then that in the datafile backups. Heres an explanation when an RMAN Backup is running note thatthis RMAN backup was a different backup done much later so the Checkpoint_Change# values listed below are much higher than those in the Recovery testing in this document. This listing below only explains how V$DATABASE.CHECKPOINT_CHANGE# can be different from V$DATAFILE.CHECKPOINT_CHANGE#
SQL> l 1 select d.checkpoint_change# DB_Chk_CN, f.checkpoint_change# SYS_Chk_CN, c.c urrent_scn 2 from 3 (select checkpoint_change# from v$database) d, 4 (select checkpoint_change# from v$datafile_header where file#=1) f, 5* (select current_scn from v$database) c SQL> / DB_CHK_CN SYS_CHK_CN CURRENT_SCN ---------- ---------- ----------1559033 1565355 1565370 SQL>

Apparently, when I issue a BACKUP DATABASE in RMAN, the Checkpoint_Change# in the Datafile headers IS incremented, but that in the Controlfile (reflected in V$DATABASE) does not get updated. RMAN apparently forces a Datafile checkpoint when it picks up the datafile. It is only at the completion of the next database checkpoint that the controlfile (V$DATABASE) is updated as well. {Incremental Checkpoints is another complication which we could discuss later}. SCENARIO B : With a Trace Backup of the Controlfile Step 1: I take a Trace Backup of the Controlfile.

 Hemant K Chitale http://hemantoracledba.blogspot.com

SQL> alter database backup controlfile to trace as 2 'C:\Oracle_Exercises\cntrlfile_Trace.sql'; alter database backup controlfile to trace as * ERROR at line 1: ORA-01277: file 'C:\ORACLE_EXERCISES\CNTRLFILE_TRACE.SQL' already exists SQL> alter database backup controlfile to trace as 2 'C:\Oracle_Exercises\cntrlfile_Trace.sql' reuse; Database altered. SQL>

the above command also illustrates the fact that we get an error if the trace already exists and we can use the REUSE keyword to overwrite an existing tracefile. Step 2: I run some transactions on the database to ensure a number of log switches and SCN changes occur. Step 3: I crash the database, remove the datafiles. Step 4: I use the Trace script to recreate the controlfiles. Ooops ! I cannot run a CREATE CONTROLFILE if datafiles are not present. I cannot RESTORE datafiles using RMAN if I do not have a Controlfile and MOUNT the database. I am in a Catch-22 situation. This makes it very important to have a Binary Backup Controlfile ! Yes, using an RMAN Repository is the protection. But if the Repository database is on the same server as the target database and is also lost at the same time as the target database, then I have no recourse. I can use Tracefile Backups to create Controlfiles when I use scripted (known as User Managed) database backups and can manually (ie without RMAN) restore the database files first. However, if the database file backups are in RMAN Backup Sets, I must have a Controlfile restored first. In a User Managed scenario, I would restore the database files from my own backup (whether on disk or on tape) using the native, OS or Tape Library commands, create the controlfile and then issue the RECOVER command. The RECOVER would read the starting SCN and Sequence# from the datafiles and every subsequent Sequence# from the ArchiveLogs that it applies.

10g RMAN also allows me to CATALOG RECOVERY AREA and CATALOG BACKUPPIECE. 9i RMAN cannot do so (although it can CATALOG DATAFILECOPY). One more reason why I would want a Binary Controlfile backup.

For other RECOVER DATABASE scenarios see : http://www.freelists.org/archives/oracle-l/05-2007/msg00440.html http://hemantoracledba.blogspot.com/2007/05/recovery-in-cold-backup.html http://hemantoracledba.blogspot.com/2007/05/rollforward-from-cold-backup.html