损坏的主文件表_关键数据文件损坏恢复实验记录

最新推荐文章于 2024-07-10 14:04:37 发布

weixin_39574555

最新推荐文章于 2024-07-10 14:04:37 发布

阅读量703

点赞数

文章标签：损坏的主文件表

本文链接：https://blog.csdn.net/weixin_39574555/article/details/111391006

版权

关键数据文件损坏恢复实验记录

标题中"关键数据文件"来自Todd Bao的《临危不惧：Oracle 11g数据库恢复技术》一书。

关键数据文件包括两类:SYSTEM表空间的数据文件与参数undo_tablespace指向的自动撤销表空间的数据文件。

它们在整体或局部上的损失会导致SQL命令执行失败、用户会话强制断开、SYS用户无法登陆，甚至是整个实例崩溃等。

从动态视图里查看关键数据文件

sys@MAA> col FILE_NAME for a65

sys@MAA> select file_id, file_name from dba_data_files where tablespace_name in ('SYSTEM',(select value from v$parameter where name='undo_tablespace'));

FILE_ID FILE_NAME

---------- -----------------------------------------------------------------

3 +MSDATA/maa/datafile/undotbs1.262.792009883

1 +MSDATA/maa/datafile/system.260.792009857

本内容我们研究关键数据文件物理损坏情况下的恢复，前提条件是我们有备份文件。

注意：在没有备份的情况下关键数据文件损坏是无法恢复的。

实验环境：

• OS : Oracle Enterprise Linux 5.5 64Bit

• DB Type : Oracle Restart

• DB Version : 11.2.0.3

实验场景描述：系统运行中关键数据文件损坏

首先我来构造实验环境，因为我的环境里数据文件都存放于ASM磁盘组里，不方便模拟损坏(物理损坏)，所以先切换到FileSystem上。

sys@MAA> select name from v$datafile where file# = 1;

NAME

----------------------------------------------------------------------------------------------------

+MSDATA/maa/datafile/system.260.792009857

备份system表空间对应的数据文件

RMAN> backup as copy datafile 1;

Starting backup at 19-DEC-2012 16:18:27

using channel ORA_DISK_1

channel ORA_DISK_1: starting datafile copy

input datafile file number=00001 name=+MSDATA/maa/datafile/system.260.792009857

output file name=/u01/recovery/MAA/datafile/o1_mf_system_8f2y2mtk_.dbf tag=TAG20121219T161827 RECID=29 STAMP=802455529

channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:25

channel ORA_DISK_1: starting datafile copy

copying current control file

output file name=/u01/recovery/MAA/controlfile/o1_mf_TAG20121219T161827_8f2y3f1g_.ctl tag=TAG20121219T161827 RECID=30 STAMP=802455535

channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:03

channel ORA_DISK_1: starting full datafile backup set

channel ORA_DISK_1: specifying datafile(s) in backup set

including current SPFILE in backup set

channel ORA_DISK_1: starting piece 1 at 19-DEC-2012 16:18:56

channel ORA_DISK_1: finished piece 1 at 19-DEC-2012 16:18:57

piece handle=/u01/recovery/MAA/backupset/2012_12_19/o1_mf_nnsnf_TAG20121219T161827_8f2y3j6m_.bkp tag=TAG20121219T161827 comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01

Finished backup at 19-DEC-2012 16:18:57

重启到MOUNT状态

sys@MAA> startup force mount

ORACLE instance started.

Total System Global Area 1252663296 bytes

Fixed Size 2227944 bytes

Variable Size 771752216 bytes

Database Buffers 469762048 bytes

Redo Buffers 8921088 bytes

Database mounted.

通过RMAN SWITCH

RMAN> switch datafile 1 to copy;

datafile 1 switched to datafile copy "/u01/recovery/MAA/datafile/o1_mf_system_8f2y2mtk_.dbf"

sys@MAA> alter database open;

Database altered.

sys@MAA> select name from v$datafile where file#=1;

NAME

----------------------------------------------------------------------------------------------------

