instance reovery & crash recovery 关系说明

数据备份和恢复是指采用的各种策略来保护数据库的数据，防止数据的丢失，并在数据丢失发生之后重构数据。数据的重构一般通过介质恢复来完成，包括还原备份的数据文件（restore）、前滚和回滚三个部分。

备份可以分为物理备份和逻辑备份。物理备份是物理数据文件的拷贝。物理备份可以通过RMAN（Recovery Manager）或操作系统工具来完成。而逻辑备份是使用Export工具将逻辑数据抽出存放到二进制文件中。

还原（restore）备份的数据文件或控制文件是重建这个文件，并使得Oracle数据库可以使用这个文件。恢复（recover）一个还原过的数据文件是通过应用归档重做日志和在线重做日志更新数据文件，也就是说，将备份完成之后数据库中所有改变重现一次。

当数据文件已经被还原，用户必须手工初始化介质恢复（media recovery）。介质恢复利用归档日志和在线重做日志来恢复数据文件。通过执行RECOVER命令进行介质恢复。

和介质恢复不同，崩溃恢复（crash recovery）和实例恢复（instance recovery）由Oracle自动完成。Crash和instance恢复将数据库恢复到实例失败前的那个事务一致性状态。Crash恢复指单实例数 据库崩溃或Rac环境中所有实例都崩溃后的恢复。而instance恢复指Rac环境中由目前存活实例启动，对失败实例进行的恢复。

Crash和instance恢复引入两个不同的操作：前滚和回滚。首先，通过应用在线重做日志中的已提交和未提交的事务来实现对当前联机的数据文件的前滚操作，然后回滚所有未提交的事务到它们的初始状态。

需要进行恢复的错误和故障：

介质故障：当Oracle对磁盘的文件进行读写操作时遇到的错误。通常需要进行介质恢复来恢复数据库的使用。

用户错误：由于用户误操作等认为错误造成的。用户错误很难避免，但是可以通过合适的权限控制来减少发生的概率。解决方法一般是由逻辑备份导入或执行表空间及时点恢复（tablespace point-in-time recovery(TSPITR)）。

数据库实例故障：当出现的问题阻止数据库的继续运行，则会出现数据库实例故障。Oracle实例故障恢复包括以下步骤：

1、对在线重做日志中还没有写入数据文件的部分进行前滚。这个步骤又叫做缓存恢复（cache recovery）。

2、打开数据库

3、将所有在数据库实例失败的时候处于活动状态的事务标志为DEAD，并把包括这些事务的回滚段或UNDO段标志为部分可用。

4、回滚死的事务。这个步骤叫做事务恢复（transaction recovery）。

5、解决数据库实例失败时处于二阶段提交的所有悬而未决的分布事务。

6、如果新的事务需要访问被死事务锁住的记录，则会自动回滚死事务来释放锁。

语句级错误：语句级错误一般不需要进行恢复，Oracle自动会回滚到这个语句执行之前的状态。

进程失败：进程失败是指用户进程、服务器进程或后台进程的失败。Oracle的后台进程PMON自动检查并释放数据库中失败的用户进程或服务器进程。如果是后台进程的失败，则Oracle数据库很可能无法再正常运行，这时候经常需要关闭并重新启动数据库。

网络错误：由于网络问题造成的。Oracle的后台进程PMON或RECO会自动解决由于网络错误造成的错误。

数据库恢复相关的数据结构：

日志文件：包括联机重做日志和归档重做日志。记录Oracle数据库的所有操作，当数据库恢复时，可以将记录的操作重现。

回滚段和UNDO段：数据库恢复时，应用日志文件中的记录后，通过回滚所有回滚段中尚未提交的事务将数据库恢复到一致性的状态。

控制文件：记录数据库物理结构的状态。

数据库归档模式：

非归档模式：不归档重做日志，重做日志循环时直接覆盖，只能进行crash和instance恢复，无法进行介质恢复。

归档模式：重做日志覆盖前必须进行归档，当发生磁盘故障时，归档模式的数据库可以完全恢复。

Oracle备份和恢复方案：

主要包括两种方法来执行备份和恢复操作：RMAN和用户管理备份和恢复（user-managed backup and recovery）。

除了物理备份这两种方案，还可以使用Export工具生成的逻辑备份作为备份策略的补充。

可参见alert_.log文件中如下所示：

alter database open
Fri Nov 09 08:47:18 2007
Beginning crash recovery of 1 threads
Fri Nov 09 08:47:18 2007
Started first pass scan
Fri Nov 09 08:47:19 2007
Completed first pass scan
4273 redo blocks read, 66 data blocks need recovery
Fri Nov 09 08:47:19 2007
Started recovery at
Thread 1: logseq 1, block 56360, scn 0.0 //这里的scn为什么是0.0？
Recovery of Online Redo Log: Thread 1 Group 3 Seq 1 Reading mem 0
Mem# 0 errs 0: C:ORACLEORADATAA815REDO03.LOG
Fri Nov 09 08:47:19 2007
Ended recovery at
Thread 1: logseq 1, block 60633, scn 0.244682
66 data blocks read, 66 data blocks written, 4273 redo blocks read
Crash recovery completed successfully
Fri Nov 09 08:47:21 2007
Thread 1 advanced to log sequence 2
Thread 1 opened at log sequence 2
Current log# 1 seq# 2 mem# 0: C:ORACLEORADATAA815REDO01.LOG
Successful open of redo thread 1.
Fri Nov 09 08:47:21 2007
SMON: enabling cache recovery
Fri Nov 09 08:47:23 2007
Undo Segment 1 Onlined
Undo Segment 2 Onlined
Undo Segment 3 Onlined
Undo Segment 4 Onlined
Undo Segment 5 Onlined
Undo Segment 6 Onlined
Undo Segment 7 Onlined
Undo Segment 8 Onlined
Undo Segment 9 Onlined
Undo Segment 10 Onlined
Successfully onlined Undo Tablespace 1.
Fri Nov 09 08:47:23 2007
SMON: enabling tx recovery
Fri Nov 09 08:47:23 2007
Database Characterset is ZHS16GBK
replication_dependency_tracking turned off (no async multimaster replication found)
Completed: alter database open

声明: 除非转自他站（如有侵权，请联系处理）外，本文采用 BY-NC-SA 协议进行授权 | 智乐兔
转载请注明：转自《instance reovery & crash recovery 关系说明》
本文地址：https://www.zhiletu.com/archives-283.html
关注公众号：