Oracle数据库备份恢复的理论基础

Oracle数据库备份恢复概念
  Oracle数据库备份是对于数据库的物理结构文件，包括数据文件、日志文件和控制文件的备份。数据库备份又可分为完全数据库备份和部分数据库备份。完全数据库备份是对于构成数据库的全部数据库文件、在线日志文件和控制文件的一个备份。完全数据库备份只能是脱机备份，在数据库正常关闭后进行。在数据库关闭的时候文件的同步号与当前检查点一致，不存在不同步的问题，对于这一类备份方法，在复制回数据库备份文件后不需要进行数据库恢复。部分数据库备份可以在数据库关闭和运行的时候进行。例如，在数据库关闭时备份一个数据文件或在数据库联机时备份一个数据表空间。部分数据库备份由于存在数据库文件之间的不同步，在备份文件复制回数据库时需要实施数据库恢复，所以这种方式只能在归档模式下使用，使用归档日志进行数据库恢复。
1 Oracle的日志文件
  Oracle数据库的日志文件(Redo Log Files，也叫重做日志)，用于记录对数据库的修改操作信息，包括普通用户对数据库里的数据的修改也包括数据库管理员对数据库结构的修改。因此，数据库的日志信息往往比数据信息还要多。比如说当用户对一个表里的一个字段进行修改，修改完成后提交数据库，这时数据文件中只需要存储修改后的数据，但是日志文件则要记录两个值，一个是修改前的记录值，一个是修改后的记录值。当然如果一段时间之类数据库仅仅只用于查询，没有修改操作，则不会产生日志信息。日志文件是与数据库备份恢复有着最直接关系的文件，有时候其作用甚至比数据文件更加重要。日志文件的作用主要体现在数据库出现故障的时候，当实例或介质失败时使用。如果关掉数据库所在机器的电源，造成数据库实例失败，Oracle 将使用联机重做日志，以将数据库系统恢复到电源停止之前的那一刹那。如果包含数据文件的磁盘驱动器发生永久性故障，Oracle将使用归档的重做日志，与使用联机重做日志一样，将驱动器的备份及时恢复到故障发生前的那一个时间点。例如，如果意外地丢失了一个表，或删除了一些关键的信息，并提交了操作，可以通过这些联机和备份的重做日志来进行恢复，并使Oracle立即将它恢复到事故发生前的时刻。
有两种类型的重做日志文件，它们是联机日志文件的和归档日志文件。每个Oracle数据库至少有两个联机日志文件，这些联机重做日志文件在大小上是固定的，并以循环的方式使用。第一个日志文件被填满后，写入第二个日志文件，然后依此类推。当所有联机日志文件都被填满时，就又回到第一个日志文件，用新事务的数据对其进行重写。从一个日志文件切换到另一个日志文件的动作叫做日志切换。如果数据库正以归档模式运行，在发生日志切换重写联机日志文件前，数据库ARCH（归档进程）将先对其进行备份(即归档)，由此就产生了归档日志文件。如果数据库运行在非归档模式，旧的日志文件将直接被新的日志文件所覆盖，不会产生归档日志。
2 Oracle的运行方式
  Oracle数据库有两种运行方式，一种是非归档方式，一种是归档方式。