/u01/recovery/MAA/datafile/o1_mf_system_8f2y2mtk_.dbf

OK，我们的实验条件是有有效备份的

RMAN> backup database;

Starting backup at 19-DEC-2012 16:35:37

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=22 device type=DISK

channel ORA_DISK_1: starting full datafile backup set

channel ORA_DISK_1: specifying datafile(s) in backup set

input datafile file number=00001 name=/u01/recovery/MAA/datafile/o1_mf_system_8f2y2mtk_.dbf

input datafile file number=00002 name=+MSDATA/maa/datafile/sysaux.261.792009871

input datafile file number=00004 name=+MSDATA/maa/datafile/users.264.792009897

input datafile file number=00005 name=+MSDATA/maa/datafile/l.266.798569345

input datafile file number=00006 name=+MSDATA/maa/datafile/l.267.798570165

input datafile file number=00007 name=+MSDATA/maa/datafile/l.268.798572257

channel ORA_DISK_1: starting piece 1 at 19-DEC-2012 16:35:38

channel ORA_DISK_1: finished piece 1 at 19-DEC-2012 16:36:04

piece handle=/u01/recovery/MAA/backupset/2012_12_19/o1_mf_nnndf_TAG20121219T163538_8f2z2tt4_.bkp tag=TAG20121219T163538 comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:26

channel ORA_DISK_1: starting full datafile backup set

channel ORA_DISK_1: specifying datafile(s) in backup set

input datafile file number=00003 name=+MSDATA/maa/datafile/undotbs1.262.792009883

channel ORA_DISK_1: starting piece 1 at 19-DEC-2012 16:36:04

channel ORA_DISK_1: finished piece 1 at 19-DEC-2012 16:36:07

piece handle=/u01/recovery/MAA/backupset/2012_12_19/o1_mf_nnndf_TAG20121219T163538_8f2z3no7_.bkp tag=TAG20121219T163538 comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:03

channel ORA_DISK_1: starting full datafile backup set

channel ORA_DISK_1: specifying datafile(s) in backup set

including current control file in backup set

including current SPFILE in backup set

channel ORA_DISK_1: starting piece 1 at 19-DEC-2012 16:36:08

channel ORA_DISK_1: finished piece 1 at 19-DEC-2012 16:36:09

piece handle=/u01/recovery/MAA/backupset/2012_12_19/o1_mf_ncsnf_TAG20121219T163538_8f2z3roq_.bkp tag=TAG20121219T163538 comment=NONE

channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01

Finished backup at 19-DEC-2012 16:36:09

环境准备完毕，我们就手动破坏数据文件

[oracle@maa3 ~]$ dd if=/dev/urandom of=/u01/recovery/MAA/datafile/o1_mf_system_8f2y2mtk_.dbf bs=1M count=1

1+0 records in

1+0 records out

1048576 bytes (1.0 MB) copied, 0.157241 seconds, 6.7 MB/s

当我们查找数据字典的时候，发现ORA报错

sys@MAA> select count(*) from dba_objects;

select count(*) from dba_objects

ERROR at line 1:

ORA-00604: error occurred at recursive SQL level 1

