Understanding Redo (2) Redo content: Change vector and redo entries

The redo log file is composed of redo records (also known as redo entries. A redo record is composed of a group of change vectors.

Redo record: a set of change vectors. Each redo record is composed of multiple change vectors. During the restoration process, Oracle will ensure that a transaction is either completely restored or not restored. It is actually done by recovering all the change vectors in the redo record. If one change vector fails to be restored, all the changes in the redo record
Vector will fail. Therefore, redo record is the minimum recovery unit for database changes.

Change vector: indicates a change made to a data block in the database. A cv only applies to changes of one data block. a cv only contains one change.

The data block can be:

Data Block
Rollback block undo Block
Data Segment header block data segment header Block
Rollback segment header block undo header Block

The structure of the Change vector, which contains a header information and body information.
The Change Vector header mainly includes:
Change # N: Number of the Change vector in the same redo record
Typ: change type
CLS: the type of the block corresponding to this modification, which is equal to x $ BH. Class.
AFN: absolute file number
DBA: rollback block address
SCN: the SCN at the time of Modification
SEQ: the numbers of different modifications to the same SCN are seq numbers. Note: in Oracle, the nature of serial numbers is that different serial numbers correspond to different contents.
OP: operation code, which consists of two parts: Layer Code. sub code

The Change Vector body mainly includes:
1) Change the version number of the data block: Oracle will copy the version number from the data block when the change vector is created. During the rollback, the Change Vector recorded in the redo log file is used, based on the SCN comparison, the data file is submitted to the relevant data file, so that the status of the data file is rolled forward, the version of the recovered data block plus one (the data block of the temporary segment does not generate the Change Vector ). Note: re-use Redo For recover. This is a binary operation process and does not produce SQL!
2) DBA: roll back the block address
3) transaction operation code
4) updated data

 

Each time you modify these blocks in cache buffer, you must first generate the corresponding change vector in PGA, and then copy the data from server process to SGA redo log buffer. The user process generates a redo entries when modifying data. In this case, the redo logs are stored in the PGA, And the redo copy latch is required to copy the redo logs in the PGA to the redo log buffer, lgwr can write the target log buffer block to the redo log file only after the process copy is complete. Redo
Entries occupies sequential space in the memory, and is written to redo log file in order. The size of entries is different from that set by the db_block_size parameter, it is fixed in Oracle source code and related to OS. Most operating systems are 512 bytes. Only when all the redo records contained in a firm are securely landed on the disk can the user process be notified of commit completed. Redo
The redo records in log buffer can be completely written or not written.

Because user process writes data to redo log buffer, latch protection is required:
Redo copy latch: Write redo to redo log Buffer
Redo allocation latch: Controls log Buffer Allocation
Obtain redo copy latch when redo copy from PGA to log buffer, obtain redo allocation latch, allocate redo log buffer space, and release redo allocation latch after allocation, the server process then copies the redo information in the PGA to the redo log buffer. After OK, the redo copy latch is released.

 

Below is a small experiment.

1) connect with HR and create a table

SQL> conn HR/HR is connected. SQL> drop table T1; drop table T1 * 1st row error: ORA-00942: Table or view does not exist SQL> Create Table T1 (a number); table created.

2) Check the current SCN.

SQL> select dbms_flashback.get_system_change_number from dual;GET_SYSTEM_CHANGE_NUMBER------------------------                 1584957

3) execute an insert statement and use this statement for analysis:

SQL> insert into T1 values (1); 1 row has been created. SQL> commit; submitted completely. SQL> select dbms_flashback.get_system_change_number from dual; get_system_change_number ---------------------- 1584996

4) with these two SCN values, we will dump the current redo log:

SQL> alter system dump logfile 'G: \ oracle \ product \ 10.2.0 \ oradata \ orcl \ onlinelog \ o1_mf_1_80yr2hgq_.log '2 SCN min 1584957 SCN Max 1584996; the system has changed. SQL> select spid from V $ process where ADDR in (select paddr from V $ session where Sid in (select Sid from V $ mystat where rownum = 1); SPID------------------------1324

5) the following content is generated by the insert statement. below is the first redo record:

REDO RECORD - Thread:1 RBA: 0x000035.0000c258.0010 LEN: 0x0070 VLD: 0x06SCN: 0x0000.00182f4a SUBSCN:  1 08/09/2012 21:47:52CHANGE #1 MEDIA RECOVERY MARKER SCN:0x0000.00000000 SEQ:  0 OP:23.1 Block Written - afn: 3 rdba: 0x00c07179 BFT:(1024,12611961) non-BFT:(3,29049)                   scn: 0x0000.00182f38 seq: 0x02 flg:0x06

Convert the hexadecimal number to the hexadecimal number.

SQL> select to_number('000035','xxxxxx') from dual;TO_NUMBER('000035','XXXXXX')----------------------------                          53SQL> select to_number('0000c258','xxxxxxxx') from dualTO_NUMBER('0000C258','XXXXXXXX')--------------------------------                           49752SQL> select to_number('0010','xxxx') from dual;TO_NUMBER('0010','XXXX')------------------------                      16SQL> select to_number('0070','xxxx') from dual;TO_NUMBER('0070','XXXX')------------------------                     112

Therefore, we can see that:
The RBA of this redo record is 0x000035. 255.c258. 0010, which is translated into a hexadecimal value of 53.49752.16. The log sequence number is 53, the block number in the redo log is 49752, and the starting byte is 16 bytes in the block.
The length of this redo record Len: 0x0070 is 112 bytes.
Change #1. This is the first CV of the redo record. We can see OP: 23.1. According to the opcode list above, we can see that it is dummy block written callback (dbwn writes data blocks)

 

Common op appendices:

4 clear

4.1 clear
5. transaction management, such as commit/rollback

5.1 modify the transaction information in the Undo header.
5.2 start of transaction
5.4 commit
5.19 transaction audit
5.20 subtransaction Audit
10 index operations

10.2 insert page block records
10.3 clear page block records
10.4 Delete records in a page Block
10.5 restore page block logs
10.6 lock index Blocks
10.7 clear the operation code in the block when submitting
10.8 initialize the header
10.9 apply xat on itl1
10.10 set the pointer of the page block to the next page Block
10.11 set the pointer of the page block to the previous page Block
10.12 root block re-initialization after split

10.13 clear page Blocks
10.15 insert records into branch blocks
10.16 clear records in the branch block
10.18 update the key value in the record
10.19 clear the split flag
10.21 undo the branch block Operation
10.22 page block Revocation
10.24 ITL Shrinkage
10.30 update non-key values
10.31 create/load indexes
10.34 clear page Blocks
11 rows of data

11.2 insert a data record
11.3 delete a piece of data
11.4 select for update)
11.5 update records
11.6 rows
11.9 cluster key index operations
11.10 set the cluster key pointer
11.11 insert multiple records
11.12 Delete multiple records
13-segment management operations
14. Block management operations
17. tablespace management operations

17.1 end backup
18 images (generated during manual Hot Backup)

18.1 begin backup
19 direct path Loading

19.1 direct path loading (archive Mode)
19.2 nologging settings
20 compatibility segment
22 local tablespace management operations
23 block write

23.1 dbwr write block (starting from 9.0.1)
24 DDL statements