当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,将相对应的已经写入数据文件的块给修改掉,完成之后数据文件中不会存在由于上一次强制关闭而留下的,未提交的脏数据块。
- 当ORACLE突然断电,重新启动过程发生了哪些事?
- HTTP请求过程中发生了哪些事?
- 当学习前端过程中心态发生了变化
- oracle 查询创建了哪些存储过程
- oracle查看创建了哪些存储过程
- 使用clearcase时,突然断电了,该怎么办?
- 因突然断电造成Oracle破坏的数据恢复方法
- Oracle数据库突然断电ORA-600错误,数据恢复
- 从插上网线到web页面请求,究竟发生了哪些过程?(计算机网络篇)
- 当用户输入一个url地址后,到看到页面的过程,期间发生了什么?
- 当浏览器访问一个链接时计算机都做了哪些事
- MySQL突然断电异常解决
- 服务器突然断电造成oracle实例不能正常启动报ora-01172 ora-01151的解决办法
- centos6.5 断电重新启动后的unexpected
- 一次oracle数据库断电受损后的恢复过程
- 一次oracle数据库断电受损后的恢复过程
- Oracle存储过程突然失效Invalid
- Oracle启动过程突然连接失败
- Exception in thread "http-apr-8080-exec-6" java.lang.OutOfMemoryError: PermGen space 解决!
- hdu3240 Counting Binary Trees 卡特兰数 乘法逆元
- premake 使用clang替换gcc
- 正则表达式语法详解
- 父亲是一本书
- 当ORACLE突然断电,重新启动过程发生了哪些事?
- postfix 源码编译安装及报错处理(基于系统用户)
- boost库 bind/function的使用 [大三四八九月实习]
- poj 2533做题笔记
- 海外省电应用市场:本土化为先锋,高技术为基础
- 常见的笔试面试题(概念性的:死锁,进程通信方式,指向字符变量的指针,文件索引结构,可被重载的运算符)
- C++中设计一个类,使其不能被继承
- 顶级图像去雾源码整理及仿真结果
- highcharts图表内的tooltip提示框在IE浏览器下出现花屏的问题分析以及解决办法