ORA-01115: IO error reading block from file (block # )

ORA-01110: data file 1: '/u01/recovery/MAA/datafile/o1_mf_system_8f2y2mtk_.dbf'

ORA-27072: File I/O error

Additional information: 4

Additional information: 11185

但实例还是打开状态

sys@MAA> select status from v$instance;

STATUS

------------------------

OPEN

当联机日志切换、触发检查点的时候实例将会terminated

sys@MAA> alter system switch logfile;

System altered.

告警日志里将会输出：

Wed Dec 19 16:38:25 2012

Read of datafile '/u01/recovery/MAA/datafile/o1_mf_system_8f2y2mtk_.dbf' (fno 1) header failed with ORA-01210

Hex dump of (file 1, block 1) in trace file /u01/app/oracle/diag/rdbms/maa/maa/trace/maa_ckpt_11266.trc

Corrupt block relative dba: 0x00400001 (file 1, block 1)

Bad header found during datafile header read

Data in bad block:

type: 33 format: 1 rdba: 0xd3cf4a69

last change scn: 0xe969.3b01a1c9 seq: 0x40 flg: 0x33

spare1: 0xd4 spare2: 0x3 spare3: 0xc77f

consistency value in tail: 0x60637f3c

check value in block header: 0x13da

block checksum disabled

Rereading datafile 1 header failed with ORA-01210

Errors in file /u01/app/oracle/diag/rdbms/maa/maa/trace/maa_ckpt_11266.trc:

ORA-01243: system tablespace file suffered media failure

ORA-01122: database file 1 failed verification check

ORA-01110: data file 1: '/u01/recovery/MAA/datafile/o1_mf_system_8f2y2mtk_.dbf'

ORA-01210: data file header is media corrupt

Errors in file /u01/app/oracle/diag/rdbms/maa/maa/trace/maa_ckpt_11266.trc:

ORA-01243: system tablespace file suffered media failure

ORA-01122: database file 1 failed verification check

ORA-01110: data file 1: '/u01/recovery/MAA/datafile/o1_mf_system_8f2y2mtk_.dbf'

ORA-01210: data file header is media corrupt

Wed Dec 19 16:38:26 2012

System state dump requested by (instance=1, osid=11266 (CKPT)), summary=[abnormal instance termination].

System State dumped to trace file /u01/app/oracle/diag/rdbms/maa/maa/trace/maa_diag_11254.trc

CKPT (ospid: 11266): terminating the instance due to error 1243

Wed Dec 19 16:38:27 2012

ORA-1092 : opitsk aborting process

Wed Dec 19 16:38:28 2012

License high water mark = 6

Dumping diagnostic data in directory=[cdmp_20121219163826], requested by (instance=1, osid=11266 (CKPT)), summary=[abnormal instance termination].

Instance terminated by CKPT, pid = 11266

USER (ospid: 11569): terminating the instance

Instance terminated by USER, pid = 11569

Wed Dec 19 16:38:30 2012

Starting ORACLE instance (normal)

LICENSE_MAX_SESSION = 0

LICENSE_SESSIONS_WARNING = 0

Picked latch-free SCN scheme 3

Using LOG_ARCHIVE_DEST_1 parameter default value as USE_DB_RECOVERY_FILE_DEST

Autotune of undo retention is turned on.

IMODE=BR

ILAT =51

LICENSE_MAX_USERS = 0

SYS auditing is disabled

Starting up:

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options.

ORACLE_HOME = /u01/app/oracle/product/11.2.0/dbhome_1

System name: Linux

Node name: maa3.luocs.com

Release: 2.6.18-194.el5

Version: #1 SMP Mon Mar 29 22:10:29 EDT 2010

Machine: x86_64

VM name: VMWare Version: 6

Using parameter settings in server-side pfile /u01/app/oracle/product/11.2.0/dbhome_1/dbs/initmaa.ora

System parameters with non-default values:

processes = 300

sessions = 472

spfile = "+MSDATA/maa/spfilemaa.ora"

memory_target = 1200M

control_files = "+MSDATA/maa/controlfile/current.256.792009855"

db_block_size = 8192

compatible = "11.2.0.0.0"

db_create_file_dest = "+MSDATA"

db_recovery_file_dest = "/u01/recovery"

db_recovery_file_dest_size= 5G

undo_tablespace = "UNDOTBS1"

remote_login_passwordfile= "EXCLUSIVE"

db_domain = ""

dispatchers = "(PROTOCOL=TCP) (SERVICE=maaXDB)"

audit_file_dest = "/u01/app/oracle/admin/maa/adump"

audit_trail = "DB"

db_name = "maa"

open_cursors = 300

diagnostic_dest = "/u01/app/oracle"

Wed Dec 19 16:38:30 2012

PMON started with pid=2, OS id=11608

Wed Dec 19 16:38:30 2012

PSP0 started with pid=3, OS id=11610

Wed Dec 19 16:38:30 2012

VKTM started with pid=4, OS id=11612 at elevated priority

VKTM running at (1)millisec precision with DBRM quantum (100)ms

Wed Dec 19 16:38:30 2012

GEN0 started with pid=5, OS id=11616

Wed Dec 19 16:38:30 2012

DIAG started with pid=6, OS id=11618

Wed Dec 19 16:38:30 2012

DBRM started with pid=7, OS id=11620

Wed Dec 19 16:38:30 2012

DIA0 started with pid=8, OS id=11622

Wed Dec 19 16:38:30 2012

MMAN started with pid=9, OS id=11624

Wed Dec 19 16:38:30 2012

DBW0 started with pid=10, OS id=11626

Wed Dec 19 16:38:30 2012

LGWR started with pid=11, OS id=11628

Wed Dec 19 16:38:30 2012

CKPT started with pid=12, OS id=11630

Wed Dec 19 16:38:30 2012

SMON started with pid=13, OS id=11632

Wed Dec 19 16:38:30 2012

RECO started with pid=14, OS id=11634

Wed Dec 19 16:38:30 2012

RBAL started with pid=15, OS id=11636

Wed Dec 19 16:38:30 2012

ASMB started with pid=16, OS id=11638

Wed Dec 19 16:38:30 2012

MMON started with pid=17, OS id=11640

NOTE: initiating MARK startup

starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...

Wed Dec 19 16:38:30 2012

MMNL started with pid=18, OS id=11644

Starting background process MARK

Wed Dec 19 16:38:30 2012

MARK started with pid=19, OS id=11646

NOTE: MARK has subscribed

starting up 1 shared server(s) ...

ORACLE_BASE not set in environment. It is recommended

that ORACLE_BASE be set in the environment

Reusing ORACLE_BASE from an earlier startup = /u01/app/oracle

Wed Dec 19 16:38:31 2012

ALTER SYSTEM SET local_listener='(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=127.0.0.1)(PORT=1521))))' SCOPE=MEMORY SID='maa';

ALTER DATABASE MOUNT /* db agent *//* {0:4:23} */

NOTE: Loaded library: /opt/oracle/extapi/64/asm/orcl/1/libasm.so

NOTE: Loaded library: System

SUCCESS: diskgroup MSDATA was mounted

NOTE: dependency between database maa and diskgroup resource ora.MSDATA.dg is established

Successful mount of redo thread 1, with mount id 681033671

Database mounted in Exclusive Mode

Lost write protection disabled

Completed: ALTER DATABASE MOUNT /* db agent *//* {0:4:23} */

ALTER DATABASE OPEN /* db agent *//* {0:4:23} */

Errors in file /u01/app/oracle/diag/rdbms/maa/maa/trace/maa_dbw0_11626.trc:

ORA-01157: cannot identify/lock data file 1 - see DBWR trace file

ORA-01110: data file 1: '/u01/recovery/MAA/datafile/o1_mf_system_8f2y2mtk_.dbf'

ORA-27048: skgfifi: file header information is invalid

Additional information: 26

Errors in file /u01/app/oracle/diag/rdbms/maa/maa/trace/maa_ora_11656.trc:

ORA-01157: cannot identify/lock data file 1 - see DBWR trace file

ORA-01110: data file 1: '/u01/recovery/MAA/datafile/o1_mf_system_8f2y2mtk_.dbf'

ORA-1157 signalled during: ALTER DATABASE OPEN /* db agent *//* {0:4:23} */...

Wed Dec 19 16:38:40 2012

Shutting down instance (abort)

License high water mark = 1

USER (ospid: 11740): terminating the instance

Instance terminated by USER, pid = 11740

Wed Dec 19 16:38:40 2012

Instance shutdown complete

-- 注意，我的实验平台为Oracle Restart，重启数据库的特性导致实例意外终止之后想尝试自动重启，但依然ORA报错告终。

然后我尝试手动startup

idle> startup

ORACLE instance started.

Total System Global Area 1252663296 bytes

Fixed Size 2227944 bytes

Variable Size 771752216 bytes

Database Buffers 469762048 bytes

Redo Buffers 8921088 bytes

Database mounted.

ORA-01157: cannot identify/lock data file 1 - see DBWR trace file

ORA-01110: data file 1: '/u01/recovery/MAA/datafile/o1_mf_system_8f2y2mtk_.dbf'

恢复这种场景我们需要从备份文件里还原

RMAN> run {

2> restore datafile 1;

3> recover database;

4> alter database open;

5> }

Starting restore at 19-DEC-2012 16:46:59

using target database control file instead of recovery catalog

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=25 device type=DISK

channel ORA_DISK_1: starting datafile backup set restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

channel ORA_DISK_1: restoring datafile 00001 to /u01/recovery/MAA/datafile/o1_mf_system_8f2y2mtk_.dbf

channel ORA_DISK_1: reading from backup piece /u01/recovery/MAA/backupset/2012_12_19/o1_mf_nnndf_TAG20121219T163538_8f2z2tt4_.bkp

channel ORA_DISK_1: piece handle=/u01/recovery/MAA/backupset/2012_12_19/o1_mf_nnndf_TAG20121219T163538_8f2z2tt4_.bkp tag=TAG20121219T163538

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:00:15

Finished restore at 19-DEC-2012 16:47:16

Starting recover at 19-DEC-2012 16:47:16

using channel ORA_DISK_1

starting media recovery

media recovery complete, elapsed time: 00:00:01

Finished recover at 19-DEC-2012 16:47:18

database opened

OK，我们成功将数据文件恢复回来。

我们再模拟下数据文件头文件的损坏的场景，我们通过bbed工具来实现

sys@MAA> col NAME for a65

sys@MAA> select file#, name from v$datafile where file#=1;

FILE# NAME

---------- -----------------------------------------------------------------

1 /u01/recovery/MAA/datafile/o1_mf_system_8f304t27_.dbf

创建一个list文件

[oracle@maa3 ~]$ cat bbed.par

1 /u01/recovery/MAA/datafile/o1_mf_system_8f304t27_.dbf

[oracle@maa3 lib]$ bbed listfile=/home/oracle/bbed.par blocksize=8192 mode=edit

Password:

BBED: Release 2.0.0.0.0 - Limited Production on Wed Dec 19 16:58:24 2012

************* !!! For Oracle Internal Use only !!! ***************

BBED> set file 1

FILE# 1

BBED> show

FILE# 1

BLOCK# 1

OFFSET 0

DBA 0x00400001 (4194305 1,1)

FILENAME /u01/recovery/MAA/datafile/o1_mf_system_8f304t27_.dbf

BIFILE bifile.bbd

LISTFILE /home/oracle/bbed.par

BLOCKSIZE 8192

MODE Edit

EDIT Unrecoverable

IBASE Dec

OBASE Dec

WIDTH 80

COUNT 512

LOGFILE log.bbd

SPOOL No

BBED> dump /v

File: /u01/recovery/MAA/datafile/o1_mf_system_8f304t27_.dbf (1)

Block: 1 Offsets: 0 to 511 Dba:0x00400001

-------------------------------------------------------

0ba20000 01004000 00000000 00000104 l ......@.........

cd1a0000 00000000 0000200b b90df827 l .......... ....'

4d414100 00000000 410d0000 005e0100 l MAA.....A....^..

00200000 01000300 00000000 00000000 l . ..............

00000000 00000000 00000000 00000000 l ................

08024000 0a000000 00000000 8d1c352f l ..@...........5/

791c352f 01000000 00000000 00000000 l y.5/............

00000000 00000000 00000420 6a000000 l ........... j...

9592d42f 69000000 00000000 00000000 l .../i...........

00000000 00000000 00000000 00000000 l ................

06005359 5354454d 00000000 00000000 l ..SYSTEM........

00000000 00000000 00000000 00000000 l ................

01000000 00000000 00000000 db90d42f l .............../

00000000 00000000 00000000 00000000 l ................

00000000 00000000 00000000 0a000a00 l ................

00000000 00000000 00000000 00000000 l ................

00000000 472d0a00 00000000 9692d42f l ....G-........./

01000000 3e000000 02000000 10000000 l ....>...........

<16 bytes per line>

BBED> m /c LUOCS

Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) Y

