实例恢复概述
证据回收 是将在线重做日志中的记录应用于数据文件的过程,以重建在最近检查点之后所做的更改。
当管理员尝试打开以前关闭不一致的数据库时,实例恢复就会自动发生。
个案恢复的目的
实例恢复确保数据库在实例失败后处于一致状态。由于甲骨文数据库如何管理数据库的变化,数据库的文件可以留在不一致的状态。
A 重新做线 是一个实例生成的所有更改的记录。单实例数据库有一个重做线程,而甲骨文RAC数据库有多个重做线程,每个数据库实例一个线程。
当一个 交易 是承诺的, 日志编写程序 将内存中剩余的重做条目和事务SCN写入 在线重做日志 .但是, 数据库撰写人(数据库) 当数据文件最有效率时,进程会将修改后的数据块写入数据文件。因此,数据文件中可能暂时存在未提交的更改,而数据文件中尚未存在提交的更改。
如果一个开放数据库的实例失败,其中一个原因是SHUTDOWN ABORT 声明或异常终止,然后可能导致下列情况:
事务提交的数据块不会写入数据文件,只会出现在 在线重做日志 .这些更改必须重新应用于数据文件。
数据文件包含实例失败时未提交的更改。必须回滚这些更改,以确保事务一致性。
实例恢复只使用在线重做日志文件和当前的在线数据文件来同步数据文件并确保它们是一致的。
当甲骨文数据库执行实例恢复时
是否需要实例恢复取决于重做线程的状态。
当数据库实例以读写方式打开时,在控制文件中标记重做线程打开,当实例一致关闭时标记关闭线程。如果在控件文件中标记为打开的重做线程,但是没有活实例持有与这些线程相对应的线程队列,那么数据库需要实例恢复。
甲骨文数据库在下列情况下自动执行实例恢复:
数据库在一个单实例数据库或甲骨文RAC数据库的所有实例失败后首次打开。这种形式的实例恢复也被称为 碰撞恢复 .甲骨文数据库回收终止实例的在线重做线程。
甲骨文RAC数据库的一些实例,但并非所有实例都失败了。实例恢复由配置中的一个幸存实例自动执行.
SMon后台流程执行实例恢复,自动应用在线重做。不需要用户干预。
检查站的重要性,例如恢复
实例恢复使用检查点来确定哪些更改必须应用于数据文件。检查点位置保证每一个与SCN一起提交的更改 低于 检查点SCN保存到数据文件中。
下图描述了在线重做日志中的重做线程。
在实例恢复期间,数据库必须应用检查点位置和重做线程结束之间发生的更改。如图所示 图13-5 ,有些更改可能已经写入数据文件。但是,只有当SCNS低于检查点位置时才会改变。 保证的 在磁盘上。
实例恢复阶段
实例恢复的第一阶段称为 缓存回收 或 向前滚动 ,并将在线重做日志中记录的所有更改重新应用到数据文件中。
因为在线重做日志包含撤销数据,所以向前滚动也会重新生成相应的撤销段。向前滚动可以通过许多在线重做日志文件,以使数据库及时前进。在向前滚动后,数据块包含在线重做日志文件中记录的所有提交的更改。这些文件还可能包含未提交的更改,这些更改在失败之前保存到数据文件中,或者记录在在线重做日志中,并在缓存恢复期间引入。
在向前滚动之后,任何未提交的更改都必须撤销。甲骨文数据库使用检查点位置,该位置保证在磁盘上保存每一个带有比检查点低的SCN的提交更改。甲骨文数据库应用撤销块回滚数据块中的未提交更改,这些更改是在失败之前编写的或在缓存恢复期间引入的。这个阶段叫做 回滚 或 交易回收 .
下图说明了向前滚动和向后滚动,这两个步骤是从数据库实例失败中恢复的必要步骤。
图13-6基本实例恢复步骤:前滚和后滚
甲骨文数据库可以根据需要同时回滚多个事务。在失败时处于活动状态的所有事务都被标记为终止。新的事务可以自己回滚单独的块来获取所需的数据,而不是等待SMon进程回滚终止的事务。
