标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 kfed MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-01110 ORA-01555 ORA-01578 ORA-08103 ORA-600 2131 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 Oracle 恢复 ORACLE恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (102)
- 数据库 (1,682)
- DB2 (22)
- MySQL (73)
- Oracle (1,544)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (159)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (7)
- Oracle ASM (67)
- Oracle Bug (8)
- Oracle RAC (53)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (565)
- Oracle安装升级 (92)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (79)
- PostgreSQL (18)
- PostgreSQL恢复 (6)
- SQL Server (27)
- SQL Server恢复 (8)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (37)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (20)
-
最近发表
- 断电引起的ORA-08102: 未找到索引关键字, 对象号 39故障处理
- ORA-00227: corrupt block detected in control file
- 手工删除19c rac
- 解决oracle数据文件路径有回车故障
- .wstop扩展名勒索数据库恢复
- Oracle Recovery Tools工具一键解决ORA-00376 ORA-01110故障(文件offline)
- OGG-02771 Input trail file format RELEASE 19.1 is different from previous trail file form at RELEASE 11.2.
- OGG-02246 Source redo compatibility level 19.0.0 requires trail FORMAT 12.2 or higher
- GoldenGate 19安装和打patch
- dd破坏asm磁盘头恢复
- 删除asmlib磁盘导致磁盘组故障恢复
- Kylin Linux 安装19c
- ORA-600 krse_arc_complete.4
- Oracle 19c 202410补丁(RUs+OJVM)
- ntfs MFT损坏(ntfs文件系统故障)导致oracle异常恢复
- .mkp扩展名oracle数据文件加密恢复
- 清空redo,导致ORA-27048: skgfifi: file header information is invalid
- A_H_README_TO_RECOVER勒索恢复
- 通过alert日志分析客户自行对一个数据库恢复的来龙去脉和点评
- ORA-12514: TNS: 监听进程不能解析在连接描述符中给出的SERVICE_NAME
标签归档:bbed
分析drop col对于数据存储块做了什么
oracle 的alter table drop col具体内部是对于数据存储块操作的,如果drop col之后dul之类的工具是否可以恢复,这里我通过具体测试,结合bbed,dump block等方法来说明该问题
1.创建测试表,并写入硬盘
SQL> create table xff.t_xifenfei as select object_id,owner,object_name from dba_objects; Table created. SQL> desc xff.t_xifenfei Name Null? Type ----------------------------------------- -------- ---------------------------- OBJECT_ID NUMBER OWNER VARCHAR2(30) OBJECT_NAME VARCHAR2(128) SQL> alter system checkpoint; System altered. SQL> alter system checkpoint; System altered.
2.找出来测试表一个block分析drop col对于存储的影响
SQL> select rowid, 2 dbms_rowid.rowid_relative_fno(rowid)rel_fno, 3 dbms_rowid.rowid_block_number(rowid)blockno, dbms_rowid.rowid_row_number(rowid) rowno,object_id 4 5 from xff.t_xifenfei where rownum<5; ROWID REL_FNO BLOCKNO ROWNO OBJECT_ID ------------------ ---------- ---------- ---------- ---------- AAAZ9wAAEAAAJojAAA 4 39459 0 20 AAAZ9wAAEAAAJojAAB 4 39459 1 46 AAAZ9wAAEAAAJojAAC 4 39459 2 28 AAAZ9wAAEAAAJojAAD 4 39459 3 15
3. dump block,并且记录该block 1,2,和最后一条记录
SQL> oradebug setmypid Statement processed. SQL> alter system dump datafile 4 block 39459; System altered. SQL> oradebug TRACEFILE_NAME /home/u01/diag/rdbms/orcl/orcl/trace/orcl_ora_14069.trc block_row_dump: tab 0, row 0, @0x1f70 tl: 16 fb: --H-FL-- lb: 0x0 cc: 3 col 0: [ 2] c1 15 col 1: [ 3] 53 59 53 col 2: [ 5] 49 43 4f 4c 24 tab 0, row 1, @0x1f5e tl: 18 fb: --H-FL-- lb: 0x0 cc: 3 col 0: [ 2] c1 2f col 1: [ 3] 53 59 53 col 2: [ 7] 49 5f 55 53 45 52 31 ………… tab 0, row 288, @0x589 tl: 22 fb: --H-FL-- lb: 0x0 cc: 3 col 0: [ 3] c2 03 5b col 1: [ 3] 53 59 53 col 2: [10] 49 5f 4a 4f 42 5f 4e 45 58 54
4. 使用bbed查看该block 1,2,和最后一条记录
[oracle@localhost ~]$ bbed password=blockedit blocksize=8192 filename=/usr/local/oradata/qsng/users01.dbf BBED: Release 2.0.0.0.0 - Limited Production on Sun Apr 3 22:25:28 2016 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. ************* !!! For Oracle Internal Use only !!! *************** BBED> set block 39459 BLOCK# 39459 BBED> map File: /usr/local/oradata/qsng/users01.dbf (0) Block: 39459 Dba:0x00000000 ------------------------------------------------------------ KTB Data Block (Table/Cluster) struct kcbh, 20 bytes @0 struct ktbbh, 96 bytes @20 struct kdbh, 14 bytes @124 struct kdbt[1], 4 bytes @138 sb2 kdbr[289] @142 ub1 freespace[821] @720 ub1 rowdata[6647] @1541 ub4 tailchk @8188 BBED> p *kdbr[0] rowdata[6631] ------------- ub1 rowdata[6631] @8172 0x2c BBED> x /rncc rowdata[6631] @8172 ------------- flag@8172: 0x2c (KDRHFL, KDRHFF, KDRHFH) lock@8173: 0x00 cols@8174: 3 col 0[2] @8175: 20 col 1[3] @8178: SYS col 2[5] @8182: ICOL$ BBED> d File: /usr/local/oradata/qsng/users01.dbf (0) Block: 39459 Offsets: 8172 to 8191 Dba:0x00000000 ------------------------------------------------------------------------ 2c000302 c1150353 59530549 434f4c24 02067576 <32 bytes per line> BBED> p *kdbr[1] rowdata[6613] ------------- ub1 rowdata[6613] @8154 0x2c BBED> x /rncc rowdata[6613] @8154 ------------- flag@8154: 0x2c (KDRHFL, KDRHFF, KDRHFH) lock@8155: 0x00 cols@8156: 3 col 0[2] @8157: 46 col 1[3] @8160: SYS col 2[7] @8164: I_USER1 BBED> d File: /usr/local/oradata/qsng/users01.dbf (0) Block: 39459 Offsets: 8154 to 8191 Dba:0x00000000 ------------------------------------------------------------------------ 2c000302 c12f0353 59530749 5f555345 52312c00 0302c115 03535953 0549434f 4c240206 7576 <32 bytes per line> BBED> p *kdbr[288] rowdata[0] ---------- ub1 rowdata[0] @1541 0x2c BBED> x /rncc rowdata[0] @1541 ---------- flag@1541: 0x2c (KDRHFL, KDRHFF, KDRHFH) lock@1542: 0x00 cols@1543: 3 col 0[3] @1544: 290 col 1[3] @1548: SYS col 2[10] @1552: I_JOB_NEXT BBED> set count 32 COUNT 32 BBED> d File: /usr/local/oradata/qsng/users01.dbf (0) Block: 39459 Offsets: 1541 to 1572 Dba:0x00000000 ------------------------------------------------------------------------ 2c000303 c2035b03 5359530a 495f4a4f 425f4e45 58542c00 0303c203 5a035359 <32 bytes per line>
5. 删除中间列,并且写入硬盘
SQL> ALTER TABLE XFF.T_XIFENFEI DROP COLUMN owner; Table altered. SQL> alter system checkpoint; System altered. SQL> / System altered.
6. 查询确定相同行所在block没有发生改变
SQL> select rowid, 2 dbms_rowid.rowid_relative_fno(rowid)rel_fno, 3 dbms_rowid.rowid_block_number(rowid)blockno, dbms_rowid.rowid_row_number(rowid) rowno,object_id 4 5 from xff.t_xifenfei where rownum<5; ROWID REL_FNO BLOCKNO ROWNO OBJECT_ID ------------------ ---------- ---------- ---------- ---------- AAAZ9wAAEAAAJojAAA 4 39459 0 20 AAAZ9wAAEAAAJojAAB 4 39459 1 46 AAAZ9wAAEAAAJojAAC 4 39459 2 28 AAAZ9wAAEAAAJojAAD 4 39459 3 15
7. drop col之后dump block继续分析
SQL> alter system dump datafile 4 block 39459; System altered. SQL> select value from v$diag_info where name='Default Trace File'; VALUE -------------------------------------------------------------------------------- /home/u01/diag/rdbms/orcl/orcl/trace/orcl_ora_14784.trc SQL> tab 0, row 0, @0x1f70 tl: 12 fb: --H-FL-- lb: 0x2 cc: 2 col 0: [ 2] c1 15 col 1: [ 5] 49 43 4f 4c 24 tab 0, row 1, @0x1f5e tl: 14 fb: --H-FL-- lb: 0x2 cc: 2 col 0: [ 2] c1 2f col 1: [ 7] 49 5f 55 53 45 52 31 ………… tab 0, row 288, @0x589 tl: 18 fb: --H-FL-- lb: 0x2 cc: 2 col 0: [ 3] c2 03 5b col 1: [10] 49 5f 4a 4f 42 5f 4e 45 58 54
8. 使用bbed查看drop col后的数据存储情况
$ bbed password=blockedit blocksize=8192 filename=/usr/local/oradata/qsng/users01.dbf BBED: Release 2.0.0.0.0 - Limited Production on Sun Apr 3 22:31:37 2016 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. ************* !!! For Oracle Internal Use only !!! *************** BBED> set block 39459 BLOCK# 39459 BBED> map File: /usr/local/oradata/qsng/users01.dbf (0) Block: 39459 Dba:0x00000000 ------------------------------------------------------------ KTB Data Block (Table/Cluster) struct kcbh, 20 bytes @0 struct ktbbh, 96 bytes @20 struct kdbh, 14 bytes @124 struct kdbt[1], 4 bytes @138 sb2 kdbr[289] @142 ub1 freespace[821] @720 ub1 rowdata[6647] @1541 ub4 tailchk @8188 BBED> p *kdbr[0] rowdata[6631] ------------- ub1 rowdata[6631] @8172 0x2c BBED> x /rncc rowdata[6631] @8172 ------------- flag@8172: 0x2c (KDRHFL, KDRHFF, KDRHFH) lock@8173: 0x02 cols@8174: 2 col 0[2] @8175: 20 col 1[5] @8178: ICOL$ BBED> d File: /usr/local/oradata/qsng/users01.dbf (0) Block: 39459 Offsets: 8172 to 8191 Dba:0x00000000 ------------------------------------------------------------------------ 2c020202 c1150549 434f4c24 434f4c24 0106de78 <32 bytes per line> BBED> p *kdbr[1] rowdata[6613] ------------- ub1 rowdata[6613] @8154 0x2c BBED> x /rncc rowdata[6613] @8154 ------------- flag@8154: 0x2c (KDRHFL, KDRHFF, KDRHFH) lock@8155: 0x02 cols@8156: 2 col 0[2] @8157: 46 col 1[7] @8160: I_USER1 BBED> d File: /usr/local/oradata/qsng/users01.dbf (0) Block: 39459 Offsets: 8154 to 8191 Dba:0x00000000 ------------------------------------------------------------------------ 2c020202 c12f0749 5f555345 52315345 52312c02 0202c115 0549434f 4c24434f 4c240106 de78 <32 bytes per line> BBED> p *kdbr[288] rowdata[0] ---------- ub1 rowdata[0] @1541 0x2c BBED> set count 32 COUNT 32 BBED> x /rncc rowdata[0] @1541 ---------- flag@1541: 0x2c (KDRHFL, KDRHFF, KDRHFH) lock@1542: 0x02 cols@1543: 2 col 0[3] @1544: 290 col 1[10] @1548: I_JOB_NEXT BBED> d File: /usr/local/oradata/qsng/users01.dbf (0) Block: 39459 Offsets: 1541 to 1572 Dba:0x00000000 ------------------------------------------------------------------------ 2c020203 c2035b0a 495f4a4f 425f4e45 58544e45 58542c02 0203c203 5a09495f <32 bytes per line>
通过上述测试可以得出如下结论:
1. drop col是真的把对应列存储在block中的内容除掉,而且把后面的列的内容前移了,并且以前多于的内容(因为一行内容前移,后面就出现空闲记录不设置为空,而就是最初内容,下次如果行长度发生改变的时候使用,就和类似update把列修改短了一样)
2. drop col只是导致一行的长度变短,但是每行的偏移量未发生改变,也就是说,每行所在的偏移量没有改变,drop col之后,每行后面多了一些空闲空间
3. 根据上面分析的原理,drop col 是真的从block内部把这一列的数据使用后面列的数据覆盖了,因此从原理上而言,dul无法恢复drop col的数据(最后一列有可能可以恢复,因为他不会被覆盖),对于drop col,只能是通过备份不完全恢复,全库闪回,dg延迟应用等方法解决
file 1 block 128 corrupted/坏块恢复—system rollback坏块修复
有个数据库file 1 block 128 坏块导致数据库无法启动报错如下
该数据库版本是11.2.0.1,根据我们的经验该block是system rollback 的segment header,以下为我在正常哭查询结果
SQL> select file_id,block_id,blocks from dba_extents where segment_name='SYSTEM'; FILE_ID BLOCK_ID BLOCKS ---------- ---------- ---------- 1 128 8 1 136 8 1 528 8 1 536 8 1 544 8 1 552 8 6 rows selected.
dump file 1 block 128 结果
Dump all the blocks in range: buffer tsn: 0 rdba: 0x00400080 (1/128) scn: 0x0000.00000000 seq: 0xff flg: 0x04 tail: 0x00000eff frmt: 0x02 chkval: 0x1387 type: 0x0e=KTU UNDO HEADER W/UNLIMITED EXTENTS Hex dump of block: st=0, typ_found=1
这里可以看到block scn为0×0000.00000000,而且数据块已经被标记为坏块
dbv检查坏块结果
从这里可以看出来主要错误是由于Controlscn: 0×0004.119fe191 greater than blockscn: 0×0000.00000000,拷贝system文件到本地,使用bbed修改
bbed修复坏块
H:\temp\SYSTEM01>bbed password=blockedit filename=system01.dbf blocksize=8192 BBED: Release 2.0.0.0.0 - Limited Production on Thu Mar 17 00:23:49 2016 Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. ************* !!! For Oracle Internal Use only !!! *************** BBED> show all FILE# 0 BLOCK# 1 OFFSET 0 DBA 0x00000000 (0 0,1) FILENAME system01.dbf BIFILE bifile.bbd LISTFILE BLOCKSIZE 8192 MODE Browse EDIT Unrecoverable IBASE Dec OBASE Dec WIDTH 80 COUNT 512 LOGFILE log.bbd SPOOL No BBED> set block 129 BLOCK# 129 BBED> map File: system01.dbf (0) Block: 129 Dba:0x00000000 ------------------------------------------------------------ Unlimited Undo Segment Header struct kcbh, 20 bytes @0 struct ktech, 72 bytes @20 struct ktemh, 16 bytes @92 struct ktetb[6], 48 bytes @108 struct ktuxc, 104 bytes @4148 struct ktuxe[204], 8160 bytes @4252 ub4 tailchk @8188 BBED> p kcbh struct kcbh, 20 bytes @0 ub1 type_kcbh @0 0x0e ub1 frmt_kcbh @1 0xa2 ub1 spare1_kcbh @2 0x00 ub1 spare2_kcbh @3 0x00 ub4 rdba_kcbh @4 0x00400080 ub4 bas_kcbh @8 0x00000000 ub2 wrp_kcbh @12 0x0000 ub1 seq_kcbh @14 0xff ub1 flg_kcbh @15 0x04 (KCBHFCKV) ub2 chkval_kcbh @16 0x1387 ub2 spare3_kcbh @18 0x0000 BBED> set mode edit MODE Edit BBED> d offset 8188 File: system01.dbf (0) Block: 129 Offsets: 8188 to 8191 Dba:0x00000000 ------------------------------------------------------------------------ ff0e0000 <32 bytes per line> BBED> m /x 01 offset 8188 File: system01.dbf (0) Block: 129 Offsets: 8188 to 8191 Dba:0x00000000 ------------------------------------------------------------------------ 010e0000 <32 bytes per line> BBED> verify DBVERIFY - Verification starting FILE = system01.dbf BLOCK = 128 DBVERIFY - Verification complete Total Blocks Examined : 1 Total Blocks Processed (Data) : 0 Total Blocks Failing (Data) : 0 Total Blocks Processed (Index): 0 Total Blocks Failing (Index): 0 Total Blocks Empty : 0 Total Blocks Marked Corrupt : 0 Total Blocks Influx : 0 BBED> sum apply Check value for File 0, Block 129: current = 0x1387, required = 0x1387 BBED> verify DBVERIFY - Verification starting FILE = system01.dbf BLOCK = 128 DBVERIFY - Verification complete Total Blocks Examined : 1 Total Blocks Processed (Data) : 0 Total Blocks Failing (Data) : 0 Total Blocks Processed (Index): 0 Total Blocks Failing (Index): 0 Total Blocks Empty : 0 Total Blocks Marked Corrupt : 0 Total Blocks Influx : 0 BBED> exit H:\temp\SYSTEM01>dbv file=SYSTEM01.DBF DBVERIFY: Release 12.1.0.2.0 - Production on 星期四 3月 17 00:26:26 2016 Copyright (c) 1982, 2014, Oracle and/or its affiliates. All rights reserved. DBVERIFY - 开始验证: FILE = H:\TEMP\SYSTEM01\SYSTEM01.DBF Controlscn: 0x0004.119fe191 greater than blockscn: 0x0000.00000000 页 128 失败, 校验代码为 14509 页 128 失败, 校验代码为 14509 DBVERIFY - 验证完成 检查的页总数: 209920 处理的页总数 (数据): 132380 失败的页总数 (数据): 0 处理的页总数 (索引): 57168 失败的页总数 (索引): 0 处理的页总数 (其他): 3112 处理的总页数 (段) : 1 失败的总页数 (段) : 1 空的页总数: 17260 标记为损坏的总页数: 1 流入的页总数: 0 加密的总页数 : 0 最高块 SCN : 188826853 (5.188826853) H:\temp\SYSTEM01>bbed password=blockedit filename=system01.dbf BBED: Release 2.0.0.0.0 - Limited Production on Thu Mar 17 00:26:59 2016 Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. ************* !!! For Oracle Internal Use only !!! *************** BBED> set blocksize 8192 BLOCKSIZE 8192 BBED> set block 129 BLOCK# 129 BBED> verify DBVERIFY - Verification starting FILE = system01.dbf BLOCK = 128 DBVERIFY - Verification complete Total Blocks Examined : 1 Total Blocks Processed (Data) : 0 Total Blocks Failing (Data) : 0 Total Blocks Processed (Index): 0 Total Blocks Failing (Index): 0 Total Blocks Empty : 0 Total Blocks Marked Corrupt : 0 Total Blocks Influx : 0 BBED> map File: system01.dbf (0) Block: 129 Dba:0x00000000 ------------------------------------------------------------ Unlimited Undo Segment Header struct kcbh, 20 bytes @0 struct ktech, 72 bytes @20 struct ktemh, 16 bytes @92 struct ktetb[6], 48 bytes @108 struct ktuxc, 104 bytes @4148 struct ktuxe[204], 8160 bytes @4252 ub4 tailchk @8188 BBED> p kcbh struct kcbh, 20 bytes @0 ub1 type_kcbh @0 0x0e ub1 frmt_kcbh @1 0xa2 ub1 spare1_kcbh @2 0x00 ub1 spare2_kcbh @3 0x00 ub4 rdba_kcbh @4 0x00400080 ub4 bas_kcbh @8 0x00000000 ub2 wrp_kcbh @12 0x0000 ub1 seq_kcbh @14 0x01 ub1 flg_kcbh @15 0x04 (KCBHFCKV) ub2 chkval_kcbh @16 0x1387 ub2 spare3_kcbh @18 0x0000 BBED> set mode edit MODE Edit BBED> m /x 0400 offset 12 File: system01.dbf (0) Block: 129 Offsets: 12 to 523 Dba:0x00000000 ------------------------------------------------------------------------ 04000104 87130000 00000000 00000000 00000000 00000000 06000000 2f000000 20100000 05000000 05000000 08000000 2d024000 00000000 05000000 00000000 00000000 00000000 00000000 00000000 06000000 00000000 00000000 00000040 81004000 07000000 88004000 08000000 10024000 08000000 18024000 08000000 20024000 08000000 28024000 08000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 <32 bytes per line> BBED> p kcbh struct kcbh, 20 bytes @0 ub1 type_kcbh @0 0x0e ub1 frmt_kcbh @1 0xa2 ub1 spare1_kcbh @2 0x00 ub1 spare2_kcbh @3 0x00 ub4 rdba_kcbh @4 0x00400080 ub4 bas_kcbh @8 0x00000000 ub2 wrp_kcbh @12 0x0004 ub1 seq_kcbh @14 0x01 ub1 flg_kcbh @15 0x04 (KCBHFCKV) ub2 chkval_kcbh @16 0x1387 ub2 spare3_kcbh @18 0x0000 BBED> m /x 625a60d0 offset 8 File: system01.dbf (0) Block: 129 Offsets: 8 to 519 Dba:0x00000000 ------------------------------------------------------------------------ 625a60d0 10000104 87130000 00000000 00000000 00000000 00000000 06000000 2f000000 20100000 05000000 05000000 08000000 2d024000 00000000 05000000 00000000 00000000 00000000 00000000 00000000 06000000 00000000 00000000 00000040 81004000 07000000 88004000 08000000 10024000 08000000 18024000 08000000 20024000 08000000 28024000 08000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 <32 bytes per line> BBED> p kcbh struct kcbh, 20 bytes @0 ub1 type_kcbh @0 0x0e ub1 frmt_kcbh @1 0xa2 ub1 spare1_kcbh @2 0x00 ub1 spare2_kcbh @3 0x00 ub4 rdba_kcbh @4 0x00400080 ub4 bas_kcbh @8 0xd0605a62 ub2 wrp_kcbh @12 0x0010 ub1 seq_kcbh @14 0x01 ub1 flg_kcbh @15 0x04 (KCBHFCKV) ub2 chkval_kcbh @16 0x1387 ub2 spare3_kcbh @18 0x0000 BBED> d offset 8188 File: system01.dbf (0) Block: 129 Offsets: 8188 to 8191 Dba:0x00000000 ------------------------------------------------------------------------ 010e0000 <32 bytes per line> BBED> m /x 010e625a File: system01.dbf (0) Block: 129 Offsets: 8188 to 8191 Dba:0x00000000 ------------------------------------------------------------------------ 010e625a <32 bytes per line> BBED> verify DBVERIFY - Verification starting FILE = system01.dbf BLOCK = 128 Block 128 is corrupt *** Corrupt block relative dba: 0x00400080 (file 0, block 128) Bad check value found during verification Data in bad block - type: 14 format: 2 rdba: 0x00400080 last change scn: 0x0010.34605a62 seq: 0x1 flg: 0x04 consistency value in tail: 0x5a620e01 check value in block header: 0x1387, computed block checksum: 0x3470 spare1: 0x0, spare2: 0x0, spare3: 0x0 *** DBVERIFY - Verification complete Total Blocks Examined : 1 Total Blocks Processed (Data) : 0 Total Blocks Failing (Data) : 0 Total Blocks Processed (Index): 0 Total Blocks Failing (Index): 0 Total Blocks Empty : 0 Total Blocks Marked Corrupt : 1 Total Blocks Influx : 0 BBED> sum apply Check value for File 0, Block 129: current = 0x27f7, required = 0x27f7 BBED> verify DBVERIFY - Verification starting FILE = system01.dbf BLOCK = 128 DBVERIFY - Verification complete Total Blocks Examined : 1 Total Blocks Processed (Data) : 0 Total Blocks Failing (Data) : 0 Total Blocks Processed (Index): 0 Total Blocks Failing (Index): 0 Total Blocks Empty : 0 Total Blocks Marked Corrupt : 0 Total Blocks Influx : 0 BBED> exit H:\temp\SYSTEM01>dbv file=SYSTEM01.DBF DBVERIFY: Release 12.1.0.2.0 - Production on 星期四 3月 17 00:40:38 2016 Copyright (c) 1982, 2014, Oracle and/or its affiliates. All rights reserved. DBVERIFY - 开始验证: FILE = H:\TEMP\SYSTEM01\SYSTEM01.DBF DBVERIFY - 验证完成 检查的页总数: 209920 处理的页总数 (数据): 132380 失败的页总数 (数据): 0 处理的页总数 (索引): 57168 失败的页总数 (索引): 0 处理的页总数 (其他): 3112 处理的总页数 (段) : 1 失败的总页数 (段) : 0 空的页总数: 17260 标记为损坏的总页数: 0 流入的页总数: 0 加密的总页数 : 0 最高块 SCN : 188826853 (5.188826853)
这里发现当我们bbed验证非坏块之时,使用dbv检测依旧报坏块,可以看出来dbv的验证比bbed更加严格
12C sysaux 异常恢复—ORA-01190错误恢复
有朋友请求支援,他们数据库由于file 3 大量坏块,然后直接使用rman 备份还原了file 3,但是在recover过程中发现归档丢失,而且整个库在丢失归档的scn之后,还做过resetlogs操作,导致现在整个库无法正常启动,报ORA-01190错误,希望帮忙把file 3 给online起来,整个库正常open【当然在丢失sysaux的情况下,数据库可以open起来,但是这种情况下,迁移数据比较麻烦】
SQL> startup; ORACLE 例程已经启动。 Total System Global Area 3.1868E+10 bytes Fixed Size 3601144 bytes Variable Size 2.8655E+10 bytes Database Buffers 3154116608 bytes Redo Buffers 54804480 bytes 数据库装载完毕。 ORA-01190: 控制文件或数据文件 3 来自最后一个 RESETLOGS 之前 ORA-01110: 数据文件 3: 'E:\APP\ORAADM\ORADATA\ORCL\SYSAUX01.DBF'
Oracle Database Recovery Check Result结果显示[脚本]
尝试不完全恢复并使用隐含参数打开库
Fri Oct 02 19:10:12 2015 ALTER DATABASE RECOVER database until cancel Fri Oct 02 19:10:12 2015 Media Recovery Start Started logmerger process Fri Oct 02 19:10:12 2015 Media Recovery failed with error 16433 Fri Oct 02 19:10:14 2015 Recovery Slave PR00 previously exited with exception 283 ORA-283 signalled during: ALTER DATABASE RECOVER database until cancel ... Fri Oct 02 19:10:37 2015 Errors in file E:\APP\ORAADM\diag\rdbms\orcl\oaorcl\trace\oaorcl_m000_5176.trc: ORA-16433: The database or pluggable database must be opened in read/write mode. Fri Oct 02 19:10:37 2015 Errors in file E:\APP\ORAADM\diag\rdbms\orcl\oaorcl\trace\oaorcl_m000_5176.trc: ORA-16433: The database or pluggable database must be opened in read/write mode. ALTER DATABASE RECOVER database until cancel Fri Oct 02 19:11:18 2015 Media Recovery Start Started logmerger process Fri Oct 02 19:11:18 2015 Media Recovery failed with error 16433 Fri Oct 02 19:11:19 2015 Recovery Slave PR00 previously exited with exception 283 ORA-283 signalled during: ALTER DATABASE RECOVER database until cancel ... alter database open resetlogs ORA-1139 signalled during: alter database open resetlogs... alter database open Fri Oct 02 19:11:49 2015 Errors in file E:\APP\ORAADM\diag\rdbms\orcl\oaorcl\trace\oaorcl_ora_4252.trc: ORA-01190: 控制文件或数据文件 3 来自最后一个 RESETLOGS 之前 ORA-01110: 数据文件 3: 'E:\APP\ORAADM\ORADATA\ORCL\SYSAUX01.DBF' ORA-1190 signalled during: alter database open... Fri Oct 02 19:15:38 2015 Errors in file E:\APP\ORAADM\diag\rdbms\orcl\oaorcl\trace\oaorcl_m000_5292.trc: ORA-16433: The database or pluggable database must be opened in read/write mode. Fri Oct 02 19:15:38 2015 Errors in file E:\APP\ORAADM\diag\rdbms\orcl\oaorcl\trace\oaorcl_m000_5292.trc: ORA-16433: The database or pluggable database must be opened in read/write mode. Fri Oct 02 19:20:39 2015 Errors in file E:\APP\ORAADM\diag\rdbms\orcl\oaorcl\trace\oaorcl_m000_2276.trc: ORA-16433: The database or pluggable database must be opened in read/write mode. Fri Oct 02 19:20:39 2015 Errors in file E:\APP\ORAADM\diag\rdbms\orcl\oaorcl\trace\oaorcl_m000_2276.trc: ORA-16433: The database or pluggable database must be opened in read/write mode. Fri Oct 02 19:25:40 2015 Errors in file E:\APP\ORAADM\diag\rdbms\orcl\oaorcl\trace\oaorcl_m000_4804.trc: ORA-16433: The database or pluggable database must be opened in read/write mode. Fri Oct 02 19:25:40 2015 Errors in file E:\APP\ORAADM\diag\rdbms\orcl\oaorcl\trace\oaorcl_m000_4804.trc: ORA-16433: The database or pluggable database must be opened in read/write mode. Fri Oct 02 19:30:41 2015 Errors in file E:\APP\ORAADM\diag\rdbms\orcl\oaorcl\trace\oaorcl_m000_876.trc: ORA-16433: The database or pluggable database must be opened in read/write mode. Fri Oct 02 19:30:41 2015 Errors in file E:\APP\ORAADM\diag\rdbms\orcl\oaorcl\trace\oaorcl_m000_876.trc: ORA-16433: The database or pluggable database must be opened in read/write mode. Fri Oct 02 19:32:40 2015 Shutting down instance (abort)
数据库遭遇ORA-16433,此类方法无法打开数据库,根据经验值出现此类问题,可能需要重建控制文件,但是由于其中file 3的resetlogs scn不正确,无法包含该文件重建控制文件
Fri Oct 02 20:10:55 2015 WARNING: Default Temporary Tablespace not specified in CREATE DATABASE command Default Temporary Tablespace will be necessary for a locally managed database in future release Fri Oct 02 20:10:55 2015 Errors in file E:\APP\ORAADM\diag\rdbms\orcl\oaorcl\trace\oaorcl_ora_5004.trc: ORA-01189: ????????????? RESETLOGS ORA-01110: ???? 3: 'E:\APP\ORAADM\ORADATA\ORCL\SYSAUX01.DBF' ORA-1503 signalled during: CREATE CONTROLFILE REUSE DATABASE "orcl" RESETLOGS FORCE LOGGING ARCHIVELOG MAXLOGFILES 16 MAXLOGMEMBERS 3 MAXDATAFILES 100 MAXINSTANCES 8 MAXLOGHISTORY 2921 LOGFILE GROUP 3 'E:\APP\ORAADM\ORADATA\ORCL\REDO03.LOG' size 50M, GROUP 2 'E:\APP\ORAADM\ORADATA\ORCL\REDO02.LOG' size 50M, GROUP 1 'E:\APP\ORAADM\ORADATA\ORCL\REDO01.LOG' size 50M DATAFILE 'E:\APP\ORAADM\ORADATA\ORCL\SYSTEM01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\PDBSEED\SYSTEM01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\SYSAUX01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\PDBSEED\SYSAUX01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\UNDOTBS01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\USERS01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\PDBORCL\SYSTEM01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\PDBORCL\SYSAUX01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\PDBORCL\SAMPLE_SCHEMA_USERS01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\PDBORCL\EXAMPLE01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\V3XSPACE.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\NMSA_BACKUP01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\V3XSPACE1.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\V3XSPACE01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\V3XSPACE02.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\V3XSPACE03.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\V3XSPACE04.DBF' CHARACTER SET AL32UTF8 ...
除掉file 3 继续重建控制文件
Fri Oct 02 20:33:11 2015 Successful mount of redo thread 1, with mount id 1419796614 Completed: CREATE CONTROLFILE REUSE DATABASE "orcl" RESETLOGS FORCE LOGGING ARCHIVELOG MAXLOGFILES 16 MAXLOGMEMBERS 3 MAXDATAFILES 100 MAXINSTANCES 8 MAXLOGHISTORY 2921 LOGFILE GROUP 3 'E:\APP\ORAADM\ORADATA\ORCL\REDO03.LOG' size 50M, GROUP 2 'E:\APP\ORAADM\ORADATA\ORCL\REDO02.LOG' size 50M, GROUP 1 'E:\APP\ORAADM\ORADATA\ORCL\REDO01.LOG' size 50M DATAFILE 'E:\APP\ORAADM\ORADATA\ORCL\SYSTEM01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\PDBSEED\SYSTEM01.DBF', --'E:\APP\ORAADM\ORADATA\ORCL\SYSAUX01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\PDBSEED\SYSAUX01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\UNDOTBS01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\USERS01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\PDBORCL\SYSTEM01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\PDBORCL\SYSAUX01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\PDBORCL\SAMPLE_SCHEMA_USERS01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\PDBORCL\EXAMPLE01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\V3XSPACE.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\NMSA_BACKUP01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\V3XSPACE1.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\V3XSPACE01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\V3XSPACE02.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\V3XSPACE03.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\V3XSPACE04.DBF' CHARACTER SET AL32UTF8
继续恢复数据库
ALTER DATABASE OPEN Fri Oct 02 20:34:57 2015 ………… Archived Log entry 3 added for thread 1 sequence 8 ID 0x54a083a3 dest 1: Fri Oct 02 20:35:16 2015 Tablespace 'SYSAUX' #1 found in data dictionary, but not in the controlfile. Adding to controlfile. Tablespace 'TEMP' #3 found in data dictionary, but not in the controlfile. Adding to controlfile. File #3 found in data dictionary but not in controlfile. Creating OFFLINE file 'MISSING00003' in the controlfile. Corrected file 15 plugged in read-only status in control file Corrected file 16 plugged in read-only status in control file Corrected file 17 plugged in read-only status in control file Corrected file 18 plugged in read-only status in control file Corrected file 19 plugged in read-only status in control file Dictionary check complete Verifying file header compatibility for 11g tablespace encryption.. Verifying 11g file header compatibility for tablespace encryption completed Fri Oct 02 20:35:19 2015 SMON: enabling tx recovery Fri Oct 02 20:35:19 2015 ********************************************************************* WARNING: The following temporary tablespaces in container(CDB$ROOT) contain no files. Starting background process SMCO Fri Oct 02 20:35:19 2015 SMCO started with pid=45, OS id=1500 This condition can occur when a backup controlfile has been restored. It may be necessary to add files to these tablespaces. That can be done using the SQL statement: ALTER TABLESPACE <tablespace_name> ADD TEMPFILE Alternatively, if these temporary tablespaces are no longer needed, then they can be dropped. Empty temporary tablespace: TEMP ********************************************************************* Database Characterset is AL32UTF8 No Resource Manager plan active Fri Oct 02 20:35:21 2015 Errors in file E:\APP\ORAADM\diag\rdbms\orcl\oaorcl\trace\oaorcl_ora_2220.trc: ORA-00376: 此时无法读取文件 3 ORA-01111: 数据文件 3 名称未知 - 请重命名以更正文件 ORA-01110: 数据文件 3: 'C:\APP\ORAADM\PRODUCT\12.1.0\DBHOME_1\DATABASE\MISSING00003' Fri Oct 02 20:35:21 2015 Errors in file E:\APP\ORAADM\diag\rdbms\orcl\oaorcl\trace\oaorcl_ora_2220.trc: ORA-00376: 此时无法读取文件 3 ORA-01111: 数据文件 3 名称未知 - 请重命名以更正文件 ORA-01110: 数据文件 3: 'C:\APP\ORAADM\PRODUCT\12.1.0\DBHOME_1\DATABASE\MISSING00003' Error 376 happened during db open, shutting down database USER (ospid: 2220): terminating the instance due to error 376 Fri Oct 02 20:35:26 2015 Instance terminated by USER, pid = 2220 ORA-1092 signalled during: ALTER DATABASE OPEN... opiodr aborting process unknown ospid (2220) as a result of ORA-1092
此时由于file 3 未包含在控制文件中,但是存在数据字典中,因此在数据库open的时候出现了默认文件名MISSING0003,尝试重命名改文件指定为存在的file 3,并且尝试恢复
SQL> startup mount; ORACLE 例程已经启动。 Total System Global Area 3.1868E+10 bytes Fixed Size 3601144 bytes Variable Size 2.8655E+10 bytes Database Buffers 3154116608 bytes Redo Buffers 54804480 bytes 数据库装载完毕。 SQL> alter database datafile 3 offline; 数据库已更改。 SQL> alter database rename file 'C:\APP\ORAADM\PRODUCT\12.1.0\DBHOME_1\DATABASE\ MISSING00003' to 'E:\APP\ORAADM\ORADATA\ORCL\SYSAUX01.DBF'; 数据库已更改。 SQL> recover database until cancel; ORA-00279: 更改 617412726 (在 10/02/2015 20:35:06 生成) 对于线程 1 是必需的 ORA-00289: 建议: E:\APP\ORAADM\FAST_RECOVERY_AREA\ORCL\ARCHIVELOG\2015_10_02\O1_MF_1_9_%U_.ARC ORA-00280: 更改 617412726 (用于线程 1) 在序列 #9 中 指定日志: {<RET>=suggested | filename | AUTO | CANCEL} E:\APP\ORAADM\ORADATA\ORCL\REDO01.LOG ORA-00310: archived log contains sequence 7; sequence 9 required ORA-00334: archived log: 'E:\APP\ORAADM\ORADATA\ORCL\REDO01.LOG' ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below ORA-01194: file 1 needs more recovery to be consistent ORA-01110: data file 1: 'E:\APP\ORAADM\ORADATA\ORCL\SYSTEM01.DBF' SQL> recover database until cancel; ORA-00279: 更改 617412726 (在 10/02/2015 20:35:06 生成) 对于线程 1 是必需的 ORA-00289: 建议: E:\APP\ORAADM\FAST_RECOVERY_AREA\ORCL\ARCHIVELOG\2015_10_02\O1_MF_1_9_%U_.ARC ORA-00280: 更改 617412726 (用于线程 1) 在序列 #9 中 指定日志: {<RET>=suggested | filename | AUTO | CANCEL} E:\APP\ORAADM\ORADATA\ORCL\REDO03.LOG 已应用的日志。 完成介质恢复。 SQL> alter database datafile 3 online; 数据库已更改。 SQL> alter database open resetlogs; alter database open resetlogs * 第 1 行出现错误: ORA-01122: 数据库文件 3 验证失败 ORA-01110: 数据文件 3: 'E:\APP\ORAADM\ORADATA\ORCL\SYSAUX01.DBF' ORA-01202: 此文件的原型错误 - 创建时间错误
这里比较明显ORA-01202,由于创建控制文件之时没有file 3信息,因此导致控制文件中关于file 3的信息和该文件头的创建时间不一致(此处之时显示了时间不一致,如果通过bbed修改时间,后续可能还有很多东西不一致,因此通过bbed 一个个修改一个个尝试,理论可行,但实际可操作性不好),因此尝试直接使用bbed修改file 3文件头(由于是win环境,操作稍微麻烦点),把resetlogs信息修改和其他的一样
BBED> m /x 3c6b2b35 File: SYSAUX01.dbf (3) Block: 2 Offsets: 112 to 143 Dba:0x00c00002 ------------------------------------------------------------------------ 3c6b2b35 386b2200 00000000 00000000 00000000 00000000 00004000 bb460000 <32 bytes per line> BBED> set offset 116 OFFSET 116 BBED> m /x 3137ca24 File: SYSAUX01.dbf (3) Block: 2 Offsets: 116 to 147 Dba:0x00c00002 ------------------------------------------------------------------------ 3137ca24 00000000 00000000 00000000 00000000 00004000 bb460000 7dc12b35 <32 bytes per line> BBED> m /x b9f8 File: SYSAUX01.dbf (3) Block: 2 Offsets: 484 to 515 Dba:0x00c00002 ------------------------------------------------------------------------ b9f8a424 00000000 e65e2435 01000000 d3410000 b89b0000 10000900 02000000 <32 bytes per line> BBED> set offset +2 OFFSET 486 BBED> m /x cc24 File: SYSAUX01.dbf (3) Block: 2 Offsets: 486 to 517 Dba:0x00c00002 ------------------------------------------------------------------------ cc240000 0000e65e 24350100 0000d341 0000b89b 00001000 09000200 00000000 <32 bytes per line> BBED> m /x 87df offset 492 File: SYSAUX01.dbf (3) Block: 2 Offsets: 492 to 523 Dba:0x00c00002 ------------------------------------------------------------------------ 87df2435 01000000 d3410000 b89b0000 10000900 02000000 00000000 00000000 <32 bytes per line> BBED> BBED> m /x 2b35 offset +2 File: SYSAUX01.dbf (3) Block: 2 Offsets: 494 to 525 Dba:0x00c00002 ------------------------------------------------------------------------ 2b350100 0000d341 0000b89b 00001000 09000200 00000000 00000000 00000000 <32 bytes per line> BBED> d offset 140 File: SYSAUX01.dbf (3) Block: 2 Offsets: 140 to 171 Dba:0x00c00002 ------------------------------------------------------------------------ bb460000 7dc12b35 ba460000 00000000 00000000 00000000 00000000 00000000 <32 bytes per line> BBED> m /x 4248 File: SYSAUX01.dbf (3) Block: 2 Offsets: 140 to 171 Dba:0x00c00002 ------------------------------------------------------------------------ 42480000 7dc12b35 ba460000 00000000 00000000 00000000 00000000 00000000 <32 bytes per line> BBED> d offset 148 File: SYSAUX01.dbf (3) Block: 2 Offsets: 148 to 179 Dba:0x00c00002 ------------------------------------------------------------------------ ba460000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 <32 bytes per line> BBED> m /x 4148 File: SYSAUX01.dbf (3) Block: 2 Offsets: 148 to 179 Dba:0x00c00002 ------------------------------------------------------------------------ 41480000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 <32 bytes per line> BBED> sum apply Check value for File 3, Block 2: current = 0xd0c8, required = 0xd0c8 BBED> verify DBVERIFY - Verification starting FILE = SYSAUX01.dbf BLOCK = 1 DBVERIFY - Verification complete Total Blocks Examined : 1 Total Blocks Processed (Data) : 0 Total Blocks Failing (Data) : 0 Total Blocks Processed (Index): 0 Total Blocks Failing (Index): 0 Total Blocks Empty : 0 Total Blocks Marked Corrupt : 0 Total Blocks Influx : 0 Message 531 not found; product=RDBMS; facility=BBED
修改完file 3的文件头之后,再次重建控制文件,此次包含file 3
Fri Oct 02 21:19:58 2015 Successful mount of redo thread 1, with mount id 1419797885 Completed: CREATE CONTROLFILE REUSE DATABASE "orcl" NORESETLOGS FORCE LOGGING ARCHIVELOG MAXLOGFILES 16 MAXLOGMEMBERS 3 MAXDATAFILES 100 MAXINSTANCES 8 MAXLOGHISTORY 2921 LOGFILE GROUP 3 'E:\APP\ORAADM\ORADATA\ORCL\REDO03.LOG' size 50M, GROUP 2 'E:\APP\ORAADM\ORADATA\ORCL\REDO02.LOG' size 50M, GROUP 1 'E:\APP\ORAADM\ORADATA\ORCL\REDO01.LOG' size 50M DATAFILE 'E:\APP\ORAADM\ORADATA\ORCL\SYSTEM01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\PDBSEED\SYSTEM01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\SYSAUX01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\PDBSEED\SYSAUX01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\UNDOTBS01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\USERS01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\PDBORCL\SYSTEM01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\PDBORCL\SYSAUX01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\PDBORCL\SAMPLE_SCHEMA_USERS01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\PDBORCL\EXAMPLE01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\V3XSPACE.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\NMSA_BACKUP01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\V3XSPACE1.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\V3XSPACE01.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\V3XSPACE02.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\V3XSPACE03.DBF', 'E:\APP\ORAADM\ORADATA\ORCL\V3XSPACE04.DBF' CHARACTER SET AL32UTF8
继续恢复数据库,数据库正常open,而且file 3 已经正常online,数据库可以直接导出来,至此恢复大体完成