File: /u01/recovery/MAA/datafile/o1_mf_system_8f304t27_.dbf (1)

Block: 1 Offsets: 0 to 511 Dba:0x00400001

------------------------------------------------------------------------

4c554f43 53004000 00000000 00000104 cd1a0000 00000000 0000200b b90df827

4d414100 00000000 410d0000 005e0100 00200000 01000300 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

08024000 0a000000 00000000 8d1c352f 791c352f 01000000 00000000 00000000

00000000 00000000 00000420 6a000000 9592d42f 69000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 06005359 5354454d 00000000 00000000

00000000 00000000 00000000 00000000 01000000 00000000 00000000 db90d42f

00000000 00000000 00000000 00000000 00000000 00000000 00000000 0a000a00

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 472d0a00 00000000 9692d42f 01000000 3e000000 02000000 10000000

<32 bytes per line>

BBED> sum apply

Check value for File 1, Block 1:

current = 0xae97, required = 0xae97

BBED> dump /v

File: /u01/recovery/MAA/datafile/o1_mf_system_8f304t27_.dbf (1)

Block: 1 Offsets: 0 to 511 Dba:0x00400001

-------------------------------------------------------

4c554f43 53004000 00000000 00000104 l LUOCS.@.........

97ae0000 00000000 0000200b b90df827 l .......... ....'

