| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: interaction between LGWR and DBWR
Umar,
I got e-mail from one DBA. I'll be free enough to put his answer here:
"There is a description in one of the manuals, but don't ask me which,
which covers this exactly as you have
surmised.
In fact, when DBWR has to write blocks for which the log is not on disc
DBWR calls LGWR to write first so that LGWR is always ahead of DBWR.
If memory serves correctly the statistics 'redo log synch writes'
is the one which tells you how many times this has happened. "
Manual (for Oracle 7.3) says that "rollback segments which contain DEAD transactions will be put as PARTIALLY UNABLE". So, I thought those rollback segments would not be flushed and "rolling forward" would use the other rollback segments.
I contacted Oracle help desk about this question because at the end I was not sure what's really going on. They told me: DBWR will never write down dirty buffers without initiating LGWR to write log buffers. So, according to them, situation where DBWR writes down dirty buffers before LGWR writes down redo entries is impossible.
I trust them, but I would like to see that written down in the manuals. That is important fact and I just don't know how they could have missed it ?!
Regards,
Tanya
Rolling Forward and Rolling Back
Database buffers in the SGA are written to disk only when necessary, using a least-recently-used algorithm. Because of the way that DBWR uses this algorithm to write database buffers to datafiles, datafiles might contain some data blocks modified by uncommitted transactions and some data blocks missing changes from committed transactions.
Two potential problems can result if an instance failure occurs:
Data blocks modified by a transaction might not be written to the
datafiles at commit time and might only appear in the redo
log.Therefore, the redo log contains changes that must be reapplied to
the database during
recovery.
Since the redo log might have also contained data that was not committed, the uncommitted transaction changes applied by the redo log (as well as any uncommitted changes applied by earlier redo logs) must be erased from the database.
To solve this dilemma, two separate steps are generally used by Oracle for a successful recovery of a system failure: rolling forward with the redo log and rolling back with the rollback segments.
The Redo Log and Rolling Forward
The redo log is a set of operating system files that record all changes made to any database buffer, including data, index, and rollback segments, whether the changes are committed or uncommitted. The redo log protects changes made to database buffers in memory that have not been written to the datafiles.
The first step of recovery from an instance or disk failure is to roll forward, or reapply all of the changes recorded in the redo log to the datafiles. Because rollback data is also recorded in the redo log, rolling forward also regenerates the corresponding rollback segments. Rolling forward proceeds through as many redo log files as necessary to bring the database forward in time. Rolling forward usually includes online redo log files and may include archived redo log files. After roll forward, the data blocks contain all committed changes as well as any uncommitted changes that were recorded in the redo log.
Rollback Segments and Rolling Back
Rollback segments record database actions that should be undone during certain database operations. In database recovery, rollback segments undo the effects of uncommitted transactions previously applied by the rolling forward phase.
After the roll forward, any changes that were not committed must be undone. After redo log files have reapplied all changes made to the database, then the corresponding rollback segments are used. Rollback segments are used to identify and undo transactions that were never committed, yet were recorded in the redo log and applied to the database during roll forward. This process is called rolling back.
Oracle can roll back multiple transactions simultaneously as needed. All transactions system-wide that were active at the time of failure are marked as DEAD. Instead of waiting for SMON to roll back dead transactions, new transactions can recover blocking transactions themselves to get the row locks they need. This feature is called fast transaction rollback.
 |
 |