ORACLE_OCP之备份-恢复概念与实例恢复深入

ORACLE_OCP之备份-恢复概念与实例恢复深入

• 文章目标：
  • 确定Oracle数据库中可能发生的故障类型
  • 描述实例恢复
  • 描述完全和不完全的恢复

一、DBA职责

• 尽可能保护数据库免于灾难
• 增加平均故障间隔时间（MTBF）–减少故障率
• 使用冗余策略保护关键组件
• 减少平均恢复时间（MTTR）–减少数据库恢复时间
• 最大限度地减少数据丢失。 DBA可以遵循最佳的实践经验来配置其数据库，这样就不会丢失任何已提交的事务。 有助于保证这一点的实体包括：
  • Archive log files-归档日志文件（在本课程的后面讨论）
  • Flashback technology-闪回技术
  • Oracle Data Guard-ORACLE数据卫士（不属于ORACLE OCP考试范畴会在后面做专题讲解）

二、故障级别

• 故障通常分为:
  • 语句错误
  • 用户进程故障
  • 网络故障
  • 用户人为故障
  • 实例故障
  • 介质故障

三、语句错误

四、用户进程故障

五、网络故障

六、用户错误

七、闪回技术

• 使用闪回技术:
  • 查看过去的数据状态
  • 及时修复数据
  • 协助用户进行错误分析和恢复

• Oracle数据库包括Oracle闪回技术：一组可支持查看数据的过去状态与恢复数据的功能，无需从备份中还原数据库。借助这项技术，您可以帮助用户分析错误并从错误中恢复。对于已做出错的用户，请使用以下内容分析错误：
  • 闪回查询：查看过去某个时间存在的已提交数据。（已修改或已删除的数据）
  • 闪回版本查询：查看特定时间间隔内已经提交了的行记录。（已经提交的事务）。
  • 闪回事务查询：查看在事务级别进行的所有数据库更改。
  • 闪回事务回退：回滚特定事务和从属事务
  • 闪回表：在不影响其他数据库对象的情况下，将一个或多个表上恢复成过去的样子
  • 闪回删除（DROP）：通过将删除的表与相关对象（例如索引和触发器）一起从回收站返回到数据库，来消除删除表的影响
  • 闪回数据库：将数据库返回到过去的时间

八、实例故障

九、了解实例恢复：检查点（CKPT）进程深入

• CKPT负责:
  • 使用检查点信息更新数据文件头
  • 使用检查点信息更新控制文件
  • 检查点进程向DBWn发出信号

十、SCN 系统改变号

• 在Oracle中SCN相当于它的时钟，在现实生活中我们用时钟来记录和衡量我们的时间，而Oracle就是用SCN来记录和衡量整个Oracle系统的更改。
• Oracle中checkpoint是在一个特定的“时间点”发生的，衡量这个“时间点”用的就是SCN，因此当一个checkpoint发生时SCN会被写入文件头中以记录这个checkpoint。
• 为什么不用系统时钟作为数据库内部记录时间？
  • 是因为系统时钟可能会发生改变（人为调节或者时钟服务器自动同步）。
• 要了解实例恢复，您需要了解某些后台进程的功能：
  • CKPT进程每三秒钟（或更频繁地）将数据存储在控制文件中，以记录DBWn从SGA写入磁盘的修改后的数据块。这称为“增量检查点”。检查点的目的是在联机重做日志文件中标识开始实例恢复的位置（称为“检查点位置”）。
  • 如果发生日志切换，则CKPT进程还将此检查点信息写入数据文件头中。
• 存在检查点的原因如下：
  • 确保将内存中修改后的数据块定期写入磁盘，以便在系统或数据库出现故障时不会丢失数据
    为了减少实例恢复所需的时间（仅需要处理最后一个检查点之后的联机重做日志文件条目以进行恢复。）
  • 确保在关机期间已将所有提交的数据写入数据文件（完全检查点）
• CKPT进程编写的检查点信息包括检查点位置，系统更改号（SCN），在线重做日志文件中开始恢复的位置，有关日志的信息等。

注意：CKPT进程不会将数据块写入磁盘，也不会将重做块写入在线重做日志文件。

十一、完全检查点（normal checkpoint）