4d414100 00000000 410d0000 005e0100 l MAA.....A....^..

00200000 01000300 00000000 00000000 l . ..............

00000000 00000000 00000000 00000000 l ................

08024000 0a000000 00000000 8d1c352f l ..@...........5/

791c352f 01000000 00000000 00000000 l y.5/............

00000000 00000000 00000420 6a000000 l ........... j...

9592d42f 69000000 00000000 00000000 l .../i...........

00000000 00000000 00000000 00000000 l ................

06005359 5354454d 00000000 00000000 l ..SYSTEM........

00000000 00000000 00000000 00000000 l ................

01000000 00000000 00000000 db90d42f l .............../

00000000 00000000 00000000 00000000 l ................

00000000 00000000 00000000 0a000a00 l ................

00000000 00000000 00000000 00000000 l ................

00000000 472d0a00 00000000 9692d42f l ....G-........./

01000000 3e000000 02000000 10000000 l ....>...........

<16 bytes per line>

bbed来损坏数据文件之后，我们查

sys@MAA> select count(*) from dba_objects;

COUNT(*)

----------

22674

但当触发检查点的时候实例会终止

sys@MAA> alter system checkpoint;

手动启动

idle> startup

ORACLE instance started.

Total System Global Area 1252663296 bytes

Fixed Size 2227944 bytes

