| From: | Steve Adams |
| Date: | 06-Nov-2001 09:26 |
| Subject: | log_simulteneous_copies parameter and redo allocation latch |
|
|
It's still there. It's just gone underground. However, changing it has little impact on redo allocation contention, and the effect can be the converse of what you might expect. If you have some contention on both the redo allocation and redo copy latches then making more copy latches available can increase the simultaneous load on the allocation latch which results in a net performance loss. Indeed, it can sometimes help to throttle down the number of copy latches to introduce some contention there as a way of reducing the severity of redo allocation latch contention. However, your first approach should of course be to minimize commits and allow LGWR to do as much of its work in the background as possible. Also beware of doing incremental checkpoints too intensively, because writing hot blocks forces DBWn to sync LGWR regularly. For that reason, the size of the cache is a factor as well, as is the size of the log buffer of course. Also, the redo allocation latch is fairly sensitive to general latch tuning using things like the spin count. However, the details are platform specific.
|
![]() |
Note 94271.1 in MetaLink says that log_simulteneous_copies no longer exists. I have an 8.1.7.2.1. database here with some waits for the redo allocation latch. Normally I would have increased the value, and activated copy latches for the redo log buffer. Is there an equivalent parameter in 8i to the above, or do I have to live with the way Oracle configures itself by default?
|