当ORACLE突然断电,重新启动过程发生了哪些事?

来源:互联网 发布:淘宝客微信小程序效果 编辑:程序博客网 时间:2024/06/10 09:37

一、当我们在进行DML,DDL命令的时候,均会产生两种不同类型的数据:

1)重做记录,目的是确保数据库具有可恢复性

2)被修改的数据块本身,目的是保证数据库的持久性。

oracle规定:保证重作记录先于对应的脏数据块写入永久层(也就是数据库文件)

那么,一个更改产生的重作记录和脏数据块,DBWn必须在LGWR将重做记录写入在线重做日志之后才可以把对应的脏数据块写入磁盘,这样就会导致数据文件永远比在线重做日志旧。

二、当我们以shutdown  immediate / normal / transactional命令关闭数据库的时候,数据库会做三件事:

1)oracle会发起一个完全检查点,此时任何新的变更将不被允许

2)LGWR将日志缓冲区中现有的重作记录写入在线重做日志——>清空日志缓冲区——>停下LGWR——>在线日志停止更新

3)DBWn将相对应的脏数据库写入数据文件

这时候在线重做日志和数据文件达到了同步。

三、对正常关闭的数据库发出start 命令后,数据库要在open阶段会检查在线重做日志和数据文件是否同步,他们的同步是打开数据库的必要条件。

那么,在数据库突然断电的之后,再次打开数据库,数据库进行了什么操作呢?

SQL> shutdown abortORACLE instance shut down.SQL> startupORACLE instance started.Total System Global Area  167772160 bytesFixed Size    1218316 bytesVariable Size   71305460 bytesDatabase Buffers   92274688 bytesRedo Buffers    2973696 bytesDatabase mounted.Database opened.
打开警告文件进行分析

[root@RedHat ~]# more /u01/app/oracle/admin/orcl/bdump/alert_orcl.log 
...........................................

starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...starting up 1 shared server(s) ...Tue Sep  3 17:55:33 2013ALTER DATABASE   MOUNTTue Sep  3 17:55:37 2013Setting recovery target incarnation to 2Tue Sep  3 17:55:37 2013Successful mount of redo thread 1, with mount id 1352977301Tue Sep  3 17:55:37 2013Database mounted in Exclusive ModeCompleted: ALTER DATABASE   MOUNTTue Sep  3 17:55:37 2013ALTER DATABASE OPENTue Sep  3 17:55:37 2013Beginning crash recovery of 1 threadsTue Sep  3 17:55:37 2013Started redo scanTue Sep  3 17:55:37 2013Completed redo scan 91 redo blocks read, 41 data blocks need recoveryTue Sep  3 17:55:38 2013Started redo application at Thread 1: logseq 124, block 1372Tue Sep  3 17:55:38 2013Recovery of Online Redo Log: Thread 1 Group 3 Seq 124 Reading mem 0  Mem# 0 errs 0: /u01/app/oracle/oradata/orcl/redo03.logTue Sep  3 17:55:38 2013Completed redo applicationTue Sep  3 17:55:38 2013Completed crash recovery at Thread 1: logseq 124, block 1463, scn 1714580 41 data blocks read, 41 data blocks written, 91 redo blocks readTue Sep  3 17:55:38 2013
-----本行书写错误,不用看----Beginning crash recovery of 1 threads
可以看到,ORACLE在open阶段,会自动恢复因为突然断电造成的崩溃:

Beginning crash recovery of 1 threads
检查REDO日志,发现有41个数据块需要恢复,然后开始恢复第3号日志组中124号日志的第1372块,

Completed crash recovery at Thread 1: logseq 124, block 1463, scn 1714580 41 data blocks read, 41 data blocks written, 91 redo blocks read
共恢复了41个数据块,读了91个重做日志块。

从这个警告日志中可以看出:

当断电后启动数据库的时候,为了是数据库能够打开,ORACLE自动的进行实例操作同步数据库文件。

实例恢复(INSTANCE RECOVERY):在启动数据库的时候发现文件不同步后,自动利用在线日志中的重作记录自动对陈旧的数据文件进行恢复的过程。

总结:在数据库强制关闭之后再开启,会做一下步骤

1.管理员发出startup命令

2.打开参数文件,启动实例

3.打开控制文件

4.检查在线重做日志和数据文件是否同步,结果为不同步

5.对已经提交事务实施前滚,对没有写如数据文件的脏块写进数据文件。

6.打开数据库,可以接受客户请求

7.对没有提交的事务实施回滚,将相当于sql命令中的rollback,将相对应的已经写入数据文件的块给修改掉,完成之后数据文件中不会存在由于上一次强制关闭而留下的,未提交的脏数据块。


原创粉丝点击