标签云
asm恢复 bbed bootstrap$ dul kcbzib_kcrsds_1 kccpb_sanity_check_2 kcratr_nab_less_than_odr MySQL恢复 obet ORA-00312 ORA-00704 ORA-00742 ORA-01110 ORA-01200 ORA-01555 ORA-01578 ORA-01595 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-600 kcratr_nab_less_than_odr 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 比特币加密文章分类
- MongoDB (1)
- MongoDB恢复 (1)
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (112)
- 数据库 (1,880)
- DB2 (22)
- MySQL (82)
- Oracle (1,705)
- Data Guard (53)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (168)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (72)
- Oracle Bug (8)
- Oracle RAC (56)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (659)
- Oracle安装升级 (108)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (91)
- PostgreSQL (37)
- pdu工具 (7)
- PostgreSQL恢复 (13)
- SQL Server (34)
- SQL Server恢复 (14)
- TimesTen (7)
- 达梦数据库 (5)
- 达梦恢复 (3)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (51)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (34)
- MongoDB (1)
-
最近发表
- Firebird 损坏数据库数据抢救工具—firebirdext
- Oracle 19c 202610补丁(RUs+OJVM)-19.33
- 由于con$.con#值达到极限,触发数据库增加约束报ORA-600 12807错误
- MongoDB 离线提取工具—mongoext
- .bres勒索病毒加密数据库dmp文件可恢复
- ORA-600 krsm_mrp_rebuild_lf_list.lno_mismatch
- 记录一次0丢失的ORA-00354: 损坏重做日志块标头故障恢复
- 不当数据库恢复操作导致一个月数据丢失
- obet快速修复oracle 位图损坏块
- 不太常见的10.2.0.1的oracle redo损坏恢复
- obet forcecopy功能抢救硬件故障中的数据文件
- kcratr_nab_less_than_odr和system坏块故障处理
- 通过obet 恢复system坏块,打开数据库
- obet dbv功能完整说明
- 分享一例运行在aix上的sap系统数据库恢复过程
- OBET-Oracle Block Editor Tool使用说明
- 几乎动用了所有手段的Oracle故障恢复
- Oracle Block Edit Tool (obet) 功能增强–2026.07
- Oracle 19c 202607补丁(RUs+OJVM)-19.32
- Patch_SCN快速修复ORA-01555数据库open故障
分类目录归档:Oracle备份恢复
Oracle 数据文件大小为0kb或者文件丢失恢复
接到一个朋友恢复请求,由于rose频繁切换导致文件系统部分数据文件变化为0kb和文件丢失.
故障现象
部分数据文件变化为0kb和文件丢失.


这里比较明显,数据库的users03变为了0kb和users04丢失.数据库alert日志报错信息如下:
Completed: alter database mount exclusive alter database open Errors in file E:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_dbw0_12008.trc: ORA-01157: ????/?????? 7 - ??? DBWR ???? ORA-01110: ???? 7: 'E:\APP\ADMINISTRATOR\ORADATA\ORCL\USERS03.DBF' ORA-27047: ?????????? OSD-04006: ReadFile() 失败, 无法读取文件 O/S-Error: (OS 38) 已到文件结尾。 Errors in file E:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_dbw0_12008.trc: ORA-01157: ????/?????? 8 - ??? DBWR ???? ORA-01110: ???? 8: 'E:\APP\ADMINISTRATOR\ORADATA\ORCL\USERS04.DBF' ORA-27041: ?????? OSD-04002: 无法打开文件 O/S-Error: (OS 2) 系统找不到指定的文件。 Errors in file E:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_ora_12040.trc: ORA-01157: ????/?????? 7 - ??? DBWR ???? ORA-01110: ???? 7: 'E:\APP\ADMINISTRATOR\ORADATA\ORCL\USERS03.DBF' ORA-1157 signalled during: alter database open... Fri May 04 09:35:10 2018 Checker run found 2 new persistent data failures
alert日志的报错也比较明显,users03是文件超过了大小(大小为0kb,读取之后肯定超过大小),users04提示无法打开文件(文件在文件系统层面已经丢失).现在问题比较明显由于文件系统故障导致文件大小为0和丢失
碎片扫描恢复
常规的方法肯定无法恢复,比较好的方法只能是底层碎片扫描重组,结合多种扫描工具,最后发现一个做底层恢复的朋友的工具效果不错,扫描结果如下

