ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 042-177

042-177

原创 Linux操作系统 作者:jbymy2000 时间:2012-03-15 19:58:41 0 删除 编辑
177. The abnormal termination of the database background process causes the database instance to shut down without synchronizing the database files. The steps that will be performed at the next instance startup in random order are as follows: 1) Perform. recovery manually 2) SMON applies redo to the database
3) The database opens 4) Uncommitted transactions are rolled back by SMON 5) SMON reads the archived redo log files and online redo log files. Arrange the steps required for instance recovery in the correct order
A.2, 3, and 4 (1 and 5 not required)
B.2, 4, and 3 (1 and 5 not required)
C.5, 3, and 4 (1 and 2 not required)
D.2, 3, and 1 (4 and 5 not required)
答案:A
实例恢复: 启动的时候,从某个点把日志文件里内容完全写到数据文件,打开,把没有提交的rollback
提交仅仅写日志文件,不写数据文件,整个log buffer都写出去(里面有提交和没提交的,包含别人session的,尽管已经写到磁盘了,但别个session自己看不到,必须自己提交) 用以提高效率
写日志优先写数据文件 ,先到log buffer 再到data buffer,内存是重复使用的
对于介质恢复和实例恢复来说,第一个步骤都是通过REDO LOG的信息进行前滚,在做前滚的时候,通过REDO LOG文件里记录的数据库变化矢量,根据SCN的比对,提交到相关的数据文件上,从而使数据文件的状态向前滚动。大家要注意的是,UNDO表空间的变化也被记录到REDO LOG里了,因此UNDO表空间相关的数据文件也会被前滚。当前滚到最后一个可用的REDO LOG或者归档日志的时候,所有的数据库恢复层面的工作就全部完成了。这个时候,数据库包含了所有的被记录的变化,这些变化中有些是已经提交,有些是尚未提交的。在最新状态的UNDO表空间中,我们也可以看到一些尚未提交的事务。
因此数据库下一步需要做的事情是事务层面的处理,回滚那些尚未提交的事务,以确保数据库的一致性。
首先是在实例故障时,可能某些事物对数据文件的修改并没有完全写入磁盘,可能磁盘文件中丢失了某些已经提交事务对数据文件的修改信息。其次是可能某些还没有提交的事务对数据文件的修改已经被写入磁盘文件了。也有可能某个原子变更的部分数据已经被写入文件,而部分数据还没有被写入磁盘文件。实例恢复就是要通过ONLINE REDO LOG文件中记录的信息,自动的完成上述数据的修复工作。这个过程是完全自动的,不需要人工干预。
在这个机制里,有两个问题需要解决,第一个是如何确保已经提交的事务不会丢失,第二个是如何在数据库性能和实例恢复所需要的时间上做出平衡,既确保数据库性能不会下降,又保证实例恢复的快速。
解决第一个问题比较简单,Oracle有一个机制,叫做Log-Force-at-Commit,就是说,在事务提交的时候,和这个事务相关的REDO LOG数据,包括COMMIT记录,都必须从LOG BUFFER中写入REDO LOG文件,此时事务提交成功的信号才能发送给用户进程。通过这个机制,可以确保哪怕这个已经提交的事务中的部分BUFFER CACHE还没有被写入数据文件,就发生了实例故障,在做实例恢复的时候,也可以通过REDO LOG的信息,将不一致的数据前滚。
解决第二个问题,oracle是通过checkpoint机制来实现的。Oracle数据库中,对BUFFER CAHCE的修改操作是前台进程完成的,但是前台进程只负责将数据块从数据文件中读到BUFFER CACHE中,不负责BUFFER CACHE写入数据文件。BUFFER CACHE写入数据文件的操作是由后台进程DBWR来完成的。DBWR可以根据系统的负载情况以及数据块是否被其他进程使用来将一部分数据块回写到数据文件中。这种机制下,某个数据块被写回文件的时间可能具有一定的随机性的,有些先修改的数据块可能比较晚才被写入数据文件。而CHECKPOINT机制就是对这个机制的一个有效的补充,CHECKPOINT发生的时候,CKPT进程会要求DBWR进程将某个SCN以前的所有被修改的块都被写回数据文件。这样一旦这次CHECKPOINT完成后,这个SCN前的所有数据变更都已经存盘,如果之后发生了实例故障,那么做实例恢复的时候,只需要冲这次CHECKPOINT已经完成后的变化量开始就行了,CHECKPOINT之前的变化就不需要再去考虑了。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/11312660/viewspace-718691/,如需转载,请注明出处,否则将追究法律责任。

上一篇: 042-176
下一篇: 042-178
请登录后发表评论 登录
全部评论

注册时间:2012-01-10

  • 博文量
    416
  • 访问量
    214079