Variable Size 771752216 bytes

Database Buffers 469762048 bytes

Redo Buffers 8921088 bytes

Database mounted.

ORA-01122: database file 1 failed verification check

ORA-01110: data file 1: '/u01/recovery/MAA/datafile/o1_mf_system_8f304t27_.dbf'

ORA-01210: data file header is media corrupt

-- ORA-01210提示数据文件头损坏

恢复方法和上面一样的。

RMAN> run{

2> shutdown abort;

3> startup mount;

4> restore datafile 1;

5> recover database;

6> alter database open;

7> }

using target database control file instead of recovery catalog

Oracle instance shut down

connected to target database (not started)

Oracle instance started

database mounted

Total System Global Area 1252663296 bytes

Fixed Size 2227944 bytes

Variable Size 771752216 bytes

Database Buffers 469762048 bytes

Redo Buffers 8921088 bytes

Starting restore at 19-DEC-2012 17:51:10

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=27 device type=DISK

channel ORA_DISK_1: starting datafile backup set restore

channel ORA_DISK_1: specifying datafile(s) to restore from backup set

channel ORA_DISK_1: restoring datafile 00001 to /u01/recovery/MAA/datafile/o1_mf_system_8f304t27_.dbf

channel ORA_DISK_1: reading from backup piece /u01/recovery/MAA/backupset/2012_12_19/o1_mf_nnndf_TAG20121219T163538_8f2z2tt4_.bkp

