Oracle internal recovery principle (basic data structure)

Oracle Basic Data Structure

Articles: Oracle recovery Internal principles http://www.bkjia.com/search.aspx? Where = nkey & keyword = 19824

2.1 Control File
 
The control file contains the status information of all other files in the database.
 
The control file contains the following types of data:
 
A. database information record (one)
 
B. Data File records (one for each data file)
 
C. Thread record (one for each thread. Note: One thread for each instance)
 
D. log file record (one log file per log file)
 
E. File Name Record (one for each data file or log file Member)
 
F. Log history (one log file has been completed)
 
 
 
The fields referenced by the following documents in the control file are as follows:
 
2.1.1 database information record (control file)
 
Included fields:
 
A. resetlogs timestamp: 8.2
 
B. resetlogs scn: 8.2
 
C. enabled thread bitvec: 8.3
 
D. force archiving scn: 3.8
 
E. database checkpoint thread (thread record index): 2.13, 3.10
 
 
 
2.1.3 data file records (control files)
 
A. thread checkpoint structure: 2.12, 3.4, 8.3
 
B. thread-open flag: 3.9, 3.11, 8.3
 
C. current log (logfile record index)
 
D. head and tail (logfile record indices) of list of logfiles in thread: 2.8
 
 
 
2.1.4 log file record (control file)
 
A. log sequence number: 2.7
 
B. thread number: 8.4
 
C. next and previous (logfile record indices) of list of logfiles in thread: 2.8
 
D. count of files in group: 2.8
 
E. low SCN: 2.7
 
F. next SCN: 2.7
 
G. head and tail (filename record indices) of list of filenames in group: 2.8
 
H. "being cleared" flag: 10.3
 
I. "archiving not needed" flag: 10.3
 
 
 
2.1.5 File Name Record (control file)
 
A. filename
 
B. filetype
 
C. next and previous (filename record indices) of list of filenames in group: 2.8
 
 
 
2.1.6 log file history (control file)
 
A. thread number: 2.11
 
B. log sequence number: 2.11
 
C. low SCN: 2.11
 
D. low SCN timestamp: 2.11
 
E. next SCN: 2.11
 
 
 
2.2 Data File Header
 
 
 
The fields referenced by subsequent documents in the data file header are as follows:
 
A. datafile checkpoint structure: 2.14
 
B. backup checkpoint structure: 4.1
 
C. checkpoint counter: 2.16, 3.4, 5.3, 6.2
 
D. esetlogs timestamp: 8.2
 
E. resetlogs SCN: 8.2
 
F. creation SCN: 8.1
 
G. online-fuzzy bit: 3.5, 6.7.1, 8.1
 
H. hotbackup-fuzzy bits: 4.1, 4.4, 6.7.1, 8.1
 
I. media-recovery-fuzzy bit: 6.7.1, 8.1
 
 
 
2.3 Log File Header
 
 
 
The fields referenced by subsequent documents in the log file header are as follows:
 
A. thread number: 2.7
 
B. sequence number: 2.7
 
C. low SCN: 2.7
 
D. next SCN: 2.7
 
E. end-of-thread flag: 6.10
 
F. resetlogs timestamp: 8.2
 
G. resetlogs SCN: 8.2
 
 
 
2.4 Change Vector)
 
The Change vector indicates a change to the data block. The Change Vector header records the DBA address of the changed data block, the version number, sequence value, and operation code of the block. The content after the header is related to the specific change operation. The data block version number and sequence value are copied from the data block header when the change vector is created. When a block is updated, the version number is larger than the original value, and the serial number is set to 1. After that, each time the data block is changed, the sequence value increases by 1.
 
 
 
2.5 redo record
 
A redo record is composed of a set of change vectors, representing a Database Change. For example, the redo record of a transaction is composed of three parts. The first is the Change vector of the transaction table (first of the rollback segment), the second is the Change vector of the rollback segment block, and the last is the Change vector of the data block. A transaction can generate multiple redo records. A redo record is the minimum unit for database recovery. A redo record is composed of multiple change vectors, allowing multiple data blocks to be modified and these modifications either happen or never happen, even if a sudden failure occurs. This Atomicity is guaranteed by a basic Job in the database buffer layer. Oracle recovery ensures that redo records are inseparable even when the database fails.

1 2 3 4 5 Next Page