第7章 备份与恢复

7.2.3.1、完全恢复（complete recovery） 4

7.2.3.2、不完全恢复（incomplete recovery） 4

7.2.5 、resetlogs操作 5

7.3.3 逻辑导入/导出（export/import 和 Data Pump） 5

7.1 什么是备份

7.1.1 备份类型

1、物理备份

将数据文件、控制文件、归档文件等oracle数据库启动时所必须的相关物理文件，复制到其他路径或设备中。（rman ,user-managed backup ）物理方式创建的备份，备份时数据库是什么样，恢复出来也是什么样。

2、逻辑备份

备份逻辑对象的方式都称为逻辑备份。

核心是复制数据。这种复制方式不管数据库中具体是哪些文件存储数据，而是按照oracle提供的命令，通过逻辑的方式将数据保存在其他位置。

7.1.2 数据库状态

备份时数据库的状态也可以分为两类：启动状态和关闭状态

1. 热备份（online backups），联机备份

数据库启动状态创建的备份。

该状态下创建的备份是不一致备份，要创建有效的热备，要求数据库必须处于归档模式，否则可能是无效备份（具体情况要视当前online redologs是否被覆盖过而定）

2. 冷备份（offline backups）,脱机备份

Open read only 模式下创建的备份也属于冷备份。

7.1.3 备份的状态

1、一致性备份（consistant backups）

备份的数据文件和控制文件有相同scn，只有数据库以shutdown immediate/normal/transactional方式关闭，并且数据库未被置于打开状态（或open read only）时创建的备份才是一致性备份，在恢复后不要要再做修复就可以直接打开。

2、不一致备份(inconsistant backups)

备份的数据文件和控制文件的scn不一致，不一致备份在恢复后必须借助归档文件和联机重做日志将数据库修复到一致性状态才能打开。创建不一致备份除了要备份数据库启动时必须的数据文件和控制文件外，还需要备份归档日志文件。

热备份肯定是不一致备份，但不一致备份不一定都是热备份。如shutdown abort关闭的数据库如果处于不一致状态，此时虽然创建的是冷备，但却是不一致备份。

7.1.4 备份规模

7.1.4.1、完全备份

完整备份，包括数据文件、控制文件、归档文件和初始化参数文件。

完全备份的数据既可以是归档模式也可以是费归档模式，备份是否有效，取决于备份状态

（1）归档模式下：

数据库正常打开状态下创建的备份是不一致性的有效备份

数据库正常关闭状态下创建的备份都是有效备份

（2）非归档模式下：

数据库正常打开状态下创建的不一致性备份是无效备份

数据库正常关闭状态下创建的备份都是有效备份（但不一致备份不建议使用）

7.1.4.2、表空间备份

备份指定的一个或多个表空间，实质是备份数据文件（隶属于指定表空间的数据文件）。满足下列条件之一时，创建的表空间级备份是有效的：

（1）数据库处于归档模式

（2）表空间为只读或脱机

7.1.4.3、数据文件备份

备份可以指定一个或多个数据文件

（1）归档模式下是有效备份

（2）read only/offline下也是有效备份

7.1.4.4、控制文件备份

7.1.4.5、归档日志文件备份

7.2 什么是恢复

7.2.1 错误的类型

7.2.1.1、用户误操作导致的失误

（1）使用flashback进行快速恢复

（2）通过之前创建的备份，恢复到错误产生之前的时间点

（3）逻辑导入正确的数据

7.2.1.2、系统进程导致的错误

用户进程或服务器进程（server process）故障:pmon 自动修复

后台进程故障，例如pmon崩溃，实例也会跟着崩溃，通常会触发实例错误

7.2.1.3、实例导致的错误：

实例错误，oracle会在下次启动后，自动尝试进行实例恢复

（1）实例崩溃的原因：

系统进程故障

服务器突然掉电

操作系统自身崩溃

（2）实例错误通常导致下列问题：

提交的事务要修改的数据尚未写入数据文件

未提交的事务修改的数据已经写入数据文件

7.2.1.4、存储介质故障导致错误

丢失数据文件，需要进行介质恢复

7.2.2 恢复类型

7.2.2.1 实例恢复

崩溃恢复oracle自动进行，读取当前的数据文件和联机重做日志文件（不是归档文件，实例恢复与是否归档模式无关）来恢复数据库，使数据库文件和控制文件恢复到崩溃前的一致性状态。

实例恢复的步骤：

（1）缓存恢复（cache recovery）

oracle启动实例加载数据库，然后通过online redologs中的重做日志，重现实例崩溃前对数据库的修改操作。在恢复过程中对于已提交的事务，但尚未写入数据文件的那部分数据全部重新写入数据文件（前滚）(rolling forward)

（2）事务恢复（transaction recovery）

在实例崩溃恢复时，部分未提交的事务操作的数据也被写入到数据文件，这些事务必须被撤销（rolling back）

