Oracle Redo Strand

Redo log is a important data to be used to recovery and some other advanced features. A redo entry involved the information about database changing. All of the redo entries should be writen into logfile finally. To avoid disk io waits, oracle allocated a log buffer from sga to cache the redo data. A redo entry is generated in PGA, then it be copied to log buffer by server process. When reach some conditions, LGWR will write the log buffer contents to the logfiles. Log buffer is shared by all of server processes, to protect it, the server process should first request the "redo allocation latch" to allocate buffer from it. Hence, in high concurrent OLTP system, we may observer the redo allocation latch contentions. Below is the flow of the redo be writen into log buffer:

shared strand

To reduce redo allocation latch waits, oracle introduced log buffer parallelism in 9.2. It split the log buffer into multiple small buffers, which are named strands (to distinguish from the private strands that will be instroduced later, we also call it "shared strands"). Each shared strand is protected by a redo allocation latch separately. With multiple shared strands, the log buffer allocation become parallelism from sequence, and redo allocation latch contentions reduced correspondly.

Shared strands number is controlled by the parameter log_parallelism, which is undocumented parameter in 10g, and obsoloted in 11g. After 10g, new parameter _log_parallelism_max define the max shared strands number, and _log_parallelism_dynamic identify if the shared strands number could be dynamiy.

For multiple CPU host, the default shared strands number is 2 if less than/equal to 16 CPU. If observed redo allocation latch contentions, should consider increase 1 strand for every 16 CPU, but should not more than 8. Besides, _log_parallelism_max could not larger than cpu_count.

Private strand

To reduce redo allocation lacth contention further, a new mechanism is introduced in 10g, which is Private Strand. Private Strand is the buffer allicated from shared pool instead of log buffer.

Redo/Undo mechanism is changed much by private strands. Every private strand is protected by a redo allocation latch. As "private", each strand only servers for 1 active transaction. The transaction that using private strand generate redo entries in private strand instead of PGA. The redo entried in private strand will be batch writen into logfile when flush or commit. If a transaction failed to request a private strand, it will request the shared privated as old mechanism. We can identify the transaction used private strands or not by the 13th bit of ktcxbflg in x$ktcxb.

The transactions using private strand will not request Redo Copy Latch and redo allocation latch of shared strand when generate Redo Entry, just request Redo Copy Latch before flush strand, thus reduced the contentions of those latches, also reduced the CPU workload.

Note: For those transactions failed get private strand, even though there is private strand available before transaction end, it will not request it.

Undocumented parameter _log_private_mul define the percent of logfile space (without the space reserved for log buffer) should be pre-allocate for private strands. We could calculate the limited private strands number under current logfile size.

After logfile switch (like checkpoint, all of private strand should be flushed into logfile before switch. We may found such information in alert log before the logfile switch entry, as "Private strand flush not complete", which could be ignored), oracle will re-allocate private strands base on current logfile size.

When pre-allocate private strands, oracle will choose the less number limited by the 2 factors just mentioned. However, as the logfile size could be changed online, the total size of private strands buffer in shared pool and the redo allocation latch number is allocated as active transaction number.

Hence, if logfile is large enough, and active transactios number setting is suitable, private strands will almost eliminate redo allocation latch contentions.