Main content of Oracle redo entries

The primary function of Redo log is to restore very important data with a related advanced feature. An Oracle redo entry mainly contains all the information about Oracle Database changes caused by actual operations, all redo entries will eventually be written to the redo file.

Redo log buffer is a piece of memory allocated in sga to avoid performance bottleneck caused by Oracle Redo file IO.

A redo entry is first generated in the user memory (PGA) and then copied to the log buffer by the oracle service process. when certain conditions are met, the LGWR process writes the redo file. Because log buffer is a piece of "shared" memory, in order to avoid conflicts, it is protected by redo allocation latch. Each service process needs to obtain the latch before allocating redo buffer. Therefore, in oltp systems with high concurrency and frequent data changes, we can usually observe the waiting time of redo allocation latch.

The entire process of Oracle Redo writing to redo buffer is as follows:

Produce Redo Enrey in PGA-> service process obtains Redo Copy latch (multiple --- CPU_COUNT * 2)-> service process obtains redo allocation latch (only one) -> allocate log buffer-> release redo allocation latch-> write Redo Entry into Log Buffer-> release Redo Copy latch;

Shared strand

In order to reduce the redo allocation latch wait, the parallel mechanism of log buffer is introduced in oracle 9.2. The basic principle is to divide the log buffer into several small buffers, which are converted into strand (to distinguish them from the private strand that appears later, they are called shared strand ).

Each strand is protected by a separate redo allocation latch. The emergence of multiple shared strand makes the originally serialized redo buffer allocation a parallel process, thus reducing the rOracle edo allocation latch wait.

The initial data volume of shared strand is controlled by the parameter log_parallelism. In 10 Gb, this parameter becomes an implicit parameter, and the parameter _ log_parallelism_max is added to control the maximum number of shared strand; _ log_parallelism_dynamic controls whether to allow the number of shared strand to dynamically change between _ log_parallelism and _ log_parallelism_max.

 
 

  
  
HELLODBA.COM>select nam.ksppinm, val.KSPPSTVL, nam.ksppdesc   
  
  
2 from sys.x$ksppi nam,   
  
  
3 sys.x$ksppsv val   
  
  
4 where nam.indx = val.indx   
  
  
5 --AND nam.ksppinm LIKE '_%'   
  
  
6 AND upper(nam.ksppinm) LIKE '%LOG_PARALLE%';   
  
  
KSPPINM KSPPSTVL KSPPDESC   
  
  
_log_parallelism 1 Number of log buffer strands   
  
  
_log_parallelism_max 2 Maximum number of log buffer strands   
  
  
_log_parallelism_dynamic TRUE Enable dynamic strands   
 
 

The size of each shared strand = log_buffer/(number of shared strand ). The strand information can be found in table x $ kcrfstrand (including shared strand and the private strand introduced later, which exists after 10 Gb ).

 
 

  
  
HELLODBA.COM>select indx,strand_size_kcrfa from x$kcrfstrand where last_buf_kcrfa != '00';   
  
  
INDX STRAND_SIZE_KCRFA   
  
  
0 3514368   
  
  
1 3514368   
  
  
HELLODBA.COM>show parameter log_buffer   
  
  
NAME TYPE VALUE   
  
  
log_buffer integer 7028736  
 
 

For the number of shared strand settings, the maximum value of 16 CPUs is 2 by default. When Oracle redo allocation latch waits in the system, you can consider adding 1 strand for every 16 CPUs added, the maximum value cannot exceed 8. And _ log_parallelism_max cannot be greater than cpu_count.

Note: In 11g, the parameter _ log_parallelism is canceled. The number of shared strand is controlled by _ log_parallelism_max, _ log_parallelism_dynamic, and cpu_count.

Private strand

To further reduce Oracle redo buffer conflicts, a new strand mechanism-Private strand was introduced in 10 Gb. Private strand is not divided from log buffer, but a piece of memory space allocated in the shared pool.

The above content is an introduction to part of the Oracle Redo parallel mechanism. I hope you will have some gains.