1. 当进程要修改某个data buffer block的时候，首先要获得该block buffer上的绝对锁；
2. 生成修改操作的redo record（现在进程pga中）和undo的信息，并且把redo record写到redo buffer中。
3. 以上操作完毕后，才开始修改buffer block。

RBA (redo byte address)
唯一识别某个redo record；由log sequence,block number,byte offset within the block组成。

Redo log Buffer

以os block 组成的临时存储redo record的内存池.同样日志文件也是由redo block组成，如下察看block size。

UET1>dbfsize /data/oracle/oradb/redo3/oradb_redo06.log

Database file: /data/oracle/oradb/redo3/oradb_redo06.log
Database file type: file system
Database file size: 40960 512 byte blocks

How to generate redo record
前台进程将pga中的redo record写到redo log buffer中需要事先分配空间。
1. Lock block buffer
2. Generate redo record in pga
3. Compute redo length and get redo allocation latch to allocate enough space in redo buffer
4. Get redo copy latch or redo writes latch to write redo record into redo buffer
5. Modify block buffer
6. Write log ahead.

How LGWR work
1. Get redo allocation latch,stop other Server Process to allocate space in redo buffer.
2. Search buffer that should be write into disk
3. Get redo copy latch,stop other server process to copy redo.
4. Update redo buffer header(lasted scn,redo block etc) in redo buffer.
5. Write redo into disk
6. Get off latches and alert other process to work

Redo latch

Redo copy latch 可以有多个
Redo allocation latch 只有一个
Redo writing latch 只有一个

全文简单解释与redo 相关的statistics和wait；总算理解了redo wastage

redo wastage
Number of bytes that was free in the log buffer when they were flushed to disk.
It is necessary to flush the log buffer when a transaction commits,
or log is switched.The name “wastage” is misleading, it is rather unused buffer space.

