Oracle实例恢复

本文详细阐述了数据库在正常运行和异常情况下的检查点机制,以及如何在实例崩溃或紧急关机后通过实例恢复保证数据一致性。在恢复过程中,系统监视器进程(SMON)执行前滚和回退两个阶段,确保所有已提交的修改被正确应用,同时移除未提交的更改。这一过程依赖于重做日志和控制文件来定位和恢复数据。
摘要由CSDN通过智能技术生成

数据库正常运行期间,在每个完全检查点时,检查点进程(CKPT)都会触发数据库写进程(DBWn)以保证将所有已提交的数据块都能从内存及时写入数据文件并刷新数据文件头。另外,在比如 shutdown immediate 正常关机情况下,系统会在关机命令执行的时间点(非完全检查点)执行强制检查点过程来保证将内存中提交过的所有数据块写入数据文件并刷新数据文件头,这种情况也确保了数据库的一致性,表示没有数据丢失。

但是在实例意外崩溃或紧急关机过程中,由于没有执行强制检查点,因此导致内存中大量提交过的数据块没有写入数据文件,同时数据文件头也没有刷新,那么下次数据库重启时,在 open 阶段,系统监视器进程(SMON)在根据控制文件的记录打开每一个数据文件时就会发现数据库没有同步过,这时 SMON 会自动执行实例恢复,以把丢失的内存中数据库的修改重新找回来。

实例恢复包括了前滚和回退两个阶段。前滚阶段,SMON 打开每个数据文件时会记录该文件头已同步过的 SCN 值,在全部数据文件都打开后,SMON 用已同步过的最小的 SCN 值在联机重做日志文件中逆向匹配,找到包含该 SCN 的第一条重做条目,然后从下一个 SCN 的第一条重做条目开始,把每一条重做记录所对应的事务都重新执行一遍,一直到重做日志文件结尾。增量检查点机制会对前滚操作进行优化以提高前滚的效率。现在,数据文件里就包含了截止到故障点的所有已提交和未提交的数据库修改,但是未提交的更改是不应该写入到数据库的。出现这个情况的原因在于重做条目是在事务开始执行时就产生了,但是同时开始执行的事务不一定同时结束,那些跨故障点的事务虽然没有提交,但重做条目在事务开始执行时就已经按顺序写入重做日志缓冲区并很快写入联机重做日志文件组。

在回退阶段,以只读方式打开数据库,对所有前滚过的重做条目重新检查一边,凡是提交状态的 SCN 和时间戳为空的条目,把该条目前滚时所产生的还原数据从还原段读出直接覆盖数据文件相对应的块,同时修改相应的元数据,最后把数据库状态改为读写方式。至此,数据库中就只包含了截止到故障点的所以已提交过的数据库的修改。自动的实例恢复执行完成,用户就可以正常执行事务了。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值