Oracle 实例恢复
Oracle 实例恢复
--=======================
-- Oracle 实例恢复
--=======================
一、Oracle实例失败
Oracle实例失败多为实例非一致性关闭所致，通常称为崩溃(crash)。实例失败的结果等同于shutdown abort。
实例失败的原因
电源负载故障
硬件故障
后台进程失败
异常关闭数据库
实例失败后的状况
数据库可能丢失已提交的事务以及存储了未提交的事务，导致数据库出现不一致的情况
解决方案
使用startup 重新启动实例。实例实现自动恢复，根据联机日志文件前滚提交的事务，回滚未提交的事务
查看告警日志、跟踪日志等找出出现故障的原因
更多常见的故障请参考：Oracle 常见故障及日常规划
二、检查点
检查点在体系结构中已经讨论，实例的恢复与检查点息息相关，因此再次讨论检查点进程
1.什么是检查点
是一个数据库事件，用于减少崩溃恢复时间，检查点位置决定了实例恢复的起始位置
由后台进程触发，触发时ckpt进程通知dbwn进程将数据缓冲区的脏数据写入到数据文件
ckpt进程同时负责更新数据文件的头部信息及控制文件上的检查点信息
2.检查点的触发条件
在日志切换的时候(自动切换或手动切换)
数据库用immediate ，transaction ，normal选项shutdown数据库的时候
用户手动触发(alter system checkpoint)
alter tablespace tablespace_name begin | end bakcup
alter tablespace tablespace_name offline
alter database datafile '<dir>' offline
alter tablespace | datafile read only
3.检测点队列
是一个脏数据库链表
检查点队列中的每一条修改过的记录包一个唯一的数据块标识符(日志文件号，块编号，偏移量)
最早队列将被优先写入到数据文件(而不论期间是否被多次修改)
最早队列被写入完成后将从队列中清除
4.检查点的分类
完全检查点
在Oracle 8i 以前，当检查点发生时，Oracle将脏缓冲列表上的数据全部写入到数据文件，称为完全检查点，又称常规检查点
特定的触发条件
alter system switch logfile
shutdown normal,immediate,transactional
alter system checkpoint
增量检查点(fast-start checkpoint)
主要是引入了检查点队列机制,每s，ckpt将检查点队列中最老的RBA更新到控制文件，RBA(重做日志块地址)同时将作为实例恢复的起点
增量检查点则细分了完全检查点，使得数据可以周期性按最老的数据块写入到数据文件
每一个脏块会被移到检查点队列里面去，按照LRBA（Low RBA第一次对此块修改对应的redo block address）来排列
最早写入检查点队列数据块的low rba值是最小的，即便该队列中的最小队列被修改多次，但修改后它在检查点队列里的顺序不会改变
当执行增量检查点时，DBWn从检查点队列按照LRBA的顺序来保证先修改的数据可以按顺序优先被写出来实现检查点的增进
此时ckpt进程使用轻量级的控制文件更新协议，将当前最低的RBA写入控制文件
ckpt在进行轻量级更新时，并不会改写控制文件中数据文件的检查点信息及数据文件头信息
仅仅是记录控制文件检查点SCN并根据增量检查点写出增进RBA信息
通过将完全检查点转变为增量检查点将大大缩短实例的恢复时间
注：更新数据文件头部及控制文件滞后于检查点事件的发生
增量检查点的触发
满足初始话文件log_checkpoint_interval、log_checkpoint_timeout、
fast_start_io_target、fast_start_mttr_target的设置的值
最小的日志文件的大小
Buffer Cacha中脏块的数量
部分检查点
表空间的脏数据写入到磁盘
由alter tablespace tablespace_name offline 触发
5.完全检查点与增量检查点的差异
完全检查点会将检查点的信息同时写入到控制文件及数据文件
增量检查点则只将RBA写入到控制文件
|
评论暂时关闭