Oracle9i新特性研究系列之七

文章作者 100test 发表时间 2007:03:14 13:53:46
来源 100Test.Com百考试题网

了解哪些参数控制了数据库实例崩溃的修复时间，并且知道9i数据库如何做实例崩溃恢复是这篇文章的目的，主要参考9i new feather，加入自己的理解，可能理解得不好，请大家指正。另外基础性的东西往往有些枯燥大家自己根据兴趣选择吧！
　　　　　 概论
　　非正常当机时间对业务的影响非常大。oracle9i增加了很多减少当机时间的特性。
　　　　 ----快速recovery。
　　　　 ----减少任何故障对最终用户的影响。
　　
　　如何实现最小的i/o recovery
　　　 如果要减少非计划当机时间，恢复时间必须降到最低。而恢复过程中i/o操作的数量直接影响着数据库的恢复时间。控制崩溃恢复时间的两个基础是
　　　　　　--读出redo log变化信息的时间
　　　　　　--读，更改，写这些变化所影响的数据块的时间。
　　
　　　　 ..oracle9i介绍了一个双通道实例或者崩溃恢复来缩减恢复时间。
　　 这里介绍的双通道恢复不能用于介质恢复，这个特性只用于实例或者崩溃恢复。
　　
　　　　 如何最小化i/o恢复
　　　日志文件经常包含在发生错误时不是脏块的变化数据块。在oracle9i,日志里增加了显示哪些块已经被成功写到磁盘的信息，在进行恢复时这些块将不会被操作，因此总体恢复时间将被缩减。这个特性不需要dba进行任何操作和配置。
　　
　　想约束恢复一个崩溃所需要的时间，有两个时间因素必须控制好：
　　　1:读log file所需要的时间.这依赖于日志文件设备的数据传输速率,和恢复过程中需要读的日志数量.
　　　2:在崩溃时在buffer cache中的已经被修改的数据块的读写时间.这依赖于限制cache中被修改而不写入data file中的块的数量,使这个数量符合在你需要的恢复时间内能够读写的文件数量.
　　
　　　日志文件中很有可能记录了一部分在崩溃时buffer中的一些虽然已经被改变,但并不是脏块的纪录.这些数据块已经在崩溃前成功的写入磁盘了.在恢复过程中不需要再对他们进行读和检查操作，这将可以节省大量时间.
　　　新特性中,恢复时需要读log两次,第一次找到哪些块需要恢复,第二次恢复那些需要恢复的块.第一次的连续读非常快,相对于以前的方法,这些额外增加的时间是非常少的.
　　
　　　　　　　　 fast-start time-based recovery limit
　　　 在恢复的时候，oracle9i实例重演从checkpoint redo byte address (checkpoint RBA))开始的所有变化，checkpoint RBA是存放在controlfile里的，需要recovery时,checkpoint RBA决定了重做日志流内开始应用recovery的位置。
　　　 提前checkpoint RBA的位置能够减少recovery time.为了提前checkpoint RBA，buffer cache里的脏块必须被写到数据文件里。这个操作就是检查点操作。但是相应的过分频繁的检查点操作会影响数据库性能。所以我们必须考虑如何取得性能和恢复速度的平衡。
　　
　　　　　　　　 fast-start time-based recovery limit
　　 特点：可以设置很多的不同维护级别，包括恢复数据库的时间范围。
　　　　　 DBA必须能够可靠的设置一个用来恢复数据库的时间限制
　　　　　 oracle9i引入了基于时间点的快速恢复，这个属性允许dba指定一个多少秒内恢复数据库的目标。oracle9i实例自动计算来设定合适的内部参数，以达到指定的目标。现在设置秒级的恢复时间限制非常容易，以前这项工作非常困难而且准确性也很差！