一、当我们在进行DML,DDL命令的时候,均会产生两种不同类型的数据:
1)重做记录,目的是确保数据库具有可恢复性
2)被修改的数据块本身,目的是保证数据库的持久性。
oracle规定:保证重作记录先于对应的脏数据块写入永久层(也就是数据库文件)
那么,一个更改产生的重作记录和脏数据块,DBWn必须在LGWR将重做记录写入在线重做日志之后才可以把对应的脏数据块写入磁盘,这样就会导致数据文件永远比在线重做日志旧。
二、当我们以shutdown immediate / normal / transactional命令关闭数据库的时候,数据库会做三件事:
1)oracle会发起一个完全检查点,此时任何新的变更将不被允许
2)LGWR将日志缓冲区中现有的重作记录写入在线重做日志——>清空日志缓冲区——>停下LGWR——>在线日志停止更新
3)DBWn将相对应的脏数据库写入数据文件
这时候在线重做日志和数据文件达到了同步。
三、对正常关闭的数据库发出start 命令后,数据库要在open阶段会检查在线重做日志和数据文件是否同步,他们的同步是打开数据库的必要条件。
那么,在数据库突然断电的之后,再次打开数据库,数据库进行了什么操作呢?
SQL> shutdown abort
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 167772160 bytes
Fixed Size 1218316 bytes
Variable Size 71305460 bytes
Database Buffers 92274688 bytes
Redo Buffers 2973696 bytes
Database 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 2013
ALTER DATABASE MOUNT
Tue Sep 3 17:55:37 2013
Setting recovery target incarnation to 2
Tue Sep 3 17:55:37 2013
Successful mount of redo thread 1, with mount id 1352977301
Tue Sep 3 17:55:37 2013
Database mounted in Exclusive Mode
Completed: ALTER DATABASE MOUNT
Tue Sep 3 17:55:37 2013
ALTER DATABASE OPEN
Tue Sep 3 17:55:37 2013
Beginning crash recovery of 1 threads
Tue Sep 3 17:55:37 2013
Started redo scan
Tue Sep 3 17:55:37 2013
Completed redo scan
91 redo blocks read, 41 data blocks need recovery
Tue Sep 3 17:55:38 2013
Started redo application at
Thread 1: logseq 124, block 1372
Tue Sep 3 17:55:38 2013
Recovery of Online Redo Log: Thread 1 Group 3 Seq 124 Reading mem 0
Mem# 0 errs 0: /u01/app/oracle/oradata/orcl/redo03.log
Tue Sep 3 17:55:38 2013
Completed redo application
Tue Sep 3 17:55:38 2013
Completed crash recovery at
Thread 1: logseq 124, block 1463, scn 1714580
41 data blocks read, 41 data blocks written, 91 redo blocks read
Tue 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,将相对应的已经写入数据文件的块给修改掉,完成之后数据文件中不会存在由于上一次强制关闭而留下的,未提交的脏数据块。