channel ORA_DISK_1: piece handle=/u01/recovery/MAA/backupset/2012_12_19/o1_mf_nnndf_TAG20121219T163538_8f2z2tt4_.bkp tag=TAG20121219T163538

channel ORA_DISK_1: restored backup piece 1

channel ORA_DISK_1: restore complete, elapsed time: 00:00:08

Finished restore at 19-DEC-2012 17:51:19

Starting recover at 19-DEC-2012 17:51:19

using channel ORA_DISK_1

starting media recovery

archived log for thread 1 with sequence 51 is already on disk as file /u01/recovery/MAA/archivelog/2012_12_19/o1_mf_1_51_8f2zrrmx_.arc

archived log for thread 1 with sequence 52 is already on disk as file /u01/recovery/MAA/archivelog/2012_12_19/o1_mf_1_52_8f2zrrnt_.arc

archived log for thread 1 with sequence 53 is already on disk as file /u01/recovery/MAA/archivelog/2012_12_19/o1_mf_1_53_8f309r7n_.arc

archived log for thread 1 with sequence 54 is already on disk as file /u01/recovery/MAA/archivelog/2012_12_19/o1_mf_1_54_8f32b33j_.arc

archived log for thread 1 with sequence 55 is already on disk as file /u01/recovery/MAA/archivelog/2012_12_19/o1_mf_1_55_8f32brdg_.arc

archived log for thread 1 with sequence 56 is already on disk as file /u01/recovery/MAA/archivelog/2012_12_19/o1_mf_1_56_8f32bs6p_.arc

archived log for thread 1 with sequence 57 is already on disk as file /u01/recovery/MAA/archivelog/2012_12_19/o1_mf_1_57_8f32bt02_.arc

archived log for thread 1 with sequence 58 is already on disk as file /u01/recovery/MAA/archivelog/2012_12_19/o1_mf_1_58_8f32bto4_.arc

archived log for thread 1 with sequence 59 is already on disk as file /u01/recovery/MAA/archivelog/2012_12_19/o1_mf_1_59_8f32bvfp_.arc

archived log for thread 1 with sequence 60 is already on disk as file /u01/recovery/MAA/archivelog/2012_12_19/o1_mf_1_60_8f32cq0w_.arc

archived log for thread 1 with sequence 61 is already on disk as file /u01/recovery/MAA/archivelog/2012_12_19/o1_mf_1_61_8f32rplr_.arc

archived log for thread 1 with sequence 62 is already on disk as file /u01/recovery/MAA/archivelog/2012_12_19/o1_mf_1_62_8f3320hd_.arc

archived log for thread 1 with sequence 63 is already on disk as file /u01/recovery/MAA/archivelog/2012_12_19/o1_mf_1_63_8f332293_.arc

archived log file name=/u01/recovery/MAA/archivelog/2012_12_19/o1_mf_1_51_8f2zrrmx_.arc thread=1 sequence=51

archived log file name=/u01/recovery/MAA/archivelog/2012_12_19/o1_mf_1_52_8f2zrrnt_.arc thread=1 sequence=52

archived log file name=/u01/recovery/MAA/archivelog/2012_12_19/o1_mf_1_53_8f309r7n_.arc thread=1 sequence=53

archived log file name=/u01/recovery/MAA/archivelog/2012_12_19/o1_mf_1_54_8f32b33j_.arc thread=1 sequence=54

