突然断电对oracle的影响吗,当ORACLE突然断电,重新启动过程发生了哪些事?

一、当我们在进行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,将相对应的已经写入数据文件的块给修改掉,完成之后数据文件中不会存在由于上一次强制关闭而留下的,未提交的脏数据块。

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值