OCP认证考试指南（18）：配置数据库的备份与恢复（1）

1、备份与恢复问题

考虑业务需求、性能以及资金成本的最终结果通常是一个折衷的方案。记录这个方案极其重要，记录的形式通常是一个服务级别协议（service level agreemenet）。

服务级别协议与备份和恢复相关的3个方面为：

• 平均失败时间（mean time betwwen failures，简写MTBF）
• 平均恢复时间（mean time to recover，简写MTTR）
• 数据损失量

DBA的目标就是减少MTTR和数据损失的同时增加MTBF。

MTBF指的是数据库出现失败的频繁度。Oracle提供两种有助于百分之百可用性的高级选项：RAC和Streams。
MTTR指的是数据库出现失败后的停机时间。
第三个目标将数据的损失量最小化。

2、失败类别

2.1、语句失败

导致语句失败的4个常见原因为：
无效数据（invaild data）：这种情况通常是由于违反了格式或完整性约束所造成的。
缺少权限（space management）：
空间分配问题：相关的语句失败原因包括：由于表空间已满而无力扩展某个段；耗尽撤销空间；运行使用磁盘排序的查询时临时空间不足；某个用户达到配额；某个对象达到最大区间限制。
逻辑错误（logic error）：在某些情况下，编程人员完全可能开发数据库无法运行的代码。

2.2、用户进程失败

用户进程可能由于多种原因而失败，包括：用户并非登出的异常退出；终端的重新启动；导致地址违规的程序。

2.3、网络失败

需要考虑3个方面：侦听器、网络接口卡以及路由。

2.4、用户错误

解决用户错误的理想方式是首先防止这些错误的出现。闪回查询是针对过某时存在的数据所运行的查询。通过使用撤销数据，就可以只为当前会话构造读一致的数据库。

^?[Copy to clipboard]View Code SQL

SQL> conn scott/tigerConnected.SQL> delete from emp; 14 rows deleted. SQL> commit; Commit complete. SQL> select count(*) from emp;   COUNT(*)----------         0 ################################################# 这里的时间1/24是1小时，1/24/60是1分钟，恢复2分钟前被delete的记录################################################ SQL> insert into emp select * from emp as of timestamp(sysdate - 2/24/60); 14 rows created. SQL> commit; Commit complete. SQL> select count(*) from emp;   COUNT(*)----------        14 SQL> drop table emp; Table dropped. SQL> select count(*) from emp;select count(*) from emp                     *ERROR at line 1:ORA-00942: table or view does not exist SQL> flashback table emp to before drop; Flashback complete. SQL> select count(*) from emp;   COUNT(*)----------        14

Log Miner是一种从联机和归档的重做日志中抽取信息的高级工具。重做包含数据块发生的所有变化。通过抽取表数据块的变化，可以重新构造所做的变化，所以重做能够用于早先时间的还原备份。如果具有相关日志的副本，那么Log Miner能够返回至先前的任意时刻，闪回查询只能返回至撤销表空间所允许的时刻。

对于修正用户错误来说，不完全恢复与闪回数据库是作用更为显著的方法。

2.5、介质失败

介质失败意味着对磁盘的损坏，因此磁盘上存储的文件会受到损坏。为了应对介质失败，必须生成控制文件、联机重做日志以及归档的重做日志文件的多个副本，此外还必须对控制文件、数据文件以及归档日志文件进行备份。不必备份重做日志，事实上，重做日志在被复制至归档日志时会进行备份。复用并不能保护数据文件，数据文件必须通过硬件冗余受到保护。

2.6、实例失败

实例失败（instance failure）是实例的无序关闭，通常称为崩溃（crash）。断电、关闭或重启服务器以及许多至关重要的硬件问题都会导致实例失败。在后台进程可能失败的某些情况下，也会触发即时的实例失败。其结果都与执行SHUTSOWN ABORT命令的结果相同。

实例失败后，数据库完全可能丢失已提交的事务以及存储未提交的事务，从而使数据库会出现讹误。这是因为服务器进程在内存中进行工作，进程更新了数据库高速缓存区内的数据块与撤销块。而这时候，DBWn进程并没有完全将更新后的数据块写至数据文件。不过LGWR进程尽可能实时地进行写操作。

3、实例恢复

3.1、实例恢复的过程

实例恢复只不过是使用联机日志文件的内容将数据库高速缓存区重新构建至崩溃之前的状态。这个过程将重演从崩溃时未被写至磁盘的数据块的相关重做日志中抽取出的所有变化。完成上述操作后，就能打开数据库。此时，数据库仍然存在讹误，但由于用户看到的实例已被修复，因此允许用户进行连接。实例恢复的这个阶段称为前滚，该阶段将恢复所有变化。每条重做记录都具有重新构造一个变化所需的最少信息：数据块的地址以及新值。前滚期间，会读取每条重做记录，相应的数据块从数据文件载入数据库高速缓存区，并且应用相应的变化。之后，数据块会被写回磁盘。

