目的 确定Oracle DB中可能发生的故障类型 说明优化实例恢复的方法 说明检查点，重做日志文件和归档日志文件的重要性 配置快速恢复区 配置ARCHIVEDLOG模式
数据库管理员的部分职责 尽量避免数据库出现故障 延长平均故障间隔时间（MTBF） 通过冗余方式保护关键组件 -Real Application Cluster -Oracle Streams -Oracle Data Guard 缩短平均恢复时间（MTTR） 最大程度地减少数据丢失 -归档日志文件 -闪回技术 -备用数据库和Oracle Data Guard 故障类别 语句失败：单个数据库操作（选择，插入，更新或删除）失败 用户进程失败：单个数据库会话失败 网络故障：与数据库的连接断开 用户错误：用户成功完成了操作，但是操作不正确（删除了表，或输入了错误数据） 实例故障：数据库实例意外关闭 介质故障：丢失了数据库操作所需的任何文件（文件已删除或磁盘出现故障） 许多情况下，语句失败是由设计决定的，且是想要的结果。如安全策略和限额规则通常是提前制定的。 用户进程失败中进行恢复时不需要DBA进行干预，进程监视器（PMON）后台进程定期轮询服务器进程。如果PMON发现某个服务器进程的用户异常，PMON会对此事务进行恢复，回退未提交的更改和解除失败会话持有的任何锁。数据库管理员需观察变化趋势，如有多个或大量用户进程失败，则可能对用户进行培训（学习如何注销程序，而不是仅仅终止程序），还有可能存储网络或应用程序问题。 网络故障 网络故障的最佳解决方法是为网络连接提供冗余路径。通过备份监听程序，网络连接和网络接口卡可降低出现网络故障的机率，从而避免影响系统可用性。 用户可能会无意中删除或修改了数据。 -如果尚未提交或退出其程序，则只需回退即可。 -如果配置了对重做信息进行归档，则在删除归档文件之前会一直保留重做信息。Oracle LogMiner工具进行恢复 -通过将表闪回到删除前的状态，用户删除表后可从回收站中恢复表。 -如果清除了回收站，或者用户使用PURGE选项删除了表，那么在数据库配置正确的情况下，仍然可通过使用时间恢复（PITR）来恢复删除的表。 该技术由一组功能组成，支持查看数据的以前状态和来回读取数据，而无需从备份还原数据库。可以协助用户执行错误分析和恢复。 功能分析错误：
-闪回查询，查看在过去某个时间点存在的已提交的历史数据。带有AS OF子句的SELECT 命令通过时间戳或SCN引用过去的某一个时间。
SELECT ... FROM <tab> AS OF SCN SCN号; SELECT ... FROM <tab> AS OF TIMESTAMP TO_TIMESTAMP('','YYYY-MM-DD HH24:MI:SS'); 11:46:45 SQL> select to_char(current_scn) from v$database; TO_CHAR(CURRENT_SCN) -------------------------------------------------------------------------------- 6533021729470 11:47:25 SQL> select to_char(sysdate,'YYYY-MM-DD HH24:MI:SS') from dual; TO_CHAR(SYSDATE,'YYYY-MM-DDHH24:MI:SS' -------------------------------------- 2018-04-16 11:48:04 11:48:04 SQL> select min(salary) from emp; MIN(SALARY) ----------- 2090 11:48:57 SQL> update emp set salary=salary+1 where salary=2090; 已更新 2 個資料列. 11:49:35 SQL> commit; 確認完成. 11:49:38 SQL> select min(salary) from emp; MIN(SALARY) ----------- 2091 11:50:06 SQL> select min(salary) from emp as of scn 6533021729470; MIN(SALARY) ----------- 2090 11:50:13 SQL> select min(salary) from emp as of timestamp to_timestamp('2018-04-16 11:00:00','YYYY-MM-DD HH24:MI:SS'); MIN(SALARY) ----------- 2090
-闪回版本查询，查看在特定时间间隔内提交的历史数据。使用SELECT命令的VERSIONS BETWEEN子句（出于性能方面的考虑，使用了现有索引）。
VERSIONS {BETWEEN {SCN | TIMESTAMP} start AND end}
SELECT versions_startscn,
versions_starttime,
versions_endscn,
versions_endtime,
versions_xid,
versions_operation
FROM emp
VERSIONS BETWEEN TIMESTAMP TO_TIMESTAMP ('2018-04-16 14:10:08', 'YYYY-MM-DD HH24:MI:SS') AND TO_TIMESTAMP ('2018-04-16 14:26:08', 'YYYY-MM-DD HH24:MI:SS');
SELECT versions_xid XID,
versions_startscn START_SCN,
versions_endscn END_SCN,
versions_operation OPERATION,
salary
FROM emp VERSIONS BETWEEN SCN MINVALUE AND MAXVALUE;
-闪回事务处理查询，查看在事务处理级进行的所有数据库更改。
SELECT xid,
start_scn,
commit_scn,
operation,
table_name,
table_owner
FROM flashback_transaction_query
WHERE table_owner = 'HR'
AND start_timestamp >=
TO_TIMESTAMP ('2018-04-16 11:00:00', 'YYYY-MM-DD HH:MI:SS');
从用户错误中进行恢复的可能的解决方法包括： -闪回事务处理恢复，回退特定的事务处理及其从属事务处理。 -闪回表，将一个或多个表读回到其以前某一时间的内容，而不影响其他数据库对象。 -闪回删除，通过将已删除的表及其从属对象（如索引和触发器）从回收站返回到数据库，撤销删除该表的操作。 -闪回数据库，将数据库返回到某个过去时间或系统更改号（SCN）。 了解实例恢复：检查点（CKPT）进程 CKPT负责以下事项： -使用检查点信息更新数据文件头 -使用检查点信息更新控制文件 -在完全检查点向DBWn发出信号 每隔三秒（或更加频繁），CKPT进程就会在控制文件中存储一次数据，以记录DBWn已将那些修改的数据块从SGA写到磁盘。这称为“增量检查点”。检查点的用途是标识联机重做日志文件进行实例恢复的位置（这个位置称为“检查点位置”）。如果发生日志切换，则CKPT进程还会将此检查点信息写入数据文件头。 存在检查点是由于下列原因： -确保内存中已修改的数据块能够定期写入到磁盘，这样在系统或数据库出现故障时就不会丢失数据 -减少实例恢复所需的时间（只需要处理上一个检查点之后的联机重做日志文件条目，即可进行恢复） -确保所有已提交的数据在关闭期间会被写入数据文件 CKPT进程写入的检查点信息包括检查点位置，系统更改号SCN，联机重做日志文件中恢复开始的位置，有关日志的信息等等。 注：CKPT进程不会将数据块写入磁盘或重做数据块写入联机重做日志文件。 了解实例恢复：重做日志文件和日志写进程 重做日志文件 -记录对数据库进行的更改 -应多路复用以避免文件丢失 日志写入进程在下列时间进行写入 -提交时 -三分之一已满时 -每隔3秒 -在DBWn写入之前 -正常关闭之前 重做日志文件记录了由于事务处理和Oracle服务器内部操作而对数据库所做的更改。（事务处理是逻辑工作单元，由用户运行的一个或多个SQL语句组成。）重做日志文件会保护数据库，避免因断电，磁盘故障等引起的系统故障导致数据不完整。重做日志文件应该多路复用，才能确保在出现磁盘故障事件时不丢失其中存储的信息。 重做日志由重做日志文件组成，而重做日志文件组由重做日志文件及其多路复用的副本组成。每个相同的副本均称作该组的一个成员，每个组按数字标识。日志写进程（LGWR）将重做记录从重做日志缓冲区写入重做日志组的所有成员，直至填满文件或日志切换操作。然后，切换至下一组文件并执行写入操作。将以循环方式使用重做日志组。 最佳实践提示：如果可能，多路复用的重做日志文件应驻留在不同的磁盘上。 了解实例恢复 自动实例恢复或崩溃恢复 -原因是尝试打开的数据库中的文件在关闭时不同步 -使用重做日志组中存储的信息来同步文件 -涉及到两个不同的操作 -前滚，将重做日志更改（已提交的和未提交的）应用到数据文件 -回退，已执行但尚未提交的更改会放回到初始状态 Oracle DB会自动从实例故障中进行恢复。实例所需要的就是正常启动。如果Oracle Restart已启用并且配置为监视该数据库，则该启动操作会自动进行。实例会装载控制文件，然后尝试打开数据文件。如果实例发现数据文件在关闭期间尚未同步，则会使用重做日志组中包含的信息将数据库前滚到关闭时的状态。然后，将打开数据库，并回退所有未提交的事务处理。 实例恢复的阶段 1.启动实例（数据文件不同步） 2.前滚（重做） 3.文件中有已提交和未提交的数据 4.打开数据库 5.回退（还原） 6.文件中只有已提交的数据 要使实例打开一个数据文件，数据文件头中包含的系统更改号（SCN）必须与数据库控制文件中存储的当前SCN匹配。 如果编号不匹配，实例会应用联机重做日志中的重做数据，并按顺序“重做”事务处理，直到数据文件处于最新状态。所有数据文件都与控制文件同步后，就会打开数据库，此时用户可以进行登录。 应用重做日志后，会应用所有事务处理，使数据库返回到出现错误时的状态。这通常包括正在进行但尚未提交的事务处理。打开数据库之后，会回退那些提交的事务处理。在实例恢复的回退阶段结束时，数据文件只包含提交的数据。 优化实例恢复 -在实例恢复期间，必须将检查点位置与重做日志末尾之间的事务处理应用到数据文件 -通过控制检查点位置与重做日志末尾之间的差异可优化实例恢复 在实例对事务处理返回commit complete之前，在重做日志组中会记录事务处理信息。重做日志组中的信息可确保在出现错误时可恢复事务处理。另外，事务处理信息还需要写入数据文件。由于数据文件写进程比重做写进程要慢很多，因此，通常在重做日志组中记录了信息之后，才会执行数据文件写操作。（数据文件随机写进程比重做日志文件连续写进程要慢。） 每隔三秒，检查点进程就会在控制文件中记录关于重做日志中检查点位置的信息。因此，Oracle DB认为此时间点之前记录的所有重做日志项对数据库恢复来说都不需要的。 实例恢复所需的时间指的是将数据文件的最后一个检查点推进到控制文件中记录的最新SCN所需的时间。管理员通过设置MTTR目标（以秒为单位）以及调整重做日志组的大小来控制该时间。例如，对于两个重做组，检查点位置与重做日志组末尾之间的距离不能大于最小重做日志组的90%。 使用MTTR指导 -以秒或分钟为单位指定所需的时间 -默认值为0（禁用） -最大值为3600秒（1个小时） FAST_START_MTTR_TARGET初始化参数可以简化实例或系统故障的恢复时间配置。 MTTR指导可将FAST_START_MTTR_TARGET值转换为多个参数，以便在所需时间内（或者在尽量接近此时间的范围内）启用实例恢复。请注意，将FAST_START_MTTR_TARGET参数显式设置为0会禁用MTTR指导。 FAST_START_MTTR_TARGET参数的设置值必须支持系统的服务级协议。如果MTTR目标的值较小，则会增加了数据文件写入次数而增加I/O开销（这会影响性能）。但是，如果MTTR目标设置得过大，则实例在崩溃后需要花费较长的时间才会恢复。 介质故障 Oracle Corporation将介质故障定义为导致一个或多个数据库文件（数据文件，控制文件或重做日志文件）丢失或损坏的任何故障。要从介质故障中进行恢复，需要还原并恢复缺失的文件。为确保可从介质故障中恢复数据库，请遵循后面的最佳实践。 配置可恢复性 要配置数据库的最大可恢复性，必须执行以下操作： -计划常规备份 修复介质故障时通常需要从备份中还原丢失或损坏的文件 -多路复用控制文件 与数据库关联的所有控制文件都是相同的。如果丢失一个控制文件，则并不难恢复；但如果丢失了所有控制文件，则很难恢复。为了避免丢失所有控制文件，至少要有两个副本。 -多路复用重做日志组 要从实例故障或介质故障中进行恢复，可使用重做日志信息将数据文件前滚到上次提交的事务处理。如果重做日志组依赖于一个重做日志文件，那么丢失这个文件意味着很可能会丢失数据。至少要确保每个重做日志组有两个副本；如果可能的话，每个副本都应在不同的磁盘控制器中。 -保留重做日志的归档副本 如果丢失了某个文件从备份中进行还原，则实例必须应用重做信息，以便将该文件推进到控制文件中包含的最新SCN。使用默认设置时，重做信息写入数据文件后，数据库会覆盖这些信息。数据库可配置为在重做日志的归档副本中保留重做信息。这称为将数据库置于archivelog模式下。 配置快速恢复区 -强烈建议使用，可简化备份存储管理 -使用存储空间（与工作数据库文件分开） -位置由DB_RECOVERY_FILE_DEST参数指定 -大小由DB_RECOVERY_FILE_DEST_SIZE参数指定 -足够大，可存放备份，归档日志，闪回日志，多路复用控制文件和多路复用重做日志 -根据保留策略自动进行管理 配置快速恢复区意味着确定了位置，大小和保留策略。 快速恢复区是磁盘上为包含归档日志，备份，闪回日志，多路复用控制文件和多路复用重做日志而专门留出的空间。快速恢复区可简化备份存储管理，因此强烈建议使用该功能。放置快速恢复区的存储位置应该与数据库的数据文件以及主要联机日志文件和控制文件的位置不同。 分配给快速恢复区的磁盘空间量取决于数据库的大小和活动级别。通常情况下，快速恢复区越大，就越有用。理想情况下，快速恢复区应足够大，可存放数据文件和控制文件副本，以及基于保留策略从保留的备份恢复数据库所需的闪回日志，联机重做日志和归档日志。（简而言之，快速恢复区至少应为数据库大小的两倍，以便可保留一个备份和若干归档日志。） 快速恢复区的空间管理由备份保留策略控制。保留策略确定文件何时过时，即何时这些文件对达到数据恢复目标已不再有用。Oracle DB通过删除不再需要的文件自动管理该存储。 多路复用控制文件 为了防范数据库故障，数据库控制文件应保存多个副本。 控制文件是一个二进制小文件，用于说明数据库的结构。只要装载或打开数据库，oracle服务器必须能够写入这个文件。如果这个文件不存在，就不能装载数据库，因此需要恢复或重新创建控制文件。数据库应该至少有两个控制文件，且这些文件应位于不同的磁盘，这样才能将由于丢失某个控制文件造成的影响降至最低。 因为所有控制文件必须是随时可用的，所以丢失一个控制文件就会导致实例出错。但在这中情况下进行恢复并不难，只需复制其中一个控制文件即可。如果丢失了所有控制文件，则进行恢复要难一些，但这种故障通常也不是灾难性故障。 添加控制文件 如果使用ASM作为存储技术，则只要有两个控制文件且每个磁盘组（例如+DATA和+FRA）上有一个控制文件，则不需要进行进一步的多路复用。对于使用OMF的数据库（例如使用ASM存储的数据库），在使用RMAN（或通过Oracle Enterprise Manager）的恢复过程中，必须创建所有附加控制文件。在使用常规系统存储的数据库中，添加控制文件是一个手动操作： 1.使用命令变更SPFILE ALTER SYSTEM SET CONTROL_FILES=’/u01/app/oracle/oradata/orcl/control01.ctl’,’/u01/app/oracle/fast_recover_size/orcl/control02.ctl’,’/u03/app/oracle/oradata/orcl/control03.ctl’ scope=spfile; 2.关闭数据库 3.使用操作系统将现有控制文件复制到新文件选择的位置 4.打开数据库 重做日志文件 多路复用重做日志组可避免介质故障和数据丢失。这会增加数据库I/O。建议重做日志组满足以下条件： -每个组至少有两个成员（文件） -每个成员 -如果使用文件系统存储，则位于单独的磁盘或控制器上 -如果使用ASM，则位于单独的磁盘组上（例如+DATA和+FRA） 注：多路复用重做日志可能会影响数据库整体性能。 重做日志组由一个或多个重做日志文件组成。组中的每个日志文件都是相同的。Oracle Corporation建议每个重做日志组至少包含两个文件。如果使用文件系统存储，则每个成员应该分布在单独的磁盘或控制器上，这样在单个设备出现故障时就不会破坏整个日志组。如果使用ASM存储，则每个成员应该位于单独的磁盘组中，例如+DATA和+FRA。丢失了整个当前日志组是一种最严重的介质故障，因为这会导致数据丢失。但丢失了包括多个成员的日志组中的一个成员是微不足道的，这并不会影响数据库操作（只会导致在预警日志中发布预警）。 请记住，由于不能在事务处理信息写入日志之前完成提交，因此多路复用重做日志可能会严重影响到数据库的性能。必须将重做日志文件置于速度最快的控制器服务的速度最快的磁盘中。请尽量不要将其它任何数据库文件与重做日志文件保存在同一磁盘上（除非使用自动存储管理ASM）。由于给定时间只能写入一个组，因此，同一磁盘中包含多个组的成员不会有什么性能影响。
alter database add logfile group 1 ('/u01/app/oracle/oradata/orcl/p_redo01_01.log','/u02/app/oracle/oradata/orcl/p_redo01_02.log') size 512M;
alter database add logfile group 2 ('/u01/app/oracle/oradata/orcl/p_redo02_01.log','/u02/app/oracle/oradata/orcl/p_redo02_02.log') size 512M;
alter database add logfile group 3 ('/u01/app/oracle/oradata/orcl/p_redo03_01.log','/u02/app/oracle/oradata/orcl/p_redo03_02.log') size 512M;
归档日志文件 要保留重做信息，请通过执行以下步骤，创建重做日志文件的归档副本 1.指定归档日志文件命名惯例 2.指定一个或多个归档日志文件的位置 3.将数据库切换为ARCHIVIELOG模式 Oracle 归档日志生成格式[(%r重做日志id %t线程号rac节点 %s日志序列号)->必须存在 (%d 数据库id)->可选]
alter system set log_archive_format='arch_%r_%t_%s.arc' scope=spfile;
alter system set log_archive_dest='location=/u01/archive' scope=spfile;
shutdown immediate
startup mount
alter database archivelog;
alter database open;
归档（ARCn）进程 -是可选的后台进程 -为数据库设置了ARCHIVELOG模式后会自动归档联机重做日志文件 -保留对数据库所做的所有更改的记录 ARCn是可选的后台进程。但是，该进程对于在磁盘损坏后恢复数据库非常重要。联机重做日志组填满后，Oracle实例将开始对下一个联机重做日志组进行写入。从一个联机重做日志组切换到另一个联机重做日志组的过程称为“日志切换”。ARCn进程在每次日志切换时都会对已填满的日志启动归档。该进程先自动归档联机重做日志组，然后在重用该日志组，从而保留对数据库所做的所有更改。这样即使磁盘驱动器损坏，也可以将数据库恢复故障点。 DBA必须做出的一个重要决策是将数据库配置为ARCHIVELOG模式下运行还是将其配置在NOARCHIVELOG模式下运行。 -在NOARCHIVELOG模式下，每次进行日志切换时都会覆盖联机重做日志文件。 -在ARCHIVELOG模式下，必须先归档不活动的已填满联机重做日志文件组，然后才能再次使用这些联机重做日志文件。 -ARCHIVELOG模式对大多数备份策略而言是必不可少的，并且这种模式很容易进行配置。 -如果归档日志文件目标位置填满或者无法写入，数据库最终将停止。从归档日志文件目标位置删除归档文件，数据库将继续操作。 总结： DBA部分职责（避免故障，延长故障间隔时间，组件冗余，减少MTTR恢复时间，减少数据丢失） 数据库可能发生的故障： 语句失败 用户进程失败 网络故障 用户误操作 实例故障 介质故障 资料误删除后的闪回操作，AS OF闪回查询，闪回版本查询，闪回事务查询 了解实例恢复：CKPT检查点进程，DBWn数据库写入进程，LGWR日志写入进程，ARCn归档进程。重做日志和归档日志作用。恢复步骤（不同步->前滚->应用->打开数据库->回退->提交数据） 优化实例恢复，合理配置MTTR指定 介质恢复：多路复用（控制文件，重做日志文件），配置快速恢复区，归档模式和常规备份