通过工具分析坏块情况
C:\Users\Administrator>dbv FiLe=D:\0504\ORCL_TS.4_FILE.7_10.ora DBVERIFY: Release 11.2.0.4.0 - Production on 星期六 5月 5 08:52:53 2018 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. DBVERIFY - 开始验证: FILE = D:\0504\ORCL_TS.4_FILE.7_10.ora ……………… 页 382565 标记为损坏 Corrupt block relative dba: 0x01c5d665 (file 7, block 382565) Completely zero block found during dbv: 页 382566 标记为损坏 Corrupt block relative dba: 0x01c5d666 (file 7, block 382566) Completely zero block found during dbv: 页 382567 标记为损坏 Corrupt block relative dba: 0x01c5d667 (file 7, block 382567) Completely zero block found during dbv: DBVERIFY - 验证完成 检查的页总数: 1374720 处理的页总数 (数据): 27582 失败的页总数 (数据): 0 处理的页总数 (索引): 20114 失败的页总数 (索引): 0 处理的页总数 (其他): 1319752 处理的总页数 (段) : 0 失败的总页数 (段) : 0 空的页总数: 1 标记为损坏的总页数: 7271 流入的页总数: 0 加密的总页数 : 0 最高块 SCN : 228271996 (0.228271996) C:\Users\Administrator>dbv FiLe=D:\0504\ORCL_TS.4_FILE.8_8.ora DBVERIFY: Release 11.2.0.4.0 - Production on 星期六 5月 5 08:52:53 2018 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. DBVERIFY - 开始验证: FILE = D:\0504\ORCL_TS.4_FILE.8_8.ora DBVERIFY - 验证完成 检查的页总数: 1136896 处理的页总数 (数据): 36639 失败的页总数 (数据): 0 处理的页总数 (索引): 57038 失败的页总数 (索引): 0 处理的页总数 (其他): 1043218 处理的总页数 (段) : 0 失败的总页数 (段) : 0 空的页总数: 1 标记为损坏的总页数: 0 流入的页总数: 0 加密的总页数 : 0 最高块 SCN : 228271997 (0.228271997) C:\Users\Administrator>
这里通过分析恢复的两个文件总的block数量2511618,其中连续损坏7271个block损坏,由于出现问题之后,数据库被offline这两个文件继续启动运行了几个小时,导致少量block被覆盖,恢复软件直接置空.后续的恢复比较顺利,正常open数据库,然后处理坏块对象(正好不是业务核心表的lob字段,所有部分丢失影响不是非常大).
温馨提醒:
1. 数据文件和备份不要放在同一个阵列上,更不能是同一个分区(卷)上
2. 出现此类问题之后,应当理解停止对该分区的任何写操作,方式丢失或者大小为0KB的文件被覆盖.
如果需要专业ORACLE数据库恢复技术支持,请联系我们
Phone:17813235971 Q Q:107644445
E-Mail:dba@xifenfei.com
发表在 非常规恢复
标签为 dbf 0kb, dbf 0字节, O/S-Error: (OS 2), O/S-Error: (OS 38), oracle 0kb, oracle 0字节, 文件丢失恢复, 文件大小为0, 碎片扫描, 碎片重组
评论关闭
ORA-00333 故障恢复
数据库启动报错
SQL> startup ORACLE instance started. Total System Global Area 1241513984 bytes Fixed Size 1219136 bytes Variable Size 218105280 bytes Database Buffers 1006632960 bytes Redo Buffers 15556608 bytes Database mounted. ORA-00333: redo log read error block 48641 count 8192
数据库启动报ORA-00333错误,官方解释为读redo log发生错误.
00333, 00000, "redo log read error block %s count %s" // *Cause: An IO error occurred while reading the log described in the // accompanying error. // *Action: Restore accessibility to file, or get another copy of the file.
alert日志
Sat Apr 14 00:39:13 2018 alter database open Sat Apr 14 00:39:13 2018 Beginning crash recovery of 1 threads parallel recovery started with 7 processes Sat Apr 14 00:39:13 2018 Started redo scan Sat Apr 14 00:39:14 2018 Errors in file /oracle/admin/oa/udump/oa_ora_5659.trc: ORA-00333: redo log read error block 54785 count 2048 ORA-00312: online log 1 thread 1: '/oracle/oradata/oa/redo01.log' ORA-27072: File I/O error Linux Error: 5: Input/output error Additional information: 4 Additional information: 54785 Additional information: 957952 Sat Apr 14 00:39:14 2018 Errors in file /oracle/admin/oa/udump/oa_ora_5659.trc: ORA-00333: redo log read error block 48641 count 8192 ORA-00312: online log 1 thread 1: '/oracle/oradata/oa/redo01.log' ORA-27091: unable to queue I/O ORA-27072: File I/O error Linux Error: 5: Input/output error Additional information: 4 Additional information: 54785 Additional information: 957952 Sat Apr 14 00:39:14 2018 Aborting crash recovery due to error 333 Sat Apr 14 00:39:14 2018 Errors in file /oracle/admin/oa/udump/oa_ora_5659.trc: ORA-00333: redo log read error block 48641 count 8192 ORA-333 signalled during: alter database open...
由于硬件异常,数据库在启动的时候读取redo异常,从而使得数据库无法正常启动
检查系统日志
Apr 14 11:14:58 oa kernel: Info fld=0x0, Current sda: sense key Hardware Error Apr 14 11:14:59 oa kernel: Additional sense: Internal target failure Apr 14 11:14:59 oa kernel: end_request: I/O error, dev sda, sector 190500041 Apr 14 11:14:59 oa kernel: SCSI error : <0 0 0 0> return code = 0x8000002 Apr 14 11:14:59 oa kernel: Info fld=0x0, Current sda: sense key Hardware Error Apr 14 11:14:59 oa kernel: Additional sense: Internal target failure Apr 14 11:14:59 oa kernel: end_request: I/O error, dev sda, sector 190500049 Apr 14 11:14:59 oa kernel: SCSI error : <0 0 0 0> return code = 0x8000002 Apr 14 11:14:59 oa kernel: Info fld=0x0, Current sda: sense key Hardware Error Apr 14 11:14:59 oa kernel: Additional sense: Internal target failure Apr 14 11:14:59 oa kernel: end_request: I/O error, dev sda, sector 190500057 Apr 14 11:14:59 oa kernel: SCSI error : <0 0 0 0> return code = 0x8000002 Apr 14 11:14:59 oa kernel: Info fld=0x0, Current sda: sense key Hardware Error Apr 14 11:14:59 oa kernel: Additional sense: Internal target failure Apr 14 11:14:59 oa kernel: end_request: I/O error, dev sda, sector 190500065 Apr 14 11:14:59 oa kernel: SCSI error : <0 0 0 0> return code = 0x8000002
大量类似I/O error, dev sda, sector错误,很可能是由于硬件方面异常导致.
损坏redo为当前redo

