The bad news is, as discussed earlier, pre-Oracle9i Release 2 systems have a single redo allocation latch, making it much more likely to experience redo allocation latch contention. The good news is there are multiple redo copy latches, and by creatively adjusting the _log_small_entry_max_size parameter, we can influence the likelihood of a process having to acquire the redo allocation latch.

Think of this instance parameter as a fence. On one side of the fence, the allocation latch is used, as you would expect, for allocating space in the redo log buffer, and one of the redo copy latches is used while copying redo into the just-allocated space. On the other side of the fence is the redo copy latch, which is used to both allocate redo log buffer space and to copy redo into the just-allocated space! If the redo entry size is greater than the _log_small_entry_max_size value, the process will hop over the fence, using only one of the redo copy latches and thereby bypassing requesting the redo allocation latch. So, by reducing the height of the fence-that is, reducing the parameter value-the processes are less likely to request a redo allocation latch. This directly reduces redo allocation latch concurrency, which will reduce the likelihood of receiving the latch free wait event.

For Oracle9i Release 2 and later systems, Oracle provides multiple redo allocation latches. By simply increasing the instance parameter processes, the number of redo allocation latches is also increased. Sampling from multiple Oracle systems indicates that about one redo allocation latch is created for every eight defined processes. So, if your system has the processes instance parameter set to 2000, you can expect to see around 250 redo allocation latches. By increasing the number of redo allocation latches, redo allocation latch concurrency is increased, reducing the likelihood of sleeping while trying to acquire one of the redo allocation latches.