2.1 非归档方式
非归档方式就是Oracle在运行中循环使用日志并在发生日志切换时日志信息被直接覆盖而不归档的一种数据库运行方式。Oracle数据库运行在非归档方式中时，日志文件将被循环利用，发生日志切换时，日志信息将被直接覆盖。一旦日志信息被覆盖，则数据库只能恢复到上次完全备份状态。非归档方式是一种不安全的运行方式，而且在这种模式下不能进行联机备份也不能进行部分数据库备份。每次备份时，只能关闭数据库，备份完整的数据文件、日志文件和控制文件。而每次恢复时，只能从失效前的一个完整的数据库备份中恢复数据文件、日志文件和控制文件。
在非归档方式下运行的数据库，只有历史日志，没有归档日志。归档日志表示在日志切换之前写到备份介质上的日志，用于数据库恢复。历史日志表示在日志切换之后被覆盖掉的日志，只是一种标识，表示何时产生过日志，物理上没有日志数据，所以历史日志由两部分组成，一部分是归档日志，另一部分是被覆盖的日志。
2.2 归档方式
归档方式就是Oracle在运行中循环使用日志并在发生日志切换时日志信息先归档再覆盖的一种数据库运行方式。Oracle数据库运行在归档方式时，只有当检验点发生时日志文件才会被重用，而此时日志文件中的信息已经被归档进程ARCH写到了备份介质服务器上成为归档日志。当发生介质故障时，可以使用归档日志文件进行数据库恢复，可以保证不丢失任何已提交的数据，因此数据库可以进行联机热备份也可以进行部分数据库备份。
前面讲到过，每一个数据库实例至少包含两个日志文件组，Oracle的后台进程LGWR时时监控着日志文件的使用情况，当一个在线日志文件组被填满后，就发生日志切换，形成数据库的归档日志文件，这时LGWR进程开始将日志信息写到下一个在线日志文件组，当最后一个可用的在线日志文件的检验点到来时，即又回到第一个组，如此循环。
数据库运行在非归档方式下时，在数据库控制文件指明填满的组不需要归档，所以当填满的组成为活动组，在日志切换的检验点完成时，则该组即可被LGWR重用。数据库在这种方式下，只能利用存储在在线日志中的信息对数据库实例故障进行恢复，不能进行介质恢复；如果运行在归档方式下，可实施在线日志的归档，在控制文件中指明填满的日志文件组在归档之前不能重用，一旦该组变为不活动组，则归档进程立即可使用该组。利用归档日志在数据库出现故障时进行介质恢复。
值得一提的是，Oracle数据库默认是工作在非归档模式下面的。要将其改变到归档模式下，需要在数据库正常运行的情况下执行下列操作：
SQL > shutdown immediate;
SQL > startup mount;
SQL > alter database archivelog;
SQL > alter database open;
每一步操作都成功后，执行SQL 语句“archive log list;”就可以看到数据库的运行模式已经是归档模式了。
3 检验点
  检验点（CheckPoint，简写为CKPT）是Oracle的一个后台进程，用来保证所有修改过的数据库缓冲区中的内容都被写入到数据库文件中去。在给定的时间内，数据库文件出现“当前”标记并将检验点记录在控制文件中，数据库恢复时只需要提供从上一个检验点以来的修改。在保证信息已被写入到相应的数据文件后，允许重用一个日志文件。检验点完成后，系统将更新数据库头和控制文件，以保证数据库的同步。增加检验点次数可以减少例程失败时恢复所需的时间。也就是说，检验点就是Oracle用来对所有数据库文件进行数据同步的一个措施。
这里介绍一个概念，叫系统改变号SCN（System Change Number，也叫检验点号，同步号等）。在Oracle系统中，SCN是数据库的三类文件（控制文件、数据文件、日志文件）的同步依据，同时存储在这三类文件当中。在日志切换或其它原因引起系统改变时，检验点号就会同时改变。数据库头的同步号与日志文件、数据文件中的检验点号完全相同则说明数据库中没有不同步现象，数据库可以正常启动；否则数据库存在不同步现象，数据库不能正常启动，必须进行介质恢复。
SCN号在数据库运行中会实时改变，并同时将改变结果写入数据文件、控制文件和数据库头，以保证全部的数据库文件同步。一般而言，出现下列情况时会产生检验点，SCN号会立即改变，生成一个新的检验点号：
(1). 系统正常退出时。
(2). 系统产生日志文件切换时。
(3). 缺省设置的时间间隔到来时。
(4). 系统接收到执行检查点的命令时。如执行SQL语句 “alter system checkpoint local;”
会在实例中显式触发一个检验点。
(5). 系统缓冲区内更新块数达到指定长度时。
(6). 最近一次检验点到当前 REDO日志块之间的 REDO块数达到指定的数量时。
检验点有三类，分别是局部检验点、全局检验点和文件检验点。局部检验点又称线程检验点，即一个实例对数据库中的所有数据库文件执行一个检验点操作，即属于一个实例的全部脏缓冲区都被写入到所有的数据文件中，如上述SQL语句“alter system checkpoint local;”执行的就是一个局部检验点操作。而全局检验点又称做数据库检验点，即所有实例对所有的数据文件执行一个检验点操作，即所有实例的全部脏缓冲区都被写入到所有的数据文件中，如SQL语句“alter system checkpoint global;”执行的就是一个全局检验点操作。而文件检验点，是所有实例对某一些数据文件所做的检验点操作，如后面会提到的SQL语句“alter tablespace system begin backup;”将执行system表空间所属全部数据文件的一个文件检验点操作。
4 回滚段
回滚段(Rollback Segement)是在当事务修改某个数据块时用于存放数据以前映像信息的数据库段（存放数据修改之前的值和位置）。回滚段的头部包含正在使用的该回滚段事务的信息。当某事务修改一个数据块时，它更新数据块头，让数据块头指向包含该事务回滚信息的回滚段。该事务还在回滚段的事务表中插入一项，给出被修改数据块的地址、事务状态以及回滚段中存放该事务回滚信息的位置。一个事务只能使用一个回滚段来存放它的回滚信息，而一个回滚段可以存放多个事务的回滚信息。
回滚段中的信息是用来保持数据的读一致性，并且用于事务回滚和事务恢复。例如：
(1). 用于读一致性：当一个会话正在修改数据时，其它的会话将看不到该会话未提交的修改（会话级读一致性）。而且，当一个语句正在执行时，该语句将看不到从该语句开始执行后的未提交的修改（语句级读一致性）。如当Oracle执行一条查询语句时，Oracle会依照当前的系统改变号来保证任何前于当前系统改变号的未提交的改变都不被该语句处理，当其它会话或语句改变了该查询所要查询的那个数据块，Oracle将利用回滚段的数据前影像来构造一个读一致性视图。
(2). 用于事务回滚：Oracle将会利用回滚段中的数据前影像来将修改的数据恢复到原来的值。如事务将某一个数据块中的一个值从100修改为1000，则原值100要存在回滚段中，而数据块中存储新值1000。如果现在发现修改有问题，需要回滚，则原值100将从回滚段中拷贝回数据块中。
  (3). 用于事务恢复：当事务正在处理的时候发生例程失败，如Oracle某个后台进程异常终止，则必须关闭并重启Oracle。回滚段的信息保存在重做日志文件中，在启动过程中，Oracle将自动进行事务恢复实现向前回滚，来恢复未提交的数据。回滚段和REDO日志一起保障了事务的完整性。
