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.

As with most latches, it is very common for the operating system to be experiencing a raging CPU bottleneck. While increasing CPU capacity is a valid solution and will most likely enable more work to flow through Oracle, simply adding more redo allocation latches to the Oracle system will most likely solve the problem, without requiring any operating system or application-related changes.