实例恢复是自动的和不可避免的，使用STARTUP调用实例恢复。首先，数据库过度到加载模式时，SMON进程会读取控制文件。之后，数据库过度到打开模式时，SMON进程会查看所有数据文件和联机重做日志文件的文件头。此时，如果已经出现实例失败，由于文件头没有全部同步，SMON进程会发现实例失败，从而进入实例恢复例程，数据库只能在前滚阶段结束之后才能被真正地打开。

如果执行了STARTUP命令，那么决不会丢失任何数据。在发生任何崩溃之后，都应当尝试执行STARTUP命令并查看崩溃的程度。

3.2、实例恢复不可能导致数据库出现讹误

因为LGWR进程总是先于DBWn进程进行写操作，并且在提交的同时进行实时的写操作，所以在重做流中始终存在足够的信息，从而能重新构建任何未被写入数据文件的已提交变化以及回滚任何已被写入数据文件的未提交变化。重做与回滚的这种实例恢复机制能够使Oracle数据库绝对不可能出现讹误。

3.3、调整实例恢复

MTTR（各种事件出现之后的平均恢复时间）是许多服务级别协议的一个重要部分。实例恢复能够保证不产生讹误，但是在数据库打开之前需要耗费大量的时间来完成实例恢复的前滚。这个时间取决于两个因素：需要读取的重做数，以及应用重做时需要在数据文件上完成的读/写操作数。这两个因素都受检查点的控制。

检查点（）保证了某个特定的时间，DBWn进程将构成一个特定系统更改号（System Change Number，简写为SCN）的所有数据变化都已写入数据文件。在一个实例崩溃事件中，只有SMON进程需要重演从上一个检查点位置开始生成的重做。无论是否被提交，在这个检查点位置之前的所做的全部变化都已被写入数据文件。因此，显然不需要使用重做来重新构造在该检查点位置之前已提交的事务。此外，在这个检查点之前未提交事务所做的变化也会被写入数据文件，因此也不需要重新构造该检查点之前的撤销数据，回滚需要使用的这些数据已经存在于磁盘上的撤销段内。

检查点位置越近，实例恢复就越快。

参数FAST_START_MTTR_TARGET使得实例恢复时间的控制变得十分容易。以秒为单位指定该参数，Oracle随后将确认DBWn进程在实例崩溃后能够以足够快的速度将数据块写至磁盘，从而不会超过指定的秒数。因此，设置的FAST_START_MTTR_TARGET参数值越小，DBWn进程将会更努力的尝试最小化检查点位置与实际时间之间的间隔。须要注意，如果设置了一个不实际的较小值，那到DBWn进程无论如何也不可能达到要求。

^?[Copy to clipboard]View Code SQL

SQL> conn system/oracleConnected. ################################################# fast_start_mttr_target参数设置为0，从而禁用检查点调整功能################################################ SQL> alter system set fast_start_mttr_target = 0; System altered. ################################################# 建表和启动事务，模拟工作负荷################################################ SQL> create table t1 as select * from all_objects where 1 = 2; Table created. SQL> insert into t1 select * from all_objects; 11185 rows created. ################################################# 查询显示实例恢复期间需要在数据文件上进行的读/写操作数以及必须处理的重做数据块# estimated_mttr显示了以秒为单位的实例恢复时间################################################ SQL> select recovery_estimated_ios, actual_redo_blks, estimated_mttr  2  from v$instance_recovery; RECOVERY_ESTIMATED_IOS ACTUAL_REDO_BLKS ESTIMATED_MTTR---------------------- ---------------- --------------                  1311            17326             16 SQL> commit; Commit complete. ################################################# 这是提交后的查询，可以看见结果变化不大，因为COMMIT不会对DBWn进程产生影响################################################ SQL> select recovery_estimated_ios, actual_redo_blks, estimated_mttr  2  from v$instance_recovery; RECOVERY_ESTIMATED_IOS ACTUAL_REDO_BLKS ESTIMATED_MTTR---------------------- ---------------- --------------                  1311            17343             16 ################################################# 手动执行检查点进程，可以看到，recovery_estimated_ios、actual_redo_blks已经清零# estimated_mttr不会变小因为该列的内容不会被实时更新################################################ SQL> alter system checkpoint; System altered. SQL> select recovery_estimated_ios, actual_redo_blks, estimated_mttr  2  from v$instance_recovery; RECOVERY_ESTIMATED_IOS ACTUAL_REDO_BLKS ESTIMATED_MTTR---------------------- ---------------- --------------                    10                6             13