Basic knowledge of Oracle: restoring true cache recovery

When learning basic knowledge about Oracle, we will understand the concept of Instance Recovery or Crash recovery, sometimes even these two terms share the same meaning in our daily language. In fact, there is a difference between Instance Recovery and Crash Recovery: for the Recovery after all the nodes in a single instance or RAC Crash, we call it Crash Recovery. However, when a node in RAC fails, the surviving ving instance tries to apply the redo on the thread of the failed node, which is called Instance Recovery.

Both Instance Recovery and Crash Recovery are composed of two parts: cache recovery followed by transaction recovery.

According to the official documentation, Cache Recovery is also called Rolling Forward, which is what we often call rollback. Transaction Recovery is also called Rolling Back, which is what we often call rollback. Rollback and rollback run through the basic concepts of Oracle restoration, which are necessary for us to learn.

If there is an event, you must take it as a secret. The theory is good and useless without practice. Fortunately, Crash Recovery is an easy experiment. Let's take a look:

SQL> shutdown abort;
ORACLE instance shut down.

SQL> startup mount;
ORACLE instance started.

Total System Global Area 1065353216 bytes
Fixed Size 2089336 bytes
Variable Size 486542984 bytes
Database Buffers 570425344 bytes
Redo Buffers 6295552 bytes
Database mounted.

SQL> alter database open;

Crash Recovery will start from alter database open. Let's observe its logs.

========================== Alert. log =
Alter database open
Tue juns 14 18:19:53 2011
Beginning crash recovery of 1 threads
Parallel recovery started with 2 processes
Tue juns 14 18:19:53 2011
Started redo scan
Tue juns 14 18:19:53 2011
Completed redo scan
0 redo blocks read, 0 data blocks need recovery
Tue juns 14 18:19:53 2011
Started redo application
Thread 1: logseq 1004, block 1124, scn 17136185
Tue juns 14 18:19:53 2011
Recovery of Online Redo Log: Thread 1 Group 2 Seq 1004 Reading mem 0
Mem #0:/flashcard/oradata/G10R2/onlinelog/o1_mf_2_6v34jokt _. log
Mem #1:/s01/flash_recovery_area/G10R2/onlinelog/o1_mf_2_6v34jotq _. log
Tue juns 14 18:19:53 2011
Completed redo application
Tue juns 14 18:19:53 2011
Completed crash recovery
Thread 1: logseq 1004, block 1124, scn 17156186
0 data blocks read, 0 data blocks written, 0 redo blocks read
Tue juns 14 18:19:53 2011
LGWR: STARTING ARCH PROCESSES
ARC0: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC0 started with pid = 16, OS id = 7829
Tue juns 14 18:19:53 2011
Thread 1 advanced to log sequence 1005 (thread open)
Thread 1 opened at log sequence 1005
Current log #3 seq #1005 mem #0:/flashcard/oradata/G10R2/onlinelog/o1_mf_3_6v34jpmp _. log
Current log #3 seq #1005 mem #1:/s01/flash_recovery_area/G10R2/onlinelog/o1_mf_3_6v34jpyn _. log
Successful open of redo thread 1
Tue juns 14 18:19:53 2011
ARC0: Becoming the 'no fal' ARCH
ARC0: Becoming the 'no srl' ARCH
ARC0: Becoming the heartbeat ARCH
Tue juns 14 18:19:53 2011
SMON: enabling cache recovery
Tue juns 14 18:19:53 2011
Db_recovery_file_dest_size of 204800 MB is 6.81% used. This is
User-specified limit on the amount of space that will be used by this
Database for recovery-related files, and does not reflect the amount
Space available in the underlying filesystem or ASM diskgroup.
Tue juns 14 18:19:54 2011
Successfully onlined Undo Tablespace 1.
Tue juns 14 18:19:54 2011
SMON: enabling tx recovery
Database Characterset is UTF8
Opening with internal Resource Manager plan
Where numa pg = 1, CPUs = 2
Replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
QMNC started with pid = 17, OS id = 7831
Tue juns 14 18:19:55 2011
Completed: alter database open