• 在Oracle8i之前，数据库的发生的检查点都是完全检查点。完全检查点会将数据缓冲区（DB_BUFFER_CACHE）里面所有的脏数据块写入相应的数据文件中，同时将最新的checkpoint scn更新到所有的数据文件头部及控制文件。保证数据库的处于一致的状态。需要注意的是，完全检查点产生的时候，CKPT并不是把当前完全检查点发生那一时刻的SCN更新到控制文件和数据文件头，而是将这个触发检查点时刻DBWn当前刚写完 dirty buffer（脏数据）对应的SCN更新到控制文件和数据文件头，也就是说，更新控制文件和数据文件头的SCN是滞后于完全检查点的发生那一时刻的SCN的，因为检查点发生的时候要写入dirty buffer还没有写入，自然不能立即更新成当前的SCN了。

• 下面这些操作将会触发完全检查点（normal checkpoint ）事件：

1. 日志切换：通过ALTER SYSTEM SWITCH LOGFILE;
2. DBA发出checkpoint命令，通过ALTER SYSTEM checkpoint;
3. 对数据文件进行热备时，针对该数据文件的checkpoint也会进行，ALTER TABLESPACE TS_NAME BEGIN BACKUP/END BACKUP。
4. 当运行ALTER TABLESPACE/DATAFILE READ ONLY的时候。
5. 数据库正常shutdown (immediate,transcational,normal)。

注意：日志切换会导致checkpoint事件发生，但是checkpoint发生却不会导致日志切换。

十二、了解实例恢复：REDO FILE和LGWR深入

• Redo log files:
  • 记录对数据库的更改
  • 应该多路复用以防止丢失
• Log Writer (LGWR) writes:
  • 提交时
  • 当三分之一充满
  • 每三秒钟
  • 在DBWn写入之前
  • 彻底关机之前
  • 。。。。。。

十三、实例恢复

• 自动实例恢复或者实例崩溃后恢复:
  • 尝试打开由不规范关机而导致的数据不一致的数据库
  • 使用存储在重做日志组中的信息与UNDO里的信息来同步数据文件
  • 涉及两个不同的操作：前滚和回滚

十四、实例恢复过程

• 实例启动（数据文件不同步）
• 前滚（重做）：已提交未写入
• 文件中包含已提交和未提交的数据。经过前滚后只剩下未提交已写入的数据
• 数据库已打开
• 回滚（撤消）：未提交已写入或未提交事务记录进行回滚
• 文件中已提交的数据

实例启动时要经过三个阶段：

• 1、STARTUP NOMOUNT； 使用SPFILE在内存中产生实例，并找到控制文件位置。

• 2、ALTER DATABASE MOUNT; 使用控制文件把所有的数据文件 日志文件进行挂载，并确定相关文件状态。

• 3、ALTER DATABASE OPEN；打开数据库（此阶段进行实例恢复）

• 第一个阶段和第二个阶段都不会发生实例恢复，都不会检查数据库的完整性，只有在第三个阶段才会去检查数据库的完整性。如果完整性有问题了就需要恢复了。

• SQL> alter database open; 第三个阶段将数据库打开发生实例恢复

• 前滚，即redo的过程不是执行SQL的过程，实际上是一个数据块修正的过程，因为数据库还没有打开，SQL语句都没有办法解析，所以使用redo在数据块上面进行更新。在将所有可以应用的redo应用完之后，这个时候数据库就可以打开了。数据库打开就可以使用了，这个时候就有了回滚的问题。在数据库非正常关闭情况下，有些事务还没有提交（有可能已经被写入到数据库中），可能数据库就关闭了，这些事务将数据修改了但是没有提交，重启之后就要将这些没有提交的事务回滚。回滚就将UNDO中回滚段相应的数据拿回来就行了。回滚是在数据库打开之后做的，而不是先前滚再回滚最后打开数据库。

十五、实例恢复调优

• 在实例恢复期间，必须将检查点位置和重做日志结尾之间的事务应用于数据文件。
• 您可以通过控制检查点位置和重做日志结束之间的差异来调整实例恢复。

十六、介质故障

十七、比较完全恢复和不完全恢复

• 恢复可以有两种范围:
  • 完全恢复：使数据库或表空间保持最新状态，包括到请求恢复的时间点所做的所有提交的数据更改
  • 不完全或时间点恢复（PITR）：在请求恢复操作之前，将数据库或表空间恢复到过去的指定时间点

十八、完全恢复过程

十九、基于时间点恢复过程（不完全恢复）