基础数据结构
2.1 控制文件
控制文件包含了数据库中所有其他文件的状态信息。
控制文件包含了如下几类数据：
A. 数据库信息记录（一条）
B. 数据文件记录（每个数据文件一条）
C. 线程记录（每个线程一条。注：每个实例一个线程）
D. 日志文件记录（每个日志文件一条）
E. 文件名记录（每个数据文件或者日志文件成员一条）
F. 日志历史记录（每个已经完成的日志文件一条）
控制文件的被后面文档引用到的字段如下，后面是引用该字段的章节：
2.1.1 数据库信息记录（控制文件）
所含字段：
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 数据文件记录（控制文件）
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 日志文件记录（控制文件）
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 文件名记录（控制文件）
A． filename
B． filetype
C． next and previous (filename record indices) of list of filenames in group: 2.8
2.1.6 日志文件历史记录（控制文件）
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 数据文件头
数据文件头部分的被后面文档引用的字段如下，后面跟的是引用该字段的章节:
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 bit: 4.1, 4.4, 6.7.1, 8.1
I． media-recovery-fuzzy bit: 6.7.1, 8.1
2.3 日志文件头
日志文件头部分的被后面文档引用的字段如下，后面跟的是引用该字段的章节:
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)
改变向量表示对数据块的一次变更。改变向量头部记录了发生变更的数据块的DBA地址，该块的版本号，序列值和操作代码。头部以后的内容跟具体的变更操作有关。数据块版本号和序列值是在创建改变向量时从数据块的头部复制过来的。当块被更新后，版本号值就比原来的值大一点，而序列号则被设为1。此后数据块每变更一次，序列值就增长1.
2.5 重做记录
一个重做记录是由一组改变向量组成，代表一个数据库变更。如一个事务的重做记录由三部分组成。首先是事务表（回滚段段首）的改变向量，其次是回滚段块的改变向量，最后是数据块的改变向量。一个事务可以产生多个重做记录组成。一个重做记录是数据库恢复的最小单位，一个重做记录由多个改变向量组成的机制允许多个数据块被修改并且这些修改要么都发生要么就都没发生，即使发生突然的失败。这种原子性是由数据库缓冲层的一个基础Job来保证的。Oracle恢复保证重做记录是不可分割的，即使在数据库失败的时候。
2.6 System Change Number (SCN)
SCN描述了数据库的一次事务提交版本。一次查询也是查询数据库的某个SCN产生时刻时的内容。SCN会被分配和保存在事务的重做记录的头部。SCN也会保存在控制文件和数据文件中。SCN是由48位长的数字组成。
2.7 重做日志
所有数据块的变更发生时都是先构建一个重做记录，然后把这个重做记录保存到重做日志中，最后在数据块中应用该变更。恢复的过程就是在旧的数据块上应用重做日志使该数据块变成当前版本。这个过程在当前版本数据丢失的情况下是必须的。
当一个重做日志文件写满了时，就会发生日志切换。每个日志是由一个线程号（见后面），序列号（一个线程以内再分）和该日志跨越的SCN范围标识。这些信息保存在日志文件头中。
重做日志文件中的重做记录是根据SCN排序的。此外，重做记录中包含的具体数据块的改变向量也是按SCN递增顺序发生的，即使是跨多个线程（这种情况发生在多个实例环境中）。只有某些重做记录头部包含有SCN信息，但是所有的记录都是在某个SCN被分配后才发生的。日志文件的头部包含了最小的SCN和下一个 SCN。最小的SCN是这个日志文件中第一个重做记录对应的SCN。下一个SCN是当前日志序列递增后的下一个日志文件的的最小SCN。当前在使用的重做日志的下一个SCN都是无限大，因为还没有日志文件的序列号比当前日志的序列要大。
2.8 重做线程
每个实例产生的重做日志被称为一个重做日志线程。一个日志线程由联机重做日志和归档重做日志（前提是数据库运行在归档模式下）组成。联机重做日志是由两个或更多个日志组组成，每个日志组由一个或更多重复的日志成员组成。通常说一个日志组，重做日志，联机日志或简称日志都是指一个日志组的成员集合（可能是一个或者多个）。一个重做日志只包含该日志所属的线程记录的日志。各个线程在写日志时分配日志文件的序列号是彼此独立的，各个线程的日志组之间的日志切换也是独立进行的。
每个日志文件组在控制文件中都有一笔记录描述它的信息，每笔记录通过日志号码查找。注意日志号跟日志组的号码是一致的，而且是全局唯一的（并行服务器环境中）。每个重做线程的日志文件组列表记录都在每个重做线程记录的后面（类似于一种Head-Detail结构），各个日志文件组的记录中都分别有一个向前和向后的字段记录上一个日志文件组和下一个日志文件组（通过日志文件组号来记录）。日志文件组的成员信息在日志文件组的记录中描述。
2.9 Redo Byte Address (RBA)
RBA指定了重做日志的位置，长度为10字节，由三部分组成：日志序号，块号以及块中的字节序号。
2.10 检查点结构
检查点结构定义了数据库重做日志的一个点。检查点结构信息保存数据文件头部和控制文件中每个重做线程的记录中。这些检查点结构用于恢复时告诉数据库从哪个重做日志的哪一笔重做记录开始恢复。
检查点结构的关键字段是检查点SCN和当前启用的线程标志。
检查点SCN能有效的定位每个启用的线程的任一位置（启用的定义见3.11）。对于每个重做线程，检查点SCN就是发生一次提交时的时间点以及对应重做日志的位置，根据重做日志文件头部的重做记录可以发现第一笔重做记录产生时分配的SCN是检查点SCN或更高一点.
当前启用的线程标志标记了这个检查点SCN被分配时哪个重做线程处于启用状态。注意每个线程在启用时都有一个状态位被设置，不管它是打开还是关闭状态。每个启用的线程都有一个重做日志，重做日志包含该检查点SCN，这点证明了该重做日志存在（联机或者已经归档）。
检查点结构还还保存了这个检查点SCN被分配时的时间戳，这个时间戳只是输出一些信息便于用户查找日志。
此外，检查点结构还保存了检查点SCN被分配时的线程的数量和线程中当前RBA地址。显式的保存线程的RBA地址（相对于保存SCN作为线程的隐式的指针）使得在单实例环境中日志序列和归档日志名称更容易找到。
检查点在一段时间内可以支持高达1023个重做日志线程，总计150字节长。
2.11 日志历史
控制文件在创建之初可以指定包含多少个已完成的日志历史记录（在CREATE DATABASE或CREATE CONTROLFILE时指定MAXLOGHISTORY选项）.日志历史记录很短(在VMS里只有24字节).它会被循环改写,因此旧的信息就会丢失.
对每个日志文件,日志历史记录包含了线程号,日志序号,Low SCN,Low SCN时间戳,next SCN(即下一个日志文件的Low SCN)。日志历史记录用来根据线程号和SCN构建归档日志名称。因为日志序号就包含在检查点结构中（RBA的一个字段），单线程（即单实例环境）的数据库不需要日志历史记录来得到归档日志名称。
日志历史记录的字段可以通过视图V$LOG_HISTORY来查询。此外 V$RECOVERY_LOG记录了介质恢复需要的归档日志，它的信息就来自于日志历史记录。虽然对单实例环境来说日志历史记录对管理没什么大的帮助，不过为了使用视图V$LOG_HISTORY和V$RECOVERY_LOG，建议配置这个功能。
2.12 线程检查点
每个启用的线程在控制文件中的记录中都包含了一个检查点结构，我们称之为线程检查点。这个检查点中的SCN字段就是线程检查点SCN，还有线程序号和RBA字段指明了这个线程检查点跟哪个线程相关。
线程检查点结构在实例每次对其线程发出检查点操作时被更新（见3.4）。检查点发生时，跟该实例相关的线程会把重做日志里记录的小于该线程检查点SCN的重做记录保护的脏数据写入到联机数据文件中。
线程检查点事件保证了该线程的重做日志中所有小于该线程检查点SCN的重做记录对应的脏数据都被写入到磁盘（注意到如果该线程关闭了，重做日志里就没有SCN比线程检查点SCN还小的记录。）
实例恢复的时候要保证对应线程的所有重做日志都应用到数据文件中。因为线程检查点SCN以前的重做日志已经被应用了，所以实例恢复可以保证，在启动重做日志进程时只要从线程检查点SCN开始应用，直至重做日志文件的尾部，所有线程的重做日志都被应用。
2.13 数据库检查点结构
数据库检查点结构就是所有打开的线程中线程检查点SCN最小的那个线程检查点。数据库检查点线程的序号——当前线程检查点是数据库检查点的那个线程的序号——被记录在控制文件的数据库信息部分。
因为每个实例都保证对应线程检查点SCN以前的重做日志保护的脏数据已经写到数据文件中，并且数据库检查点SCN是所有线程中线程检查点SCN最小的，所以可以说所有实例中在数据库检查点SCN以前的重做日志记录所保护的脏数据都被写到数据文件中。换句话说是数据库所有联机数据文件都在数据库检查点时发生了检查点操作。这就是一个实例检查点了对应线程时用数据库检查点更新了所有联机数据文件检查点（见下面）的基本原理（见3.4）。
2.14 数据文件检查点结构
数据文件检查点结构指的是每个数据文件的头部包含的检查点结构，其中的SCN字段就是数据文件检查点SCN。
由前面而知，针对每个数据文件，在其检查点SCN以前的所有线程的重做日志保护的脏数据都已经被写入到数据文件。每个联机的数据文件会把它的检查点SCN记录在控制文件中，但这个值可能跟数据文件头部的检查点SCN不一致。Oracle恢复层设计成能接受这种不一致。当实例失败发生在更新数据文件头部的检查点之后提交控制文件“事务”之前时，二者没有及时同步造成不一致。（注：控制文件“事务”是数据库内部机制，独立于Oracle事务层，指的是保证对控制文件任意大的更新都能够自动被“提交”）。
数据文件检查点执行时（见3.6），数据文件头部的检查点结构会被更新，并且保证所有线程产生的重做日志记录在该检查点SCN以前对应的脏数据都已经被写入到磁盘上了。
线程检查点事件（见3.4）保证了所有线程产生的所有SCN在检查点SCN以前的重做日志记录对应的脏数据都被写入到磁盘了。线程检查点事件可能会推进数据库检查点（如在单实例环境中；或该线程的检查点最旧了）如果数据库检查点推进了，新的检查点将更新所有联机数据文件的检查点结构（热备份中的数据文件除外，见第4节）。
介质恢复时要保证对即将恢复的数据文件把任一个线程产生的重做日志记录都要应用上去。由前面知对即将恢复的数据文件来说，每个线程产生的重做日志在该数据文件检查点SCN以前的重做日志都已经得到应用，介质恢复在重新应用日志时只需要从数据文件检查点SCN开始支持恢复结束点。注：用户指定结束的SCN或时间点等（不完全回复），又或者是所有线程的结束点（完全恢复）。
因为数据文件检查点保存在数据文件的头部中，所以在数据文件的备份中同样也存在。如果是热备份产生的备份，热备份保证了当数据文件处于热备份状态时，即使在复制要备份的数据文件过程中数据库要更新该数据文件上的脏数据，数据文件中所有数据库的版本跟数据文件头部的检查点结构的版本是一致的，都是在热备份开始那一刻时的版本。
2.15 结束SCN
每个数据文件在控制文件的记录中都有一个字段叫结束SCN。如果该数据文件是脱机状态或只读的，该结束SCN的值表示对该数据文件不会有再比这个结束SCN 更大的重做记录。如果该数据文件是联机的并且有一个实例打开了数据库，结束SCN就会被设置为无限大（注：值为0xffff.ffffffff）。结束 SCN用于介质恢复时告诉重做程序在该数据文件上应用重做日志时到了这个SCN时就停止。这保证了在数据库打开的状态下恢复一个脱机的数据文件时介质恢复能停下来。
不管数据文件脱机或者只读，结束SCN都会被设置为具体的SCN。不管脱机操作时“立即”（因为I/O错误导致或者因为数据文件所在表空间被立即脱机）还是“临时的“或“正常的”（数据文件所在表空间正常脱机）。不过在数据文件被立即脱机时，不会发生数据文件检查点（见3.6），并且对应的脏数据都丢失了。因此在将该脱机文件变成联机时介质恢复需要重新应用重做日志直至结束SCN。介质恢复不需要应用结束SCN以后的重做日志，因为就不存在这样的重做日志。如果结束SCN等于数据文件检查点SCN，那么该数据文件就不需要恢复。
2.16 检查点计数
在数据文件头部和数据文件在控制文件的记录部分都有一个检查点技术。检查点计数是用来判断数据文件或者控制文件是否是过时的（从一个备份中恢复出来的）。
每次发生线程检查点事件时，检查点计数都会递增。从而即使数据文件的检查点没有被推进时检查点计数也会增加。线程检查点事件时数据文件检查点没有被推进的原因可能是数据文件处于热备份状态，或者它的SCN比要更新的检查点SCN值还要新（如数据文件时新增的或者刚经历了一次数据文件检查点事件）。
2.17 表空间干净结束SCN
数据字典TS$有两列表示 表空间干净结束SCN（注：9i中是SCNWRP和SCNBAS组合表示）。它表示表空间是在这个SCN时被脱机或者设置为只读。如在对数据文件发出检查点操作后（见3.6），数据文件检查点SCN被记录到TS$中作为表空间干净结束SCN。这样的表空间在数据库以重置日志方式打开后不需要被删除（见 8.6）。在介质恢复时，以重置日志方式打开日之前，这种表空间会处于脱机状态。重置日志后，表空间也不需要恢复，允许被直接设置为联机状态或读写状态。重置日志后建议立即备份表空间。
当把一个脱机且干净的表空间置为联机或者可读写时，表空间干净结束SCN会被设置为0（中间可能短暂性被设置为无穷大）。立即或临时性的将表空间置为脱机状态，tablespace-clen-stop SCN也会是0.
一个在TS$中表空间干净结束SCN为非零的表空间被认为在那个SCN时是干净的，指的是该表空间包含了直至那个SCN的所有的重做记录保护的数据，没有大于那个SCN的重做日志记录存在。如果该表空间的所有数据文件都是脱机时刻的状态或者只读的，那在将表空间置为联机状态时是不需要恢复的。注意到表空间干净结束SCN同数据文件在控制文件中的记录的结束SCN是有区别的。结束SCN只是表明该数据文件没有超过结束SCN的重做日志记录，但并没有暗示该数据文件已经包含了结束SCN以前的所有重做日志记录所保护的脏数据。
表空间干净结束SCN存放在TS$中而不是控制文件中，所以可以得到重做日志的保护并且处于正确的状态。如在一个不完全恢复后（见6.12），该表空间的状态依然正确。它的值也不会随着使用了备份的控制文件。更重要的是这种 SCN的存在使得该表空间在以重置日志方式打开数据库后依然可以存在。因此不完全恢复期间的脱机了的表空间可以在以重置日志方式打开数据库后直接置为联机状态或设置为可读写。如果没有表空间干净结束SCN,就没有办法知道该表空间不需要被重置日志抛弃的重做日志记录。那时唯一可选的办法就是将该表空间脱机。
2.18 数据文件脱机范围
数据文件在控制文件中记录了脱机时的SCN和脱机结束时的检查点。二者界定了该数据文件不需要重做日志的范围。因此介质恢复的时候可以直接跳过该范围的重做日志。这个特性帮助恢复了一个已经脱机了或者设为只读了很长一段时间的数据文件变成联机或可读写。
当一个数据文件从脱机状态变为联机状态时（或从只读变成可读写时），脱机范围设置规则如下：脱机起始SCN取的是该表空间的表空间干净结束SCN,脱机结束检查点取的是数据文件设置为联机（或可读写）时的数据文件检查点。