lgwr负责将redo 从redo buffer中写到redo log file里面。redo buffer 同cache buffer一样，都是由buffer block组成.通常redo buffer block是512bytes；
lgwr写的最小单位是redo buffer block.例如一个512bytes的redo buffer block里面只有300bytes redo，其余212bytes都是空的,
这时候lgwr写这个redo buffer block到redo log file,那么300bytes作为redo size ,212bytes作为redo wastage ；
根据规则，( redo size + redo wastage ）/ redo blocks written 就是计算redo buffer block 大小；同时redo log file也是由多个redo block组成,
每个redo block对应lwgr写的redo buffer block；也就是说100m的(archived ) log file里面，有很多空洞，它包括的redo log并没有100M,

http://www.itpub.net/showthread.php?s=&threadid=390058
http://www.itpub.net/showthread.php?s=&threadid=393948

The complete list of redo-related events is listed below. The important events are also marked.

log switch/archive

This event is waited when the DBA manually enters the command “ALTER SYSTEM ACRHIVE LOG CHANGE ”. If the log to be archived is in the current thread, then a log switch is requested and waited until it is done. Otherwise (the log to be archived is not in the current thread), this event is waited for 10 seconds.

log file sequential read

Any request to read from the redo log files will wait for this event. The read can be the redo records or the log file header. The p3 column indicates the number of blocks read and is set to 1 if the wait is for the log file header. Number of blocks to read in one batch is port specific and can not be tuned.

log file single write

This event is waited only when writing the log file header block. There are two places where the header block is written; when adding a new member file and when the log sequence number is advanced.The only contention reason could be the access time to the file, which can simply be resolved by reducing non-redo related activity on the disk or placing the redo files on faster disks

log file parallel write **

This is the main event waited while writing the redo records to the current log file. The call to write the log buffer is only made in LGWR and the write operation is parallelized per physical disk. However, the wait is not over until the last redo buffer makes it to the disk.

log buffer space **

This is the event kcrfws() waits on. From kcrfh.h:

/* Waiting for space in the log buffer because we are writing stuff into

* the log buffer faster than lgwr can write it out. Consider making the log

* buffer bigger if it is small, or moving the log files to faster disks

* such as striped disks.

*/

Each wait is normally 1 second, but in the case of a log switch it is 5 seconds.

log file switch (checkpoint incomplete)

log file switch (archiving needed)

log file switch (clearing log file)

switch logfile command

All four of these events are waited if the log to be switched into is not available yet. The first one (checkpoint incomplete) can be caused under heavy load when the checkpoint for the next log is not completed. The last three is generally caused by error conditions or manual intervention. For example, when the DBA enters the “ALTER SYSTEM CLEAR LOGFILE” command and the LGWR needs to switch to the log file being cleared, the third event (clearing log file) is waited. The wait time is 1 second.

log file switch completion

If the log file to be switched into is not available for the reasons not indicated by the previous 4 events, then wait for this event. This happens when the current log file is simply full. The LGWR needs to complete the writing to the current log file and open the new one (switch logfiles).

log file sync **

When a request is made to sync the redo up to a specific rba and the redo pointed at by that rba is not already on disk, LGWR is told to start a write that will include the redo. The time it takes for LGWR to complete the write and then post the requester is the “log file sync” event. Each user COMMIT or ROLLBACK must sync the redo with an infinite RBA, forcing a complete flush of the log buffer to the redo log file.

redo wait

This event is defined in Oracle8 but it is not used.

Here is the complete list of redo-related statistics and a brief explanation:

redo writes
redo blocks written
redo write time

All three of these statistics are calculated in kcrfwc(), at the end of the redo parallel write operation. These are the main redo statistics and are only updated by LGWR. No other calls are allowed to kcrfwc(). “Redo writes” is the number of times the log buffer is written and “redo blocks written” is the total number blocks written. The average blocks/write can be easily be calculated from these values. “Redo write time” is the total time it took to write all the redo to disk. In a way, this is the cumulative value of each “log file parallel write” wait time.

redo log space requests
redo log space wait time

These statistics show the number of times it was requested to allocate space in the redo file and the total time waited for it. These statistics are incremented only if space is not immediately available and we are waiting for a log switch. The number of requests is the sum of all “log file switch” events except for an “ALTER SYSTEM SWITCH LOGFILE” command.

redo size
redo entries

These statistics are calculated in kcrfwr() just before the redo record is copied into the log buffer. These numbers simply indicate how much redo is generated since the instance startup. “redo size” is in bytes, so the average redo information per redo record can be calculated easily. There are no events associated with these statistics.

redo small copies

Total number of entries of size <= log_small_entry_max_size. These entries are copied using the allocation latch only, without getting the redo copy latch. Although this eliminates some latch overhead, it may reduce concurrency on a multi-CPU system.

redo buffer allocation retries

This is the total number of retries necessary to allocate space in the redo buffer. Retries are needed because either the LGWR has gotten behind, or because an event (such as log switch) is occurring. While a process is retrying it frees the allocation and copy latches but has to acquire the “redo writing” latch. Latches will be discussed later in this lesson.

redo entries linearized

This is the total number of entries of size <= redo_entry_prebuild_threshold. When a redo entry is prebuilt, the contents are copied into a contiguous area in the PGA area so that a single memcopy() can be done to to copy them to the log buffer. This will increase the CPU time but the time to hold the redo copy latch will be shorter, hopefully increasing concurrency.

redo log switch interrupts

In an OPS environment, log switch is forced on the idle instances to minimize recovery time. This is the number of times another instance asked to advance the log.

redo wastage

Number of bytes that was free in the log buffer when they were flushed to disk. It is necessary to flush the log buffer when a transaction commits, or log is switched.The name “wastage” is misleading, it is rather unused buffer space.

Having a large value for this statistic will cause more redo log file space usage. This value does not need to be tuned unless disk space is a concern. Otherwise reducing the log_buffer will also decrease the value of this statistic. However, this might have an undesirable side effect and increase in “redo log space requests”

redo writer latching time

When LGWR is writing the log buffer, it has to get and release all copy latches to ensure nobody is writing in closed blocks. This is the time it takes for LGWR to get and release all the latches during log buffer flushing.

redo ordering masks

This statistics is only relevant in an OPS environment. The ordering of the redo records are based on the SCN and in some uncommon situations the current SCN (Lamport SCN) in the current instance might be less than the current (ordering) SCN. In this case a new SCN is required (through DLM). This statistics is the number of times that an SCN had to be allocated to force a redo record to have a higher SCN than a record generated in another thread using the same block.

redo synch writes
redo synch time

These two statistics are calculated in the buffer cache management routines rather than the redo routines. Normally redo is generated and copied into the buffer and it is written by LGWR in the background. “Redo synch writes” is incremented each time the redo records must be written out to disk due to a commit.“Redo synch time” is the time it takes for the “redo synch write” to complete.

ITPub博客

redo 体系结构

最新文章