You were brought to this page based on an internet search
and as a free service to Oracle DBAs.
The text below is an except from the book,
Oracle Performance Firefighting, written by
Craig Shallahamer of
OraPub, Inc.
Figures and tables are not included on this page, only their reference.
To order the book in either print or PDF form, click
here.
©2009, 2010 by Craig Shallahamer. This is copyrighted material.
PleaseOut of respect for those involved in the creation of the book and also for
their familes, we ask you to respect the copyright both in intent and deed. Thank you.
-------------------------------
To complete a database checkpoint, the database writer must write every associated dirty buffer to disk, and then every database file and control must be updated with the latest checkpoint number. Keep in mind that regardless of the archive mode, Oracle promises that committed transaction data will reside in an Oracle database file, either in .dbf files or redo log files.
Using Figure 8-18 as a reference, suppose the log writer (LGWR) background process just finished writing to redo log group RLOG 100, and is ready switch to redo log group RLOG 200 and begin writing. However, the database writer background process (not shown) is still finishing the checkpoint related to the redo entries in redo log group RLOG 200. If the log writer background process were to switch and begin writing into redo log group RLOG 200, it would overwrite committed transaction details that at that time may only reside in the buffer cache. If the instance crashed, the committed transactions, which reside only in the buffer cache, would be lost forever! To prevent this, in this example, the log writer background process will wait to switch and wait to begin writing into redo log group RLOG 200 until the database writer background process has finished writing all the dirty buffers related to the checkpoint. While the log writer background process is waiting (effectively stopped writing) it will post a log file switch (checkpoint incomplete) wait event.
The solution is very simple. Add more redo log groups to give the database writer background process more time to complete the checkpoint. If the log switch rate is uncomfortably fast,8 then create new, larger redo log group members, and drop the old redo log groups. No downtime is involved when adding or dropping the online redo logs.
©2009, 2010 by Craig Shallahamer. This is copyrighted material.
PleaseOut of respect for those involved in the creation of the book and also for
their familes, we ask you to respect the copyright both in intent and deed. Thank you.
|