回滚段分为系统回滚段、非系统回滚段以及Defered回滚段。系统回滚段是在数据库创建后由系统自动创建的，该回滚段只用于存放系统表空间中对象的前影像。非系统回滚段用于存放非系统表空间中对象的数据前影像。非系统回滚段又分为私有回滚段和公有回滚段，私有回滚段应在参数文件的Rollback Segements参数中列出，以便例程启动时自动使其在线。公有回滚段一般在OPS（Oracle并行服务器）中出现，将在例程启动时自动在线。 Defered回滚段在表空间离线（Offline）时由系统自动创建，当表空间再次在线（Online）时由系统自动删除，用于存放表空间离线时产生的回滚信息。
5 Oracle备份恢复原理分析
Oracle 数据库使用数据库后备副本、日志、回滚段和控制文件这几种结构来保护数据。它采用日志文件及回滚段的形式保存日志信息。当某事务修改一个数据块时，修改前的数据信息（称为前映像）被存储到回滚段中。由于事务内部故障出现的概率大于其它类型故障，把回滚信息存储在数据库内部的对象(回滚段)中而不是写在日志文件中可以明显地提高故障恢复的效率（有点类似于CPU的Cache的作用）。事务提交前都会将相应的日志信息写盘，这确保了日志信息是完整的。为了提高效率，在事务提交之后并不马上将提交的数据写盘(Cache也是这样做的)。
我们注意到当我们采取热备份的时候，需要对每个要备份的表空间置为backup模式。通常的热备份的脚本都是这样的：
  alter tablespace system begin backup ；
  cp e:\oracle9i\oradata\oemrep\system01.backup to e: \system01.backup ；
  alter tablespace users end backup ；
  我们知道，Oracle的最小存储单位是一个数据块，一个块的大小通常设置为8k，而操作系统的块通常是512字节，这说明一个Oracle的数据块由很多个操作系统的块组成。而且对于一个数据文件来说，它的所有块对应的操作系统的块并不是按顺序存储的，当运行cp等操作系统命令时并不能指定从Oracle的哪个数据块开始拷贝。当open数据库的时候，Oracle会去比较控制文件中数据文件记录和数据文件头的checkpoint cnt，如果两者相同，则判断数据库是同步的，不需要介质恢复，如果不同，Oracle就会报错，提示某某文件需要进行介质恢复。然后我们必须拷贝回数据文件的备份，开始做recover，这时候数据库就会从上次成功备份时的SCN开始恢复，选定恢复时使用的日志，直到恢复结束。如果我们没有执行SQL语句alter tablespace system begin backup 的话，当拷贝数据文件时，比如说我们拷贝的第一个块可能是SCN为100的数据块。我们知道当数据库发生检验点时会去更新数据文件头和控制文件中的checkpoint scn，如果当我们在拷贝数据文件的同时发生了几次检验点，这时候数据文件头的SCN可能被更新了很多次。这时候拷贝进程去拷贝数据文件头所在的操作系统块，可能这个数据文件头的块因为被checkpoint了很多次导致它的SCN为1000，这时候整个数据文件会出现不一致，当用这个备份文件去恢复数据库时，恢复进程会从SCN＝1000开始恢复，这样的话恢复的数据库就会丢失从SCN号100到1000的那些数据块，因为恢复进程并不应用SCN在1000以前的日志，所以不置成backup模式备份的话是不可取的。当数据文件置于backup模式时，Oracle会去锁定数据文件头，这时候数据库发生检验点的话将不会修改文件头的SCN，而只是增加checkpoint cnt，所以不管执行拷贝的时候操作系统块的拷贝顺序是如何，Oracle总会从文件头的SCN开始恢复，这样的话也就避免了前面提到的恢复时的数据块丢失。当然如果大家用的是Rman来备份的话，就不会有这个问题，因为Rman备份的时候会自动对比数据块的头尾标志，如果发现不一致，那么它将会再去读这个块，直到读到一致的块才往备份集里写。