昨天，一个朋友公司的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
copyright (c) 1982, 2005, oracle. all rights reserved.
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等手段，首先恢复出来数据文件，然后尝试启动数据库