archived log file name=/u01/recovery/MAA/archivelog/2012_12_19/o1_mf_1_55_8f32brdg_.arc thread=1 sequence=55

archived log file name=/u01/recovery/MAA/archivelog/2012_12_19/o1_mf_1_56_8f32bs6p_.arc thread=1 sequence=56

archived log file name=/u01/recovery/MAA/archivelog/2012_12_19/o1_mf_1_57_8f32bt02_.arc thread=1 sequence=57

archived log file name=/u01/recovery/MAA/archivelog/2012_12_19/o1_mf_1_58_8f32bto4_.arc thread=1 sequence=58

archived log file name=/u01/recovery/MAA/archivelog/2012_12_19/o1_mf_1_59_8f32bvfp_.arc thread=1 sequence=59

archived log file name=/u01/recovery/MAA/archivelog/2012_12_19/o1_mf_1_60_8f32cq0w_.arc thread=1 sequence=60

archived log file name=/u01/recovery/MAA/archivelog/2012_12_19/o1_mf_1_61_8f32rplr_.arc thread=1 sequence=61

media recovery complete, elapsed time: 00:00:01

Finished recover at 19-DEC-2012 17:51:22

database opened

我再介绍一下如何模拟SYS.SYSTEM撤销段头部损坏，依然使用bbed工具。

BBED> find /c MAA

File: /u01/recovery/MAA/datafile/o1_mf_system_8f304t27_.dbf (1)

Block: 1 Offsets: 32 to 543 Dba:0x00400001

------------------------------------------------------------------------

4d414100 00000000 e50c0000 005e0100 00200000 01000300 00000000 00000000

54414732 30313231 32313954 31363533 34350000 00000000 00000000 00000000

08024000 0a000000 00000000 8d1c352f 791c352f 01000000 00000000 00000000

00000000 00000000 00000420 5b000000 b788d42f 5a000000 00000000 00000000

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 00000000 00000000 00000000 06005359 5354454d 00000000 00000000

00000000 00000000 00000000 00000000 01000000 00000000 00000000 8184d42f

00000000 00000000 00000000 00000000 00000000 00000000 00000000 0a000a00

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

00000000 808b0900 00000000 b788d42f 01000000 36000000 02000000 10000000

02000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

<32 bytes per line>

BBED> dump /v

File: /u01/recovery/MAA/datafile/o1_mf_system_8f304t27_.dbf (1)

Block: 1 Offsets: 32 to 543 Dba:0x00400001

-------------------------------------------------------

4d414100 00000000 e50c0000 005e0100 l MAA..........^..

00200000 01000300 00000000 00000000 l . ..............

54414732 30313231 32313954 31363533 l TAG20121219T1653

34350000 00000000 00000000 00000000 l 45..............

08024000 0a000000 00000000 8d1c352f l ..@...........5/

791c352f 01000000 00000000 00000000 l y.5/............

00000000 00000000 00000420 5b000000 l ........... [...

b788d42f 5a000000 00000000 00000000 l .../Z...........

00000000 00000000 00000000 00000000 l ................

06005359 5354454d 00000000 00000000 l ..SYSTEM........

00000000 00000000 00000000 00000000 l ................

01000000 00000000 00000000 8184d42f l .............../

00000000 00000000 00000000 00000000 l ................

00000000 00000000 00000000 0a000a00 l ................

00000000 00000000 00000000 00000000 l ................

00000000 808b0900 00000000 b788d42f l .............../

01000000 36000000 02000000 10000000 l ....6...........

02000000 00000000 00000000 00000000 l ................

00000000 00000000 00000000 00000000 l ................

<16 bytes per line>

BBED> m /c LUOCS

Warning: contents of previous BIFILE will be lost. Proceed? (Y/N) Y

File: /u01/recovery/MAA/datafile/o1_mf_system_8f304t27_.dbf (1)

Block: 1 Offsets: 32 to 543 Dba:0x00400001

------------------------------------------------------------------------

4c554f43 53000000 e50c0000 005e0100 00200000 01000300 00000000 00000000