7.2.2.2、介质恢复

介质恢复首先将数据库恢复到备份时的状态，然后通过应用重做日志的方式将数据库恢复到最近的时间点（应用所有重做日志）或者某个指定的时间点（只应用部分重做日志，不超过重做日志中记录的最后时间点）

7.2.3 、介质恢复的两种恢复方式

7.2.3.1、完全恢复（complete recovery）

将数据库恢复到最近的时间点的恢复方式就是完全恢复。

通常是当磁盘故障导致数据文件和控制文件无法访问时选择的恢复方式，并不仅仅是整个数据库的恢复才叫完全恢复，也可以针对表空间或数据文件进行完全恢复。

（1）对整个数据做恢复，大概步骤如下：

mount数据库

确认所有数据文件均为online状态

执行恢复操作

应用所有生成的redologs文件（包括联机重做日志文件和归档文件）

（2）表空间或数据文件级的恢复

open数据库

将要恢复的表空间或数据文件置为offline

执行恢复操作

应用所有生成的redologs文件（包括联机重做日志和归档文件）

7.2.3.2、不完全恢复（incomplete recovery）

将数据库恢复到非当前时候的状态，也即只应用部分归档或联机重做日志，可以通过指定scn或时间点，将数据库恢复到指定时间时的状态，也叫时间点恢复。

适用于下列情况：

（1）介质损坏导致部分在线重做日志不应用。

（2）用户误操作数据，无法用逻辑方式恢复。

（3）由于丢失部分归档日志，无法进行完全恢复。

（4）控制文件丢失，只能以备份的控制文件打开数据库。

通过创建的备份，恢复所有的数据文件，然后应用重做日志到指定的时间点（或者最后一个可用的重做日志文件），最后以open resetlogs 模式打开数据库。

不完全恢复只应用部分日志文件，必须指定结束标志

基于时间：指定具体时间

基于SCN ：实质同上但更精准

基于cancel：应用所有能够应用的日志文件，直到用户主动取消为止

基于日志序号：指定归档文件序号

不完全恢复同样支持表空间或数据文件级的不完全恢复。表空间的时间点恢复也叫TSPITR（Tablespace Point-in-time Recovery）, system表空间和undo表空间（或任何包含回滚段的表空间）不支持TSPITR.

7.2.4 、恢复操作

数据库的恢复是将数据库恢复到一个一致性的状态，分为两步：restore修复和recover恢复

（1）修复restore：将要恢复的文件从备份集中读取出来，并保持至指定路径下

（2）恢复recover：应用所有重做日志，将数据库恢复到崩溃前的状态，或应用redo,将数据库恢复到指定的时间点。

7.2.5 、resetlogs操作

在执行了不完全恢复、或使用了备份的控制文件进行恢复或执行了flashback database之后，在打开数据库时必须指定resetlogs选项。

 指定resetlogs会执行下列操作：

（1）归档当前的在线重做日志（若可以访问得到），清空内容并将日志文件序号重置为1（若在线重做日志不存在，则重建）；

（2）重置控制文件中关于在线日志文件的元数据；

（3）更新数据文件和在线重做日志文件中的resetlogs scn和重置时间信息。

resetlogs操作：正常运行中oracle内部有一个生命周期（incarnation），以 resetlogs方式打开后，oracle数据库又开始了一个新的生命周期，即重置incarnation，日志文件序号也被重置和初始化到1

10g之前的版本，数据库执行完open resetlogs之后，建议立刻进行一次全备份，因为之前版本中在执行open resetlogs操作时并不对当前的online redologs文件进行归档，这会导致归档文件不再连续，因此之前创建的备份不再有效（恢复不到当前状态了，只能恢复到open resetlogs操作之前）。10g以后open resetlogs操作会首先将当前online redologs归档（如果能够访问到的话），并且open resetlogs操作也会记入online redologs文件并正常归档。 保证了归档日志文件的连续性，之前的备份依然有效，但还是建议open resetlogs操作之后马上进行一次全库备份。

7.3 常见的备份与恢复技术

7.3.1 用户管理的备份和恢复（user-managed backup&recovery）

应用场景：

（1）误删数据文件

（2）临时进行的备份和恢复：例如架设测试一模一样的环境

7.3.2 rman备份和恢复（recover manager backup&recovery）

7.3.3 逻辑导入/导出（export/import 和 Data Pump）

数据库容量达到一定规模后，不太适用于备份（因为效率较低），但可以作为跨平台迁移使用。

7.3.4 闪回（flashback）

（1）闪回查询：通过查询undo段，重现操作之前的数据

（2）闪回表：表对象及关联索引等对象在drop后没有物理删除，而是标记删除（放入recycle bin中），若要对该对象进行恢复，执行命令即可，该操作只修改数据字典，不管要恢复的对象占用多大空空间，恢复效率高。

（3）闪回数据库

7.3.5 数据卫士（data guard）