Note:

Alter database open
Beginning crash recovery of 1 threads
Started redo scan
Completed redo scan
Started redo application
Completed redo application
Completed crash recovery
SMON: enabling cache recovery
Successfully onlined Undo Tablespace 1
SMON: enabling tx recovery
Completed: alter database open

From the above steps, we can see three recovery terms:

Crash recovery
Cache recovery
Tx recovery

This is inconsistent with the Crash Recovery concept described in the official document. We will clarify these recovery.

Crash recovery includes scan and application for redo. It apparently completes the Rolling Forward rollback, the crash recovery in the alarm log is equivalent to the "cache recovery" described in the official document. We can regard "Completed crash recovery" as a marker of Roll-ahead. The tx recovery literally shows that it is actually a Transaction Recovery. tx recovery occurs after Undo Tablespace online (the prerequisite for Transaction rollback is that Undo is available ), before the data is opened ("Completed: alter database open "). Note that tx recovery is not required to be completed before the database is opened. It is only started by smon before the database is opened ("SMON: enabling tx recovery ").

The only question left is, What Is cache recovery here? Obviously it is not the "cache recovery" described in the official documentation, and almost no documentation introduces such a recovery operation, which is also the focus of this article.

Let's take a look at another demonstration. This demonstration shows that cache recovery still exists in the most common database that does not contain Crash Recovery:

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.

SQL> startup mount;
ORACLE instance started.
Total System Global Area 1065353216 bytes
Fixed Size 2089336 bytes
Variable Size 486542984 bytes
Database Buffers 570425344 bytes
Redo Buffers 6295552 bytes
Database mounted.

SQL> alter database open;
Database altered.

SQL> select * from v $ version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0-64bi
PL/SQL Release 10.2.0.4.0-Production
CORE 10.2.0.4.0 Production
TNS for Linux: Version 10.2.0.4.0-Production
NLSRTL Version 10.2.0.4.0-Production

SQL> select * from global_name;

GLOBAL_NAME
--------------------------------------------------------------------------------

========================== Alert. log =
Alter database open
Tue juns 14 18:43:52 2011
LGWR: STARTING ARCH PROCESSES
ARC0: Archival started
LGWR: STARTING ARCH PROCESSES COMPLETE
ARC0 started with pid = 14, OS id = 8133
Tue juns 14 18:43:52 2011
Thread 1 opened at log sequence 1005
Current log #3 seq #1005 mem #0:/flashcard/oradata/G10R2/onlinelog/o1_mf_3_6v34jpmp _. log
Current log #3 seq #1005 mem #1:/s01/flash_recovery_area/G10R2/onlinelog/o1_mf_3_6v34jpyn _. log
Successful open of redo thread 1
Tue juns 14 18:43:52 2011
ARC0: Becoming the 'no fal' ARCH
ARC0: Becoming the 'no srl' ARCH
ARC0: Becoming the heartbeat ARCH
Tue juns 14 18:43:52 2011
SMON: enabling cache recovery
Tue juns 14 18:43:53 2011
Successfully onlined Undo Tablespace 1.
Tue juns 14 18:43:53 2011
SMON: enabling tx recovery
Database Characterset is UTF8
Opening with internal Resource Manager plan
Where numa pg = 1, CPUs = 2
Replication_dependency_tracking turned off (no async multimaster replication found)
Tue juns 14 18:43:53 2011
Incremental checkpoint up to RBA [0x3ed. 624.0], current log tail at RBA [0x3ed. 944.0]
Tue juns 14 18:43:53 2011
Starting background process QMNC
QMNC started with pid = 15, OS id = 8135
Tue juns 14 18:43:53 2011
Completed: alter database open

Because it is clean shutdown, there is no crash recovery here. However, "SMON: enabling cache recovery" is also displayed here. It can be seen that cache recovery is a recovery operation that must be performed every time an instance starts instance startup. But the question is, what kind of objects does the Restoration Operation target?

1 2 3 Next Page