RMAN-06054: media recovery requesting unknown archived log, Where is SCN kept?

Question

I have the following situation:

1. Backups of DB1(located on srv1 server) database are taken everyday at 1:00 AM.

2. I took backed up files(datafile,archivelog,controlfile,spfile) of 24/10/2011 and restored them on the server srv2.

3. During recovering Oracle required log file:

   RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 228 and starting SCN of 26651733

4. I searched that logfile on the server srv1 and copied it to the server srv2. Registered it with the database and run recover database command again. Still the same error, but with other sequence number and SCN.

   RMAN-06054: media recovery requesting unknown archived log for thread 1 with sequence 229 and starting SCN of 26654944

These archivelogs are generated after 24/10/2011 so backup of this date should not know about newer archivelogs. I can set recovery until that sequence but I just wonder to know where is that SCN stored? Why does my Oracle requires newer archivelogs?

Server srv1 and srv2 are not contacting with each other.

Thank you a lot.

Answer 1

Each redo log file (and archived redo log file) contains starting SCN and ending SCN. In case it is a last redo, the ending SCN is 0xffffffffffff.

nap01:~/oradata/jt10g$ strings redo01.log|head -3
z{|}
JT10G
Thread 0001, Seq# 0000000004, SCN 0x0000000b05b5-0x0000000bd34f

nap01:~/oradata/jt10g$ strings redo02.log|head -3
z{|}
JT10G
Thread 0001, Seq# 0000000005, SCN 0x0000000bd34f-0x0000000bf612

nap01:~/oradata/jt10g$ strings redo03.log|head -3
z{|}
JT10G
Thread 0001, Seq# 0000000006, SCN 0x0000000bf612-0xffffffffffff

Until database sees 0xffffffffffff it keeps asking for further logs. But it is not a problem, you can specify UNTIL SCN or UNTIL CANCEL for your recovery (this means you don't want a complete recovery, in other words you want to lose some recent data).

Answer 2

Just completing the answer from @kubanczyk, which is very good.

When you issue the recover database command, the RDBMS will try a complete recovery, meaning that it will look for the archived logs starting at the SCN (thread and sequence) from the restored backup and apply each archived log until it reaches the "active" redo log of the original database. That's why you're getting that error.

So your best bet as @kubanczyk posted is to use recover database until cancel which is an incomplete recovery until the most recent (contiguous) archived log found.

That should do the trick.

Hope this clarifies the restore/recover process a bit.

As for the other part of the question

Where is the SCN kept?

The SCN (System Change Number) is kept in the control file and the headers of each datafile, uit allows the database to know which datafiles are in sync and where the database writer DBWR has to perform the next writes from the database buffer cache.

Each backup also is "tagged" with a SCN (and thread-sequence) to allow the RMAN process know the exact "time" those were taken.

Hope this helps.