Re: DB writer takes over?

Hi Jim,

This is probably not the DBWR, but the LGWR. Whether you like or not you can't turn of redo log writing, aka after image journaling. You should also run in archivelog. One day you will probably regret it. That's said let me explain why you are experiencing problems. The redo log files are written in a continuous sequential stream. Every time a log file has been completely filled, a switch occurs. In special situations it can happen there is a burst of writes, and ALL online redo log files are filled at about the same time. This will cause the database to hang, probably this occurs also when running in noarchivelog. It looks like you need to make your online redo log files bigger, and/or make sure the init.ora parameter log_checkpoint_interval is bigger than the size of your redo log files. Log file switches are logged in the datadictionary and in the alert.log and in the lgwr trace file. It should be easy to verify how ofte they occur now.
Why is in not the DBWR. The DBWR will come into play as soon as db_block_write_batch blocks are written. This parameter is by default half of db_multiblock_read_count which usually is 16. So as soon as 8 blocks are dirty the DBWR will become active. If you increased this parameter you should lower it. It is very likely in your situation the DBWR will become active immediately.

Hth,

Sybrand Bakker, Oracle DBA

Jim Kuschill wrote:

> We've got a database with of about 15GB, spread moderatly over several
> drives, on a mid-size Unix box with 2 CPUs. We've allocated 50,000
> buffers for the hummer, and are not running with archiving. Everything
> runs quite well until we try to do some batch work and post a lot of
> blocks.
>
> Now, we fully expect things to get a little herkey-jerkey, but what
> happens doesn't seem quite right...
>
> The batch update runs along just fine until it apparently runs out of
> blocks. The DB writer fires up ... and locks up the database until it's
> done with its work!
>
> Is this normal? I know there are about a Sagan's-worth of tuning
> paramters, but any clues which might get our DB writer to play nicer?
>
> kusch_at_frequencymarketing.com

Received on Sat Nov 14 1998 - 10:20:30 CST