| 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: Log Switching
On Mon, 03 May 1999 20:50:10 GMT, Jonathan Ingram
<jonathan.ingram_at_miname.com> wrote:
>Jeremiah Wilton wrote:
>
>> Hmm, what is the LOG_CHECKPOINT_TIMEOUT parameter for then? Wouldn't it
>> just do the same thing as your cron job?
>
>A checkpoint is not the same as a log switch. Setting LOG_CHECKPOINT_TIMEOUT merely
>forces the database to perform extra checkpoints; it does not force a log switch to
>occur. A checkpoint occurs when a log switch occurs by definition, but the reverse
>is not true.
>
>Setting LOG_CHECKPOINT_TIMEOUT does causes checkpoints to occur at a specified
>number of seconds. When a checkpoint occurs, LGWR writes the contents of the redo
>log buffer to the online redo log.
This is incorrect. Writing the contents of the redo log buffer to log files is not directly connected to the checkpoint event - redo log is written constantly (fixed timeout every couple of seconds, after each commit and when DBWR writes dirty buffers to the data files). During checkpoits only the file headers are updated and a list of dirty buffers is collected so that DBWR can flush all the dirty buffers to the disks. When this happens, the changes prior to that moment are not needed any more in case of a crash recovery. And that is the main and the only purpose of the checkpoint.
> Only if the checkpoint is the result of a log
>switch will ARCH generate an archive log file from the previously active online
>redo log file (once the file is marked as inactive in v$log).
>
>To the best of my knowledge, there is *no* parameter or configuration setting in
>Oracle7 or Oracle8 that can be configured to force a log switch to occur. Oracle
>recommends in the performance tuning classes for Oracle7 and Oracle8 that you
>configured LOG_CHECKPOINT_TIMEOUT and LOG_CHECKPOINT interval so that checkpoints
>occur only when the online redo logs are switched.
IMHO there should be no reason for forcing explicit log switches (except during performing backups) and hence no need for such special initialisation parameter.
Your point was:
>> If you have disk failure and your online redo logs are lost or corrupted by the
>> failure, you have lost everything that occurred since the last log switch.
True, but this should not happen. That's why Oracle allows (and strongly recomends) multiple redo log group members, located on different physical disks. Ok, you might say, all of those disks could be lost because of some severe crash. But then, it might (perhaps with the similar probability) also cause the loss of all your archived logs, in which case you have lost everything since your last move of archived logs to the tape or some other offline storage. And more frequend log switches can't help you under this extremely black scenario.
So if your logfile group members are on different disks (and possibly controlers), then you should not loose any of your data except the uncommited transactions (which you lose in any case, no matter if these transactions have allready be written to the log files from the redo buffer or not). The size of the redo log files and/or the frequency of the checkpoints only define the longest time needed to perform an instance recovery, not the amount of data that might be lost in a case of a crash.
>Jonathan Ingram
>jonathan.ingram_at_miname.com
>Remove the first "m" from "miname.com" to reply.
Regards,
Jurij Modic <jmodic_at_src.si>
Certified Oracle7 DBA (OCP)
 |
 |