Database Reference
In-Depth Information
About Instance Recovery
We mentioned instance recovery earlier, and there may be a question or two about
instance recovery on your OCP exam, so let's talk about that for a second. In this
section, we will discuss:
Checkpoints
The system change number
Instance recovery
Fast-start fault recovery
Tuning database instance recovery times
Monitoring cache recovery
The mean time to recover advisor
Checkpoints The reason there is a variance between the current state of the database and
the state of the database as represented in the database data files is that Oracle reduces the
writes to disk in order to improve database performance. The DBW process typically writes
to the database data files in a lazy fashion. This is so that the IO associated with the writes by
the DBW processes will be minimized. Each time a write occurs, this is called a checkpoint.
Checkpoints occur irregularly most of the time, triggered by various events. It is quite possible
that a changed block in memory will not be written to disk for a period of seconds or even
minutes after a commit occurs. Thus, a commit does not cause a checkpoint. A commit only
causes the redo change records (called change vectors) that have been generated in the redo log
buffer to be flushed to the online redo log of the database. Since the online redo logs reside on
disk, they provide the persistent image that, when added to the database data files, represent
the most current image of the database to the most recent commit.
The System Change Number Oracle keeps track of all of the activity in the database
through the use of the system change number (SCN). The SCN is a counter, and its job is to
keep track of everything going on inside the database and assign it a temporal identity. This
serves to keep transactions that occurred in a particular order in the same order later down
the road (such as during recovery). You need to preserve the order of transactions because
of dependencies that occur between transactions. For example, if you have a parent table
and a child table, you want to make sure that during recovery all insert s into the parent
table occur before insert is into the child table. This is because of the foreign key constraint
that exists between the two tables to ensure the integrity of that parent/child relationship.
The SCN helps Oracle to track the temporal flow of those changes, and thus the parent
table insert will have a lower SCN than the child table insert . As a result, in the end, all
is right with the world.
SCNs are loosely coupled with time. Thus, 12:30 p.m. local time would be associated with a
specific SCN in a given individual database. The thing to remember is that 12:30 p.m. local
time will most likely be associated with a different SCN in each database, so the coupling is
very loose. The concept of the SCN is very important because there may be times when you
Search WWH ::




Custom Search