Shulou(Shulou.com)05/31 Report--

How to understand the internal process of redo and lgwr, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain for you in detail, people with this need can come to learn, I hope you can gain something.

Oracle adopts mixed logging mode, which takes blocks as units, that is, dba + sql, which can avoid recording the whole block and recover quickly.

The granularity is at the block level (like physical logging), so one operation is stored for each individual block change

A large transaction can be composed of multiple mini-transaction, that is, redo record, and each record can be composed of multiple change vector; commit/rollback corresponds to a single redo record

Each redo record contains one atomic operation, one change vector corresponds to only one data block, and the change vector is generated before the block is actually modified.

When the transaction commits, the generated redo+undo and commit record are written to the redo log file, while the transaction table of rollback segment header is updated

Note: temporary tables only record undo

There are three kinds of latch in Redo

1 Copy, multiple can be set via _ LOG_SIMULTANEOUS_COPIES

2 Allocation, only 1.

3 there is only one Write

Generation of REDO

Redo is generated in PGA first, and the copy latch--allocation latch is obtained in turn. The redo is written to log buffer and then the block is modified. Lgwr gets the write latch when refreshing redo buffer to avoid multiple refreshes at the same time.

The specific steps are as follows

1 pin lives in buffer block in exclusive mode

2 build change vector in PGA and combine it into redo record, which is completed by kconew () / kcoadd ()

3 call kcrfwr () to write record to log buffer:

Calculate the amount of space occupied by record

Assign SCN

Get copy latch and verify SCN

Get allocation latch to verify whether there is enough space in log buffer/file. If so, release allocation latch and write redo to log buffer, otherwise release allocation/copy latch and inform LGWR to log flush/switch at the same time.

Note: in order to prevent multiple processes from telling LGWR to refresh redo or switch log files at the same time, write latch (only 1) is introduced. Only after obtaining this latch can you proceed to the next step.

4 write redo record to log buffer and then release copy latch to check whether the trigger LGWR threshold has been reached

5 change buffer block

Nologging

Redo record is still recorded in this mode, and the change vector types under it are all INVALID;. Each record can correspond to multiple data blocks, and the corresponding data blocks will be identified as soft-corrupt when the redo is applied.

LGWR trigger threshold

1 triggered by foreground process: insufficient log buffer space; transaction commit

2 log buffer full 1 beat 3

3 redo exceeds 1m

4 3 seconds timeout

5 Log switching

6 redo thread shutdown

LGWR trigger process

1 get write/allocation latch, the former prevents LGWR from being requested multiple times, and the latter prevents redo space from being allocated to the foreground process

2 determine the range of log buffer to be written (from the beginning to the buffer to be refreshed) and assign a new SCN (avoid using the same SCN twice for flush)

3 release allocation latch

4 calculate the number of redo write required, because the log buffer is circular, so write at most twice (distributed at the beginning and the end)

5 calculate target RBA and improve incremental checkpoints according to log_checkpoint_interval

6 release write latch

7 make sure that the log buffer to be written is copied, that is, wait for all copy latch to be released

8 LGWR updates SCN and checksum for redo block header (optional)

9 perform disk write, but modify _ lgwr_async_io to enable asynchronous IO

Group submission

Lgwr received a request at C1 and added c2/g1/c3 when starting to refresh log buffer. At this time, you need to wait for c3 to finish writing (release redo copy latch) and refresh it together with c3.

Common redo wait events

Log file parallel write- is triggered by lgwr and writes redo record to the current log file, whose parallelism is determined by the number of physical disks

Log file sync- is waited by the foreground process from commit/rollback until lgwr writes the log to disk and notifies the requesting process

There is not enough space in log buffer space- log buffer to store the newly generated redo, indicating that the writing speed of lgwr is slower than that of redo generation.

Log file switch- is divided into checkpoint incomplete and archiving needed

Log file sync process

Which foreground processes will lgwr post?

When lgwr refreshes the log, it will post the corresponding foreground process (wakeup) to continue to work, so how can lgwr determine which foreground processes should be wakeup?

The meaning of the p1 parameter waiting for log file sync is: P1 = buffer# in log buffer that needs to be flushed

When lgwr refreshes the buffer, it scans the list of active sessions to see which sessions are waiting for log file sync, and the buffer# of the session is less than or equal to the maximum value of the log buffer it refreshes, and these sessions will be wakeup.

Lgwr file sync and buffer busy wait

The stack call of the transaction commit is as follows

Is ktcCommitTxn= > ktucmt = > kcbchg = > kcbchg1_main = > kcrfw_redo_gen = > kcrf_commit_force

Kcbchg== > block change, why does block change happen? Because commit needs to immediate block cleanout the block in Buffer Cache, exclusive mode pin is needed during this period

If another session accesses the block at this time, it will wait for buffer busy wait.

Http://www.askmaclean.com/archives/why-slow-redo-write-cause-buffer-busy-wait.html

Archive log process

1 ARCH reads control files to determine the log files to be archived

2 allocate archive memory _ LOG_ARCHIVE_BUFFERS * _ LOG_ARCHIVE_BUFFER_SIZE

3 Open all members of the log group to be archived as read-only (read log buffer in turn) and verify log file header; if db_block_checksum=true each log block will also verify checksum

4 create and open an archive log file

5 copy logs from online log to archive log in a circular manner, performing sanity check for each buffer

Close online log and archive log after execution

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.