Re: Redo Log question
Date: 1996/01/24
Message-ID: <Pine.SUN.3.91.960124150358.5938C-100000_at_seatimes>#1/1
On 22 Jan 1996, Parris Geiser wrote:
> Our application has peak periods of heavy updates. During that time
> a large number of redo logs are generated. The cpu for writing
> these logs takes away from processing and reduces the thruput.
> Currently we have 3 logs of 10Megs. The question is:
> would it be better to have fewer smaller logs, e.g., 10 each 1M.
> Or, increase the size of the log file to handle the peak period
> within one log file, e.g., 3 logs of 50M?
First, look in the alertSID.log file to see if there is a message about not being able to switch the thread to a new log. It will make some mention about a checkpoint in progress. If so, then you need to add another group of logs.
Second, when you say three logs, I presume you mean three groups of logs (with redo log mirroring of two to three members per group)?
I would add a fourth group of logs at 10M, then check if the checkpointing is taking away from the log writing. If so, then I'd set the initSID parm to allow the CKPT process to run seperate from the LGWR process. Finally, if it's copying the redo log to the archive that is causing the slowdown, then play with the two initSID parms that affect the archival performance.
CHECKPOINT_PROCESS = TRUE <<You should set this to true only if
the LGWR process performance takes a significant hit during checkpointing>> LOG_BUFFER = 65536 <<or higher is not unreasonable on a busy system.>> LOG_ARCHIVE_BUFFERS = x <<Play until the performance is right>>
In general, make LOG_BUFFER as big as needed and let LOG_ARCHIVE_BUFFERS default. See chapter 17 in the Administrator's Guide.
+----------------------------------------------------+ | Steve Butler Voice: 206-464-2998 | | The Seattle Times Fax: 206-382-8898 | | PO Box 70 Internet: sbut-is_at_seatimes.com | | Seattle, WA 98111 Packet: KG7JE_at_N6EQZ.WA | +----------------------------------------------------+All standard and non-standard disclaimers apply. All other sources are annonymous. Received on Wed Jan 24 1996 - 00:00:00 CET