Tuning Recovery - Expert Oracle RAC Performance Diagnostics and Tuning - page 318

Recovery of Online Redo Log: Thread 2 Group 4 Seq 4 Reading mem 0
Mem# 0: +DATA/rac/onlinelog/group_4.267.781699385
Thu Apr 10 09:01:36 2014
minact-scn: master found reconf/inst-rec before recscn scan old-inc#:6 new-inc#:6
Thu Apr 10 09:01:42 2014
Completed redo application of 25.25MB
Thu Apr 10 09:03:14 2014
LMON (ospid: 5187) waits for latch 'enqueue hash chains' for 80 secs.
Thu Apr 10 09:07:04 2014
.......
Thu Apr 10 09:13:44 2014
GES: System Load is HIGH.
GES: Current load is 31.70 and high load threshold is 10.00
Thu Apr 10 09:13:48 2014
Completed instance recovery at
Thread 2: logseq 4, block 68453, scn 1495515
3745 data blocks read, 12020 data blocks written, 34017 redo k-bytes read
Thread 2 advanced to log sequence 5 (thread recovery)
Thu Apr 10 09:14:00 2014
minact-scn: master continuing after IR
minact-scn: Master considers inst:2 dead
Thu Apr 10 09:14:20 2014

10. During remastering of GRD resources and when the GCS services managed on the failed

instance get relocated, instance recovery is paused.

11. Oracle performs recovery by traversing through the redo logs in two passes. It's called

the rollforward and rollback phases of recovery. During rollforward recovery, all dirty
blocks affected by committed transactions are written to the datafile; and during rollback
recovery, all blocks updated on the disk as a result of transactions that have not been
committed are rolled back.

12. Oracle starts the database recovery process and begins the cache recovery process, that

is, rolling forward committed transactions. This is made possible by reading the redo log
files of the failed instance. Because of the shared storage subsystem, redo log files of all
instances participating in the cluster are visible to other instances. This makes any one
instance (nodes remaining in the cluster and were started first) that detected the failure to
read the redo log files of the failed instance and start the recovery process.

• Cache recovery is the first pass of reading the redo logs by

SMON on the active instance.
The redo logs files are read and applied to the active instance performing the recovery
operation through a parallel execution.

• During this process,

SMON will merge the redo thread ordered by the SCN to ensure that
changes are applied in an orderly manner. It will also find the block written record (BWR)
in the redo stream and remove entries that are no longer needed for recovery because
they were PIs of blocks already written to disk. SMON recovers blocks found during this
first pass and acquires the required locks needed for this operation. The final product of
the first pass log read is a recovery set that only contains blocks modified by the failed
instance, with no subsequent BWR to indicate that the blocks were later written. The
recovering SMON process will then inform each lock element's master node for each block
in the recovery list that it will be taking ownership of the block and lock for recovery.
Other instances will not be able to acquire these locks until the recovery operation is
completed. At this point, full access to the database is available.