Understanding redo (3) explain an update process

Theoretical analysis:

1) server process searches buffer cache for the block to be updated by update (also known as buffer in memory). If no block is found, it reads the buffer cache from disk.

2) server process constructs a group of change vectors to record changes to the data blocks (put in PGA at this time). This group of change vectors form a redo record.
Four data blocks may be changed:
The segment header of the rollback segment: indicates the transaction information on the corresponding transaction table, including xid and uba, and allocates rollback blocks.
Block header blocks: allocate transaction slots and Mark transaction information, including xid and uba.
Rollback block: record the pre-image
Data Block: Modify

3) use the redo record size to determine the size of the redo log buffer.

4) judge the current scn and save it to the redo record (different redo record may share the same SCN value and use the value SEQ in the change vector header to differentiate it)

5) obtain the redo copy latch, and then obtain the redo allocation latch.

6) Check whether another process has a higher SCN value than the currently held SCN. If yes, generate a new SCN and replace the SCN in step 1. In short, save the latest scn.

7) determine whether there is sufficient redo log buffer space. The details are as follows:

If the redo log buffer does not have enough space, release the redo copy latch and redo allocation latch. If other processes or conditions start with LGWR, wait for lgwr to complete, if LGWR is not started at this time, lgwr is triggered (redo writing latch is required, And the LGWR process will always occupy this LATCH when the redo record is written to the online current redo LOG file from the log BUFFER, prevent other processes from triggering LGWR at the same time. If other processes attempt to obtain the latch, they must wait and obtain the redo allocation latch to prevent new change vectors from being written into the log buffer, this causes LGWR to be unable to determine the number of redo writes.) when there is not enough space, after the redo copy/allocation latch is released, if the redo writing latch cannot be obtained, the lgwr is started by other processes, after obtaining the data, check whether the log buffer has space (because the LGWR may have released a large number of redo log buffer space). If there is space, release the redo writing latch, then obtain redo copy/allocation latch. If there is no space, lgwr is triggered and redo writing latch is released (this latch is given to lgwr ). if there is no space and lgwr writes the redo record in the redo log buffer to the online current redo logfile, when the redo logfile space is insufficient, the process checks whether other processes have started the switch logfile. If not, the switch logfile is triggered. If other processes have started, the current process waits. After the switch logfile, continue to write lgwr into redo log buffer. (do not generate redo during switch log)

If the redo log buffer has enough space, allocate space, release the redo allocation latch, and then COPY the change vector from PGA to the redo log buffer, mount the block corresponding to the redo record modified in the buffer cache to CKPTQ (checkpoint queue) (wait for dbwr to write) and then release the redo copy latch. 

8) check whether the redo log buffer and redo record have reached threadshold after writing. If so, lgwr is triggered.

9) Update the block in the buffer cache.

Experiment details (dump undo information to understand ):

1)

1. SQL> conn hr/hr
2. Connected.
3. SQL>Drop TableT1;
4. Drop TableT1
5. *
6. Row 3 has an error:
7. ORA-00942: Table or view does not exist
8. SQL>Create TableT1 (id number,NameVarchar2 (20 ));
10. The table has been created.
12. SQL>Insert IntoT1 (1,'A');
13. Insert IntoT1 (1,'A')
14. *
15. Row 3 has an error:
16. Lack of ORA-00928SELECTKeywords
19. SQL>Insert IntoT1Values(1,'A');
21. One row has been created.
23. SQL>Insert IntoT1Values(2,'B');
25. One row has been created.
26. SQL>Commit;
28. Submitted.

2)

1. SQL>SelectDbms_rowid.rowid_relative_fno (rowid) fno,
2. 2 dbms_rowid.rowid_block_number (rowid) bno
3. 3FromHr. t1;
5. FNO BNO
6. --------------------
7. 4 437
8. 4 437
10. SQL>SelectData_object_id, ownerFromDba_objectsWhereObject_name ='T1';
12. DATA_OBJECT_ID OWNER
13. --------------------------------------------------------------------------
14. 53467 HR
16. SQL>AlterSystem flush buffer_cache;
18. The system has been changed.
19. SQL>SelectFile #, block #, dirtyFromV $ bhWhereObjd = 53467;
21. FILE # BLOCK # DI
22. ----------------------
23. 4 438 N
24. 4 433 N
25. 4 436 N
26. 4 439 N
27. 4 434 N
28. 4 437 N
30. You have selected 6 rows.

3)

1. SQL>Select*FromT1;
3. IDNAME
4. --------------------------------------------------
5. 1
6. 2 B
8. SQL>UpdateT1Set Name='C' WhereId = 1;
10. 1 row updated.

4)

1. SQL>SelectFile #, block #, dirtyFromV $ bhWhereObjd = 53467;
3. FILE # BLOCK # DI
4. ----------------------
5. 4 440 N
6. 4 435 N
7. 4 438 N
8. 4 438 N
9. 4 433 N
10. 4 436 N
11. 4 436 N
12. 4 439 N
13. 4 439 N
14. 4 434 N
15. 4 437 N
16. 4 437 N
17. 4 437 Y
19. 13 rows have been selected.
21. SQL>SelectXidusn, xidslot, xidsqn, ubafil, ubablkFromV $Transaction;
23. XIDUSN XIDSLOT XIDSQN UBAFIL UBABLK
24. --------------------------------------------------
25. 8 6 579 2 2636

1 2 Next Page