超级复杂艰难之Oracle数据库大恢复-备份恢复[Oracle防范]

赞助商链接

分享到： QQ空间新浪微博腾讯微博人人网

　　本文“超级复杂艰难之Oracle数据库大恢复-备份恢复[Oracle防范]”是由七道奇为您精心收集，来源于网络转载，文章版权归文章作者所有，本站不对其观点以及内容做任何评价，请读者自行判断，以下是其具体内容：

昨天,一个朋友公司的数据库崩溃.

这再次印证了我反复提到的一个命题:数据库也需求歇息.

每逢节假日,数据库也常常会自我挑选放假.

从前我说:年末难终进入数据库事故多发期,一年一度今又是,记得别的一个圣诞节,我还和Biti一同在北京的时刻,一样碰到一个上海的朋友数据库崩溃,我们远程指导这位朋友恢复了数据.

这次的事情是这样的.

1.首先主机宕机,磁盘出错

看到以下这类错误,普通你的数据都很危险了

Dec 24 13:52:13 kernel: sda5: rw=0, want=18298437640, limit=163846872
Dec 24 13:52:13 kernel: attempt to access beyond end of device
Dec 24 13:52:13 kernel: sda5: rw=0, want=10384710304, limit=163846872
Dec 24 13:52:13 kernel: attempt to access beyond end of device
Dec 24 13:52:13 kernel: sda5: rw=0, want=8756273744, limit=163846872
Dec 24 13:52:13 kernel: attempt to access beyond end of device
Dec 24 13:52:13 kernel: sda5: rw=0, want=5023902272, limit=163846872
Dec 24 13:52:13 kernel: attempt to access beyond end of device
Dec 24 13:52:13 kernel: sda5: rw=0, want=6730428824, limit=163846872
Dec 24 13:52:13 kernel: attempt to access beyond end of device
Dec 24 13:52:13 kernel: sda5: rw=0, want=8884660792, limit=163846872
Dec 24 13:52:13 kernel: attempt to access beyond end of device
Dec 24 13:52:13 kernel: sda5: rw=0, want=9182513808, limit=163846872
Dec 24 13:52:13 kernel: attempt to access beyond end of device
Dec 24 13:52:13 kernel: sda5: rw=0, want=5002858800, limit=163846872
Dec 24 13:52:13 kernel: attempt to access beyond end of device
Dec 24 13:52:13 kernel: sda5: rw=0, want=6730428824, limit=163846872
Dec 24 13:52:13 kernel: attempt to access beyond end of device
Dec 24 13:52:13 kernel: sda5: rw=0, want=15872410168, limit=163846872

2.数据文件大量破坏

当然这次也不例外,大量文件破坏,dbv大量以下错误:

[oracle@stat datafile]$ dbv file=o1_mf_system_29448mn7_.dbf blocksize=8192

DBVERIFY: Release 10.2.0.2.0 - Production on Thu Dec 25 22:17:52 2008

DBVERIFY - Verification starting : FILE = o1_mf_system_29448mn7_.dbf
Page 40 is influx - most likely media corrupt
Corrupt block relative dba: 0x00400028 (file 1, block 40)
Fractured block found during dbv:
Data in bad block:
type: 6 format: 2 rdba: 0x00400028
last change scn: 0x0000.18990f0e seq: 0x1 flg: 0x06
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0xbc120601
check value in block header: 0xc0cb
computed block checksum: 0xb003

Page 232 is influx - most likely media corrupt
Corrupt block relative dba: 0x004000e8 (file 1, block 232)
Fractured block found during dbv:
Data in bad block:
type: 6 format: 2 rdba: 0x004000e8
last change scn: 0x0000.18991b98 seq: 0x1 flg: 0x06
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x6c440601
check value in block header: 0x8d7f
computed block checksum: 0x77dc

3.掌握文件破坏

启动数据库呈现以下错误:

Wed Dec 24 17:08:52 2008
ALTER DATABASE MOUNT
Wed Dec 24 17:08:56 2008
Errors in file /opt/oracle/admin/stat/udump/stat_ora_4630.trc:
ORA-00600: internal error code, arguments: [kccpb_sanity_check_2], [11258908], [10375171], [0x0], [], [], [], []
Wed Dec 24 17:08:57 2008
ORA-600 signalled during: ALTER DATABASE MOUNT...
Wed Dec 24 17:09:01 2008
Starting ORACLE instance (normal)
Wed Dec 24 17:16:22 2008
Corrupt block 1 found during reading backup piece, file=/opt/oracle/product/db10g/dbs/snapcf_stat.f, corr_type=2

4.经太反复确认,这个环境Over了

5.不完好的备份

从前的备份机制使得我可以从远程主机找到一系列备份集,但是没有掌握文件.

通过备份集、dbms_backup_restore等手段,首先恢复出来数据文件,然后尝试启动数据库

　　以上是“超级复杂艰难之Oracle数据库大恢复-备份恢复[Oracle防范]”的内容，如果你对以上该文章内容感兴趣，你可以看看七道奇为您推荐以下文章：

超级复杂艰难之Oracle数据库大恢复-备份恢复

本文地址：

与您的QQ/BBS好友分享!

[] [返回上一页] [打印]