针对这样的情况,由于是硬件故障,先要通过dbv或者rman检查其他数据文件是否正常,如果有数据文件不能读,那需要对数据文件进行特殊处理.本次恢复的中,客户相对比较幸运,所有数据文件全部可以正常访问,只是当前redo异常,通过隐含参数强制拉库,然后导出数据,重建库解决.类似文章:又一起存储故障导致ORA-00333 ORA-00312恢复
恢复没有控制文件备份的rman数据文件备份
最近有朋友咨询,只有rman备份数据文件,无控制文件备份的问题,这里进行分析验证
只有数据文件的rman备份
这里只有数据文件的备份,没有任何控制文件的备份
C:\Documents and Settings\Administrator>e: E:\>dir 驱动器 E 中的卷是 新加卷 卷的序列号是 68FB-8527 E:\ 的目录 2018-03-29 10:53 6,163,873,792 FULL_20180329_01SV08N2_1_1.RMAN 2018-03-29 10:54 1,050,558,464 FULL_20180329_02SV0918_1_1.RMAN 2018-03-29 10:56 2,167,414,784 FULL_20180329_03SV092B_1_1.RMAN 2018-03-29 11:07 1,034,625,024 FULL_20180329_05SV09QQ_1_1.RMAN 2018-03-29 11:07 1,376,256 FULL_20180329_06SV09RJ_1_1.RMAN 2018-03-29 11:08 3,104,768 FULL_20180329_07SV09TP_1_1.RMAN
还原system01.dbf
SQL> startup nomount ORACLE 例程已经启动。 Total System Global Area 2137886720 bytes Fixed Size 2177456 bytes Variable Size 1224738384 bytes Database Buffers 905969664 bytes Redo Buffers 5001216 bytes SQL> @restore_datafile.sql system01.dbf Trying : E:/FULL_20180329_02SV0918_1_1.RMAN From : DISK Data File : Found ------------------------ RESTORED Data File To: D:\oradata\orcl\system01.dbf PL/SQL 过程已成功完成。
重建控制文件
SQL> startup nomount pfile=e:/pfile.txt ORACLE 例程已经启动。 Total System Global Area 2137886720 bytes Fixed Size 2177456 bytes Variable Size 1224738384 bytes Database Buffers 905969664 bytes Redo Buffers 5001216 bytes SQL> CREATE CONTROLFILE REUSE DATABASE "ORCL" RESETLOGS NOARCHIVELOG 2 MAXLOGFILES 50 3 MAXLOGMEMBERS 5 4 MAXDATAFILES 100 5 MAXINSTANCES 1 6 MAXLOGHISTORY 226 7 LOGFILE 8 GROUP 1 'D:\oradata\orcl\redo01.log' SIZE 100M, 9 GROUP 2 'D:\oradata\orcl\redo02.log' SIZE 100M, 10 GROUP 3 'D:\oradata\orcl\redo03.log' SIZE 100M 11 DATAFILE 12 'D:\oradata\orcl\system01.dbf' 13 CHARACTER SET ZHS16GBK 14 ; 控制文件已创建。
注册备份集
E:\>rman target /
恢复管理器: Release 11.2.0.1.0 - Production on 星期四 3月 29 15:46:17 2018
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
已连接到目标数据库: ORCL (DBID=1449113534, 未打开)
RMAN> catalog start with 'e:/*.rman';
使用目标数据库控制文件替代恢复目录
搜索与样式 e:/*.rman 匹配的所有文件
数据库未知文件的列表
=====================================
文件名: E:\FULL_20180329_01SV08N2_1_1.RMAN
文件名: E:\FULL_20180329_02SV0918_1_1.RMAN
文件名: E:\FULL_20180329_03SV092B_1_1.RMAN
文件名: E:\FULL_20180329_05SV09QQ_1_1.RMAN
文件名: E:\FULL_20180329_06SV09RJ_1_1.RMAN
文件名: E:\FULL_20180329_07SV09TP_1_1.RMAN
是否确实要将上述文件列入目录 (输入 YES 或 NO)? yes
正在编制文件目录...
目录编制完毕
已列入目录的文件的列表
=======================
文件名: E:\FULL_20180329_01SV08N2_1_1.RMAN
文件名: E:\FULL_20180329_02SV0918_1_1.RMAN
文件名: E:\FULL_20180329_03SV092B_1_1.RMAN
文件名: E:\FULL_20180329_05SV09QQ_1_1.RMAN
文件名: E:\FULL_20180329_06SV09RJ_1_1.RMAN
文件名: E:\FULL_20180329_07SV09TP_1_1.RMAN
RMAN> list backup;
备份集列表
===================
BS 关键字 类型 LV 大小 设备类型 经过时间 完成时间
------- ---- -- ---------- ----------- ------------ ----------
1 Full 5.74G DISK 00:00:00 29-3月 -18
BP 关键字: 1 状态: AVAILABLE 已压缩: NO 标记: TAG20180329T104802
段名:E:\FULL_20180329_01SV08N2_1_1.RMAN
备份集 1 中的数据文件列表
文件 LV 类型 Ckp SCN Ckp 时间 名称
---- -- ---- ---------- ---------- ----
5 Full 96384627 29-3月 -18
BS 关键字 类型 LV 大小 设备类型 经过时间 完成时间
------- ---- -- ---------- ----------- ------------ ----------
2 Full 1001.88M DISK 00:00:00 29-3月 -18
BP 关键字: 2 状态: AVAILABLE 已压缩: NO 标记: TAG20180329T104802
段名:E:\FULL_20180329_02SV0918_1_1.RMAN
备份集 2 中的数据文件列表
文件 LV 类型 Ckp SCN Ckp 时间 名称
---- -- ---- ---------- ---------- ----
1 Full 96384627 29-3月 -18 D:\ORADATA\ORCL\SYSTEM01.DBF
BS 关键字 类型 LV 大小 设备类型 经过时间 完成时间
------- ---- -- ---------- ----------- ------------ ----------
3 Full 2.02G DISK 00:00:00 29-3月 -18
BP 关键字: 3 状态: AVAILABLE 已压缩: NO 标记: TAG20180329T104802
段名:E:\FULL_20180329_03SV092B_1_1.RMAN
备份集 3 中的数据文件列表
文件 LV 类型 Ckp SCN Ckp 时间 名称
---- -- ---- ---------- ---------- ----
6 Full 96384627 29-3月 -18
BS 关键字 类型 LV 大小 设备类型 经过时间 完成时间
------- ---- -- ---------- ----------- ------------ ----------
4 Full 986.69M DISK 00:00:00 29-3月 -18
BP 关键字: 4 状态: AVAILABLE 已压缩: NO 标记: TAG20180329T110706
段名:E:\FULL_20180329_05SV09QQ_1_1.RMAN
备份集 4 中的数据文件列表
文件 LV 类型 Ckp SCN Ckp 时间 名称
---- -- ---- ---------- ---------- ----
2 Full 96384627 29-3月 -18
BS 关键字 类型 LV 大小 设备类型 经过时间 完成时间
------- ---- -- ---------- ----------- ------------ ----------
5 Full 1.30M DISK 00:00:00 29-3月 -18
BP 关键字: 5 状态: AVAILABLE 已压缩: NO 标记: TAG20180329T110706
段名:E:\FULL_20180329_06SV09RJ_1_1.RMAN
备份集 5 中的数据文件列表
文件 LV 类型 Ckp SCN Ckp 时间 名称
---- -- ---- ---------- ---------- ----
4 Full 96384627 29-3月 -18
BS 关键字 类型 LV 大小 设备类型 经过时间 完成时间
------- ---- -- ---------- ----------- ------------ ----------
6 Full 2.95M DISK 00:00:00 29-3月 -18
BP 关键字: 6 状态: AVAILABLE 已压缩: NO 标记: TAG20180329T110841
段名:E:\FULL_20180329_07SV09TP_1_1.RMAN
备份集 6 中的数据文件列表
文件 LV 类型 Ckp SCN Ckp 时间 名称
---- -- ---- ---------- ---------- ----
3 Full 96384627 29-3月 -18
还原所有数据文件
SQL> @restore_datafile all_file Restoring All Data Files : -------------------------- Attempting To Restore :D:\oradata\orcl\1.dbf ------------------------ Trying : E:/FULL_20180329_01SV08N2_1_1.RMAN From : DISK Data File: Not Found ------------------------ Trying : E:/FULL_20180329_02SV0918_1_1.RMAN From : DISK Data File : Found ------------------------ RESTORED Data File To: D:\oradata\orcl\1.dbf Attempting To Restore :D:\oradata\orcl\2.dbf ------------------------ Trying : E:/FULL_20180329_01SV08N2_1_1.RMAN From : DISK Data File: Not Found ------------------------ Trying : E:/FULL_20180329_02SV0918_1_1.RMAN From : DISK Data File: Not Found ------------------------ Trying : E:/FULL_20180329_03SV092B_1_1.RMAN From : DISK Data File: Not Found ------------------------ Trying : E:/FULL_20180329_05SV09QQ_1_1.RMAN From : DISK Data File : Found ------------------------ RESTORED Data File To: D:\oradata\orcl\2.dbf Attempting To Restore :D:\oradata\orcl\3.dbf ------------------------ Trying : E:/FULL_20180329_01SV08N2_1_1.RMAN From : DISK Data File: Not Found ------------------------ Trying : E:/FULL_20180329_02SV0918_1_1.RMAN From : DISK Data File: Not Found ------------------------ Trying : E:/FULL_20180329_03SV092B_1_1.RMAN From : DISK Data File: Not Found ------------------------ Trying : E:/FULL_20180329_05SV09QQ_1_1.RMAN From : DISK Data File: Not Found ------------------------ Trying : E:/FULL_20180329_06SV09RJ_1_1.RMAN From : DISK Data File: Not Found ------------------------ Trying : E:/FULL_20180329_07SV09TP_1_1.RMAN From : DISK Data File : Found ------------------------ RESTORED Data File To: D:\oradata\orcl\3.dbf Attempting To Restore :D:\oradata\orcl\4.dbf ------------------------ Trying : E:/FULL_20180329_01SV08N2_1_1.RMAN From : DISK Data File: Not Found ------------------------ Trying : E:/FULL_20180329_02SV0918_1_1.RMAN From : DISK Data File: Not Found ------------------------ Trying : E:/FULL_20180329_03SV092B_1_1.RMAN From : DISK Data File: Not Found ------------------------ Trying : E:/FULL_20180329_05SV09QQ_1_1.RMAN From : DISK Data File: Not Found ------------------------ Trying : E:/FULL_20180329_06SV09RJ_1_1.RMAN From : DISK Data File : Found ------------------------ RESTORED Data File To: D:\oradata\orcl\4.dbf Attempting To Restore :D:\oradata\orcl\5.dbf ------------------------ Trying : E:/FULL_20180329_01SV08N2_1_1.RMAN From : DISK Data File : Found ------------------------ RESTORED Data File To: D:\oradata\orcl\5.dbf Attempting To Restore :D:\oradata\orcl\6.dbf ------------------------ Trying : E:/FULL_20180329_01SV08N2_1_1.RMAN From : DISK Data File: Not Found ------------------------ Trying : E:/FULL_20180329_02SV0918_1_1.RMAN From : DISK Data File: Not Found ------------------------ Trying : E:/FULL_20180329_03SV092B_1_1.RMAN From : DISK Data File : Found ------------------------ RESTORED Data File To: D:\oradata\orcl\6.dbf PL/SQL 过程已成功完成。
重建控制文件并open数据库
SQL> CREATE CONTROLFILE REUSE DATABASE "ORCL" RESETLOGS NOARCHIVELOG 2 MAXLOGFILES 50 3 MAXLOGMEMBERS 5 4 MAXDATAFILES 100 5 MAXINSTANCES 1 6 MAXLOGHISTORY 226 7 LOGFILE 8 GROUP 1 'D:\oradata\orcl\redo01.log' SIZE 100M, 9 GROUP 2 'D:\oradata\orcl\redo02.log' SIZE 100M, 10 GROUP 3 'D:\oradata\orcl\redo03.log' SIZE 100M 11 DATAFILE 12 'D:\oradata\orcl\1.dbf', 13 'D:\oradata\orcl\2.dbf', 14 'D:\oradata\orcl\3.dbf', 15 'D:\oradata\orcl\4.dbf', 16 'D:\oradata\orcl\5.dbf', 17 'D:\oradata\orcl\6.dbf' 18 CHARACTER SET ZHS16GBK 19 ; 控制文件已创建。 SQL> alter database open resetlogs; 数据库已更改。
这里本质就是通过oracle内部包,直接还原数据文件,这个模拟的是基础的情况,在实际的恢复中,由于只有数据文件的备份,可能文件不一致,还需要通过一些非常规方法对数据库进行强制打开
发表在 rman备份/恢复
评论关闭


加我微信(17813235971)
加我QQ(107644445)

