An overview of internal management mechanism of log buffer in Oracle

The internal management of the log buffer is divided into two parts, one being the build redo record and the other being the redo record writing to the online log file. These two parts are not isolated and unrelated. During the process of generating a redo record, LGWR may be triggered to write the redo record to the online log file.

We first use an example to illustrate the procedure in the log buffer, and use [file#, blk#] to represent a block of data, file# to represent the file number, and blk# to represent the data block number.

Suppose session 1 emits an UPDATE statement: Update redo_test set name= ' CDF ' where id=1;

Oracle first finds the data block where the id=1 resides (assuming [file#4,blk#120]) into the buffer cache, and then finds an available rollback segment block (assuming [file#2,blk#19]), putting the old value ' abc ' into the block, Generate a redo record at the same time. The ' CDF ' is then placed in the table's data block and the redo record is generated. At this point the structure of the log buffer can be simply represented as the following (we know in front of the memory structure of the log buffer that the most important columns in the redo record are those listed below). Also, the following line represents a redo record):

Line number transaction ID file# block# Row column value

1 T1 2--ABC

2 T1 4 1 2 CDF

This assumes that session 2 emits additional UPDATE statements: Update t set c1=10 where c1=9;

In the same way, Oracle finds the data block (assuming [file#5,blk#200]) into the buffer cache and finds the rollback segment data block (assuming [file#2,blk#30]) to store the old values, generate Redo records, update the data blocks of the table, and generate Redo records again. The structure of the log buffer is similar to the following form:

Line number transaction ID file# block# Row column value

1 T1 2--ABC

2 T1 4 1 2 CDF

3 T20 2 30--9

4 T20 5 200 20 1 10

At this point, Session 1 also emits an UPDATE statement: Update redo_test set name= ' Xyz1 ' where id=2, and commits (commits). The same way to handle rollback segments and data blocks and generate redo records. Suppose the log buffer is generated at this time:

Line number transaction ID file# block# Row column value

1 T1 2--ABC

2 T1 4 1 2 CDF

3 T20 2 30--9

4 T20 5 200 20 1 10

5 T1 2--ABC

6 T1 4 2 2 xyz1

7 T1 Commit SCN timestamp

See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/database/Oracle/

At this point we can note that the submit tag is also recorded in the redo record. Each time a commit is made, a SCN number is generated, the smaller the SCN number, the earlier it occurs, and the more the redo records it belongs to are in the front. Once a user issues a COMMIT statement, the system triggers the LGWR process. At this point, the LGWR process writes all of the redo records shown above to the online log file. Note that it also includes transaction T20 that have not yet been committed.

The SCN is the atomic clock within the Oracle database, which can be considered to be a 9-digit time message that is accurate to the second. The SCN records the sequence of events that occur within the database, such as DML, Commit, DBWN, and so on, which can cause the increase of the SCN number.

In the process of LGWR writing these redo records, another session issues an UPDATE statement and submits it. The log buffer is now assumed to be as follows:

Line number transaction ID file# block# Row column value

1 T1 2--ABC

2 T1 4 1 2 CDF

3 T20 2 30--9

4 T20 5 200 20 1 10

5 T1 2--ABC

6 T1 4 2 2 xyz1

7 T1 Commit SCN timestamp

The redo log above is being written by LGWR and the following redo logs are generated when LGWR is written

-----------------------------------------------------

8 T20 2 39--289

9 T20 5 498 220 3 190

2 T9-HHH

One T9 9 9 xxx

T9 Commit SCN Timestamp

T18 2 189--18

10 29 300 10 20 T18

T18 Commit SCN Timestamp

When LGWR writes the first batch of redo records (lines 1th through 7th), it immediately starts writing the second batch of Redo records (lines 8th through 15th). Note that there are two commits in the second batch of Redo records, but the LGWR are not divided into two writes, but they are written all at once. The log buffer memory for this section is freed when the LGWR is finished writing the change vectors for lines 1th through 7th, and can be overwritten by the newly generated redo record.