| 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: archive log
On 5 Dec 1997 06:09:06 GMT, "Mike heydon" <pgbison_at_iafrica.com> wrote:
>
>> but for some reason, after archivelog is enable the system seems to be
>> very slow...
>> does the archivelog generally use a lot of system resources?
>>
>> is there a way to set it so it doesn't uses alot of system resource?
>
>One of the major causes of poor system peformance with archiving is
>CHECKPOINTS. A checkpoint will occur at every redo log switch or in
this is not accurate. Checkpoints happen in NOARCHIVELOG and ARCHIVELOG mode. The big difference between ARCHIVELOG and NOARCH from a processing perspective is that after a REDO log file is filled, it will be copied elsewhere. If they experience issues with archive log mode, they are probably experiencing some amount of disk contention (eg: they might be copying the redo log into another directory on the same disk -- introducing massive contention between LGWR and ARCH and if they have any datafiles on this same disk, adding DBWR to the mix).
Checkpointing and ARCHIVELOG don't have anything to do with eachother.
>accordance to the log_checkpoint_interval and log_checkpoint_timeout. When
>Oracle is performing a checkpoint NOTHING else can happen as it is ensuring
>that whatever is in memory in the SGA is written out to disk. If
>checkpoints are happening too frequently then you will have a performance
>penalty.
>
When Oracle performs a checkpoint, work continues as normal, everything - reading/writing/commtting/etc takes place during a checkpoint. The only time the database stops during a checkpoint is when you have insufficient log space allocated. Oracle must finish the checkpoint before you can reuse a log file. In general, checkpionts do not preclude work from occuring. Only when you attempt to reuse a log file, and the checkpoint has not had time to complete in the background, will work be suspended.
IMO, if checkpoints aren't happening frequently enough, you can introduce this problem artificially. If you don't keep DBWR, the process that does checkpoints, busy often enough, it could end up with way too much cached blocks to checkpoint in a sort period of time.
>How to rectify this ?
>
>Set parameter log_checkpoints_to_alert = true in init ora file. This will
>give you the interval that checkpoints are occuring in the alert log.
>They should ideally be occuring every 30-60 minutes. If they are not then
>your redo log files are probably too small.
>Increase their size and set log_checkpoint_interval = 0 (Disable timed
>checkpoints) and set log_checkpoint_interval = xx where xx is a size BIGGER
>than your redo log size. This will ensure that checkpoints ONLY occur when
>a redo log switch occurs. The frequency of log switching and checkpoints
>are now controllable by the size of the redo log files.
>
>Other thingies .....
>
>Make sure checkpoint_process = true in init ora file. This reduces the work
>LGWR (Log writer) has to do. If this parameter is NOT set the LGWR has to
>do Checkpoints as well as writing the redo logs.
>
DBWR does checkpoints. LGWR updates datafile headers. Enabling CKPT will remove the burden of updating datafile headers from LGWR. DBWR does the actual checkpointing of information. The effect of CKPT process will be anything from nothing (if you have few datafiles, this setting doesn't do much) to allowing processing to go a little faster (the overhead of LGWR updating the datafile headers is fairly small and is a function of the number of datafiles).
>Check the alert log to ensure that LGWR is NOT waiting for ARCH (Archiver
>process). If it is then a peformance bottleneck is happenening. The
>solution to this is to ADD more redo logs so that LGWR is always able to
>write to a redo log. It cannot write to a redo log if ARCH is busy
>archiving it. The normal amount of redo logs when Archiving is active is 4
>to 5.
In addition to the above, try to make it so ARCH, LGWR and DBWR are not contending with eachother. If ARCH can't keep up, its generally because of an IO bottleneck unless you are creating massive amounts of log continously (loading, indexing). It would be nice if
Then, lgwr would write to redo-disk-1 while arch would read redo-disk-2 and write arch-disk. dbwr would write data disks. When lgwr switches, we would hope arch was able to keep up and lgwr would write redo-disk-2 while arch would now read redo-disk-1 and write arch-disk.
>
>Good Luck
>Mike Heydon
Thomas Kyte
tkyte_at_us.oracle.com
Oracle Government
Bethesda MD
http://govt.us.oracle.com/ -- downloadable utilities
Anti-Anti Spam Msg: if you want an answer emailed to you, you have to make it easy to get email to you. Any bounced email will be treated the same way i treat SPAM-- I delete it. Received on Mon Dec 08 1997 - 00:00:00 CST
 |
 |