标签云
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,666)
- DB2 (22)
- MySQL (73)
- Oracle (1,528)
- Data Guard (51)
- EXADATA (8)
- GoldenGate (21)
- ORA-xxxxx (159)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (14)
- ORACLE 21C (3)
- Oracle 23ai (7)
- Oracle ASM (65)
- Oracle Bug (8)
- Oracle RAC (52)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (559)
- Oracle安装升级 (90)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (77)
- 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)
-
最近发表
- 清空redo,导致ORA-27048: skgfifi: file header information is invalid
- A_H_README_TO_RECOVER勒索恢复
- 通过alert日志分析客户自行对一个数据库恢复的来龙去脉和点评
- ORA-12514: TNS: 监听进程不能解析在连接描述符中给出的SERVICE_NAME
- ORA-01092 ORA-00604 ORA-01558故障处理
- ORA-65088: database open should be retried
- Oracle 19c异常恢复—ORA-01209/ORA-65088
- ORA-600 16703故障再现
- 数据库启动报ORA-27102 OSD-00026 O/S-Error: (OS 1455)
- .[metro777@cock.li].Elbie勒索病毒加密数据库恢复
- 应用连接错误,初始化mysql数据库恢复
- RAC默认服务配置优先节点
- Oracle 19c RAC 替换私网操作
- 监听报TNS-12541 TNS-12560 TNS-00511错误
- drop tablespace xxx including contents恢复
- Linux 8 修改网卡名称
- 如何修改集群的公网信息(包括 VIP) (Doc ID 1674442.1)
- 如何在 oracle 集群环境下修改私网信息 (Doc ID 2103317.1)
- ORA-600 [kcvfdb_pdb_set_clean_scn: cleanckpt] 相关bug
- ORA-600 krhpfh_03-1210故障处理
标签归档:ORA-01113
一键恢复ORA-01113 ORA-01110—Oracle Recovery Tools
一般由于归档日志丢失或者非归档库可能在数据库启动的时候出现类似如下错误
SQL> startup ORACLE instance started. Total System Global Area 2137886720 bytes Fixed Size 2282960 bytes Variable Size 587205168 bytes Database Buffers 1543503872 bytes Redo Buffers 4894720 bytes Database mounted. ORA-01113: file 1 needs media recovery ORA-01110: data file 1: 'F:\ORADATA\XIFENFEI\SYSTEM01.DBF'
主要是由于数据文件不一致需要比较老的日志,但是日志不存在从而导致该问题
以前是通过一系列的方法强制open库,以前类似文章:
12c ORA-01113 ORA-01110 恢复
分享一次ORA-01113 ORA-01110故障处理过程
现在可以通过Oracle Recovery Tools工具一键解决
尝试open数据库
SQL> recover database; Media recovery complete. SQL> alter database open; Database altered.
软件下载:OraRecovery下载
使用说明:使用说明
12c ORA-01113 ORA-01110 恢复
使用Oracle Recovery Tools 工具实现一键解决此类问题,参考:一键恢复ORA-01113 ORA-01110—Oracle Recovery Tools
数据库版本
数据库启动报错
Completed: ALTER DATABASE MOUNT Thu Aug 17 12:34:52 2017 alter database open Thu Aug 17 12:34:52 2017 Ping without log force is disabled . Thu Aug 17 12:34:52 2017 Errors in file D:\APP\ORACLE\diag\rdbms\XIFENFEI\XIFENFEI\trace\XIFENFEI_ora_5960.trc: ORA-01113: 文件 5 需要介质恢复 ORA-01110: 数据文件 5: 'D:\APP\ORACLE\ORADATA\XIFENFEI\DATAFILE\O1_MF_UNDOTBS1_DN9MQJFK_.DBF' ORA-1113 signalled during: alter database open
客户尝试恢复
SQL> startup mount; ORACLE 例程已经启动。 Total System Global Area 1.0301E+10 bytes Fixed Size 3842760 bytes Variable Size 1778388280 bytes Database Buffers 8489271296 bytes Redo Buffers 29708288 bytes 数据库装载完毕。 SQL> alter database open; alter database open * 第 1 行出现错误: ORA-01113: 文件 5 需要介质恢复 ORA-01110: 数据文件 5: 'D:\APP\ORACLE\ORADATA\XIFENFEI\DATAFILE\O1_MF_UNDOTBS1_DN9MQJFK_.DBF' SQL> alter database datafile 5 offline drop; 数据库已更改。 SQL> alter database open; alter database open * 第 1 行出现错误: ORA-01113: 文件 6 需要介质恢复 ORA-01110: 数据文件 6: 'D:\APP\ORACLE\ORADATA\XIFENFEI\DATAFILE\O1_MF_USERS_DN9MQH75_.DBF' SQL> recover datafile 6; ORA-00283: 恢复会话因错误而取消 ORA-00322: 日志 3 (用于线程 1) 不是最新副本 ORA-00312: 联机日志 3 线程 1: 'D:\APP\ORACLE\FAST_RECOVERY_AREA\XIFENFEI\ONLINELOG\O1_MF_3_DN9MV6DW_.LOG' ORA-00322: 日志 3 (用于线程 1) 不是最新副本 ORA-00312: 联机日志 3 线程 1: 'D:\APP\ORACLE\ORADATA\XIFENFEI\ONLINELOG\O1_MF_3_DN9MV6BX_.LOG'
使用Oracle Database Recovery Check检测结果
尝试恢复
SQL> recover database; ORA-00283: recovery session canceled due to errors ORA-00322: log 3 of thread 1 is not current copy ORA-00312: online log 3 thread 1: 'D:\APP\ORACLE\FAST_RECOVERY_AREA\XIFENFEI\ONLINELOG\O1_MF_3_DN9MV6DW_.LOG' ORA-00322: log 3 of thread 1 is not current copy ORA-00312: online log 3 thread 1: 'D:\APP\ORACLE\ORADATA\XIFENFEI\ONLINELOG\O1_MF_3_DN9MV6BX_.LOG' SQL> recover database until cancel ORA-00279: 更改 9843709 (在 08/17/2017 07:04:02 生成) 对于线程 1 是必需的 ORA-00289: 建议: D:\APP\ORACLE\FAST_RECOVERY_AREA\XIFENFEI\ARCHIVELOG\2017_08_17\O1_MF_1_717_%U_.ARC ORA-00280: 更改 9843709 (用于线程 1) 在序列 #717 中 指定日志: {<RET>=suggested | filename | AUTO | CANCEL} D:\APP\ORACLE\FAST_RECOVERY_AREA\XIFENFEI\ONLINELOG\O1_MF_2_DN9MV69G_.LOG ORA-00310: archived log contains sequence 716; sequence 717 required ORA-00334: archived log: 'D:\APP\ORACLE\FAST_RECOVERY_AREA\XIFENFEI\ONLINELOG\O1_MF_2_DN9MV69G_.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: 'D:\APP\ORACLE\ORADATA\XIFENFEI\DATAFILE\O1_MF_SYSTEM_DN9MN5OT_.DBF' SQL> recover database until cancel ORA-00279: 更改 9843709 (在 08/17/2017 07:04:02 生成) 对于线程 1 是必需的 ORA-00289: 建议: D:\APP\ORACLE\FAST_RECOVERY_AREA\XIFENFEI\ARCHIVELOG\2017_08_17\O1_MF_1_717_%U_.AR C ORA-00280: 更改 9843709 (用于线程 1) 在序列 #717 中 指定日志: {<RET>=suggested | filename | AUTO | CANCEL} D:\APP\ORACLE\FAST_RECOVERY_AREA\XIFENFEI\ONLINELOG\O1_MF_1_DN9MV661_.LOG ORA-00310: archived log contains sequence 715; sequence 717 required ORA-00334: archived log: 'D:\APP\ORACLE\FAST_RECOVERY_AREA\XIFENFEI\ONLINELOG\O1_MF_1_DN9MV661_.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: 'D:\APP\ORACLE\ORADATA\XIFENFEI\DATAFILE\O1_MF_SYSTEM_DN9MN5OT_.DBF' SQL> recover database until cancel ORA-00279: 更改 9843709 (在 08/17/2017 07:04:02 生成) 对于线程 1 是必需的 ORA-00289: 建议: D:\APP\ORACLE\FAST_RECOVERY_AREA\XIFENFEI\ARCHIVELOG\2017_08_17\O1_MF_1_717_%U_.ARC ORA-00280: 更改 9843709 (用于线程 1) 在序列 #717 中 指定日志: {<RET>=suggested | filename | AUTO | CANCEL} D:\APP\ORACLE\FAST_RECOVERY_AREA\XIFENFEI\ONLINELOG\O1_MF_3_DN9MV6DW_.LOG 已应用的日志。 完成介质恢复。 SQL> alter database datafile 5 online; 数据库已更改。 SQL> recover database until cancel; ORA-00279: 更改 9843709 (在 08/17/2017 07:04:02 生成) 对于线程 1 是必需的 ORA-00289: 建议: D:\APP\ORACLE\FAST_RECOVERY_AREA\XIFENFEI\ARCHIVELOG\2017_08_17\O1_MF_1_717_%U_.AR C ORA-00280: 更改 9843709 (用于线程 1) 在序列 #717 中 指定日志: {<RET>=suggested | filename | AUTO | CANCEL} D:\APP\ORACLE\FAST_RECOVERY_AREA\XIFENFEI\ONLINELOG\O1_MF_3_DN9MV6DW_.LOG ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below ORA-01152: file 1 was not restored from a sufficiently old backup ORA-01110: data file 1: 'D:\APP\ORACLE\ORADATA\XIFENFEI\DATAFILE\O1_MF_SYSTEM_DN9MN5OT_.DBF' ORA-01112: 未启动介质恢复 SQL> recover datafile 5; ORA-00283: 恢复会话因错误而取消 ORA-00264: 不要求恢复 SQL> SELECT status, 2 checkpoint_change#, 3 checkpoint_time,FUZZY, 4 count(*) ROW_NUM 5 FROM v$datafile_header 6 GROUP BY status, checkpoint_change#, checkpoint_time,fuzzy 7 ORDER BY status, checkpoint_change#, checkpoint_time; STATUS CHECKPOINT_CHANGE# CHECKPOINT_TIME FUZ ROW_NUM ------- ------------------ ------------------- --- ---------------- ONLINE 9850826 2017-08-17 08:15:45 NO 1 ONLINE 9857411 2017-08-17 08:15:45 NO 7 ONLINE 9857411 2017-08-17 09:00:48 NO 2 SQL> set numw 16 SQL> SELECT status, 2 checkpoint_change#, 3 checkpoint_time,last_change#, 4 count(*) ROW_NUM 5 FROM v$datafile 6 GROUP BY status, checkpoint_change#, checkpoint_time,last_change# 7 ORDER BY status, checkpoint_change#, checkpoint_time; STATUS CHECKPOINT_CHANGE# CHECKPOINT_TIME LAST_CHANGE# ROW_NUM ------- ------------------ ------------------- ---------------- ---------------- ONLINE 9857411 2017-08-17 09:00:48 9850826 1 ONLINE 9857411 2017-08-17 09:00:48 9857411 8 SYSTEM 9857411 2017-08-17 09:00:48 9857411 1 SQL> alter database open resetlogs; alter database open resetlogs * 第 1 行出现错误: ORA-01152: 文件 1 没有从过旧的备份中还原 ORA-01110: 数据文件 1: 'D:\APP\ORACLE\ORADATA\XIFENFEI\DATAFILE\O1_MF_SYSTEM_DN9MN5OT_.DBF' [/shell] 这里比较明显,由于controlfile的scn 大于db的scn,从而出现了ORA-01152的错误,重试重建控制文件 <br> <strong>重建控制文件</strong> 1 SQL> alter database backup controlfile to trace as 'd:\app\ctl.txt'; 数据库已更改。 SQL> startup nomount; ORACLE 例程已经启动。 Total System Global Area 10301210624 bytes Fixed Size 3842760 bytes Variable Size 1778388280 bytes Database Buffers 8489271296 bytes Redo Buffers 29708288 bytes SQL> CREATE CONTROLFILE REUSE DATABASE "XIFENFEI" NORESETLOGS NOARCHIVELOG 2 MAXLOGFILES 16 3 MAXLOGMEMBERS 3 4 MAXDATAFILES 100 5 MAXINSTANCES 8 6 MAXLOGHISTORY 292 7 LOGFILE 8 GROUP 1 ( 9 'D:\APP\ORACLE\ORADATA\XIFENFEI\ONLINELOG\O1_MF_1_DN9MV652_.LOG', 10 'D:\APP\ORACLE\FAST_RECOVERY_AREA\XIFENFEI\ONLINELOG\O1_MF_1_DN9MV661_.LO G' 11 ) SIZE 50M BLOCKSIZE 512, 12 GROUP 2 ( 13 'D:\APP\ORACLE\ORADATA\XIFENFEI\ONLINELOG\O1_MF_2_DN9MV68H_.LOG', 14 'D:\APP\ORACLE\FAST_RECOVERY_AREA\XIFENFEI\ONLINELOG\O1_MF_2_DN9MV69G_.LO G' 15 ) SIZE 50M BLOCKSIZE 512, 16 GROUP 3 ( 17 'D:\APP\ORACLE\ORADATA\XIFENFEI\ONLINELOG\O1_MF_3_DN9MV6BX_.LOG', 18 'D:\APP\ORACLE\FAST_RECOVERY_AREA\XIFENFEI\ONLINELOG\O1_MF_3_DN9MV6DW_.LO G' 19 ) SIZE 50M BLOCKSIZE 512 20 DATAFILE 21 'D:\APP\ORACLE\ORADATA\XIFENFEI\DATAFILE\O1_MF_SYSTEM_DN9MN5OT_.DBF', 22 'D:\APP\ORACLE\ORADATA\XIFENFEI\DATAFILE\O1_MF_SYSAUX_DN9MK6B3_.DBF', 23 'D:\APP\ORACLE\ORADATA\XIFENFEI\DATAFILE\O1_MF_UNDOTBS1_DN9MQJFK_.DBF', 24 'D:\APP\ORACLE\ORADATA\XIFENFEI\DATAFILE\O1_MF_USERS_DN9MQH75_.DBF', 25 'D:\APP\ORACLE\PRODUCT\12.1.0\DBHOME_1\DATABASE\XIFENFEIFILE06', 26 'D:\APP\ORACLE\PRODUCT\12.1.0\DBHOME_1\DATABASE\XIFENFEIFILE05', 27 'D:\APP\ORACLE\PRODUCT\12.1.0\DBHOME_1\DATABASE\XIFENFEIFILE04', 28 'D:\APP\ORACLE\PRODUCT\12.1.0\DBHOME_1\DATABASE\XIFENFEIFILE03', 29 'D:\APP\ORACLE\PRODUCT\12.1.0\DBHOME_1\DATABASE\XIFENFEIFILE02', 30 'D:\APP\ORACLE\PRODUCT\12.1.0\DBHOME_1\DATABASE\XIFENFEIFILE01' 31 CHARACTER SET ZHS16GBK 32 ; 控制文件已创建。
尝试恢复
SQL> recover database; 完成介质恢复。 SQL> alter database open; alter database open * 第 1 行出现错误: ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00600: internal error code, arguments: [4194], [41], [36], [], [], [], [], [], [], [], [], [] 进程 ID: 2864 会话 ID: 62 序列号: 54236
本来到这一步,错误比较明显,undo异常,这类直接对undo进行处理即可,可是运气不太好
异常crash之后redo损坏
SQL> startup pfile='d:/app/pfile.txt' ORACLE 例程已经启动。 Total System Global Area 1.0301E+10 bytes Fixed Size 3842760 bytes Variable Size 1778388280 bytes Database Buffers 8489271296 bytes Redo Buffers 29708288 bytes 数据库装载完毕。 ORA-00354: 损坏重做日志块标头 ORA-00353: 日志损坏接近块 60 更改 23924938639111 时间 08/17/2017 21:36:16 ORA-00312: 联机日志 1 线程 1: 'D:\APP\ORACLE\FAST_RECOVERY_AREA\XIFENFEI\ONLINELOG\O1_MF_1_DN9MV661_.LOG' ORA-00312: 联机日志 1 线程 1: 'D:\APP\ORACLE\ORADATA\XIFENFEI\ONLINELOG\O1_MF_1_DN9MV652_.LOG' SQL> recover database; ORA-00283: recovery session canceled due to errors ORA-00354: corrupt redo log block header ORA-00353: log corruption near block 60 change 23924938639111 time 08/17/201721:36:16 ORA-00312: online log 1 thread 1: 'D:\APP\ORACLE\FAST_RECOVERY_AREA\XIFENFEI\ONLINELOG\O1_MF_1_DN9MV661_.LOG' ORA-00312: online log 1 thread 1: 'D:\APP\ORACLE\ORADATA\XIFENFEI\ONLINELOG\O1_MF_1_DN9MV652_.LOG' SQL> recover database until cancel; ORA-00279: 更改 10050832 (在 08/17/2017 21:36:13 生成) 对于线程 1 是必需的 ORA-00289: 建议: D:\APP\ORACLE\FAST_RECOVERY_AREA\XIFENFEI\ARCHIVELOG\2017_08_17\O1_MF_1_718_%U_.ARC ORA-00280: 更改 10050832 (用于线程 1) 在序列 #718 中 指定日志: {<RET>=suggested | filename | AUTO | CANCEL} D:\APP\ORACLE\FAST_RECOVERY_AREA\XIFENFEI\ONLINELOG\O1_MF_1_DN9MV661_.LOG ORA-00283: recovery session canceled due to errors ORA-00354: corrupt redo log block header ORA-00353: log corruption near block 60 change 23924938639111 time 08/17/2017 21:36:16 ORA-00334: archived log: 'D:\APP\ORACLE\FAST_RECOVERY_AREA\XIFENFEI\ONLINELOG\O1_MF_1_DN9MV661_.LOG'
到这一步,只能通过屏蔽oracle 事务前滚,强制拉库恢复。
SQL> startup pfile='d:/app/pfile.txt' mount; ORACLE 例程已经启动。 Total System Global Area 1.0301E+10 bytes Fixed Size 3842760 bytes Variable Size 1778388280 bytes Database Buffers 8489271296 bytes Redo Buffers 29708288 bytes 数据库装载完毕。 SQL> recover database until cancel; ORA-00279: 更改 10050832 (在 08/17/2017 21:36:13 生成) 对于线程 1 是必需的 ORA-00289: 建议: D:\APP\ORACLE\FAST_RECOVERY_AREA\XIFENFEI\ARCHIVELOG\2017_08_17\O 1_MF_1_718_%U_.ARC ORA-00280: 更改 10050832 (用于线程 1) 在序列 #718 中 指定日志: {<RET>=suggested | filename | AUTO | CANCEL} cancel 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: 'D:\APP\ORACLE\ORADATA\XIFENFEI\DATAFILE\O1_MF_SYSTEM_DN9M N5OT_.DBF' ORA-01112: 未启动介质恢复 SQL> alter database open resetlogs; 数据库已更改。
_ALLOW_RESETLOGS_CORRUPTION
我相信_ALLOW_RESETLOGS_CORRUPTION 这个参数一定很多人都熟悉,是redo异常恢复的杀手锏之一,以下文章是来自官方的解释
DB_Parameter _ALLOW_RESETLOGS_CORRUPTION ======================================== This documentation has been prepared avoiding the mention of the complex structures from the code and to simply give an insight to the 'damage it could cause'. The usage of this parameter leads to an in-consistent Database with no other alternative but to rebuild the complete Database. This parameter could be used when we realize that there are no stardard options available and are convinced that the customer understands the implications of using the Oracle's secret parameter. The factors to be considered are ;-- 1. Customer does not have a good backup. 2. A lot of time and money has been invested after the last good backup and there is no possibility for reproduction of the lost data. 3. The customer has to be ready to export the full database and import it back after creating a new one. 4. There is no 100% guarantee that by using this parameter the database would come up. 5. Oracle does not support the database after using this parameter for recovery. 6. ALL OPTIONS including the ones mentioned in the action part of the error message have been tried. By setting _ALLOW_RESETLOGS_CORRUPTION=TRUE, certain consistency checks are SKIPPED during database open stage. This basically means it does not check the datafile headers as to what the status was before the shutdown and how it was shutdown. The following cases mention few of the checks that were skipped. Case-I ------ Verification that the datafile present has not been restored from a BACKUP taken before the database was opened successfully by using RESETLOGS. ORA-01190: control file or data file %s is from before the last RESETLOGS Cause: Attempting to use a data file when the log reset information in the file does not match the control file. Either the data file or the control file is a backup that was made before the most recent ALTER DATABASE OPEN RESETLOGS. Action: Restore file from a more recent backup. Case-II ------- Verification that the status bit of the datafile is not in a FUZZY state. The datafile could be in this state due to the database going down when the - Datafile was on-line and open - Datafile was not closed cleanly (maybe due to OS). ORA-01194: file %s needs more recovery to be consistent Cause: An incomplete recover session was started, but an insufficient number of logs were applied to make the file consistent. The reported file was not closed cleanly when it was last opened by the database. It must be recovered to a time when it was not being updated. The most likely cause of this error is forgetting to restore the file from a backup before doing incomplete recovery. Action: Either apply more logs until the file is consistent or restore the file from an older backup and repeat recovery. Case-III -------- Verification that the COMPLETE recover strategies have been applied for recovering the datafile and not any of the INCOMPLETE recovery options. Basically because the complete recovery is one in which we even apply the ON-LINE redo log files and open the DB without reseting the logs. ORA-01113: file '%s' needs media recovery starting at log sequence # %s Cause: An attempt was made to open a database file that is in need of media recovery. Action: First apply media recovery to the file. Case-IV ------- Verification that the datafile has been recovered through an END BACKUP if the control file indicates that it was in backup mode. This is useful when the DB has crashed while in hot backup mode and we lost all log files in DB version's less than V7.2. ORA-01195: on-line backup of file %s needs more recovery to be consistent" Cause: An incomplete recovery session was started, but an insufficient number of logs were applied to make the file consistent. The reported file is an on-line backup which must be recovered to the time the backup ended. Action: Either apply more logs until the file is consistent or resotre the database files from an older backup and repeat recovery. In version 7.2, we could simply issue the ALTER DATABASE DATAFILE xxxx END BACKUP statement and proceed with the recovery. But again to issue this statement, we need to have the ON-LINE redo logs or else we still are forced to use this parameter. Case-V ------ Verification that the data file status is not still in (0x10) MEDIA recovery FUZZY. When recovery is started, a flag is set in the datafile header status flag to indicate that the file is presently in media recovery. This is reset when recovery is completed and at times when it has not been reset we are forced to use this paramter. ORA-01196: file %s is inconsistent due to a failed media recovery session Cause: The file was being recovered but the recovery did not terminate normally. This left the file in an inconsistent state. No more recovery was successfully completed on this file. Action: Either apply more logs until the file is consistent or restore the backup again and repeat recovery. Case-VI ------- Verification that the datafile has been restored form a proper backup to correspond with the log files. This situation could happen when we have decided that the data file is invalid since its SCN is ahead of the last applied logs SCN but it has not failed on one of the ABOVE CHECKS. ORA-01152: file '%s' was not restored from a sufficientluy old backup" Cause: A manual recovery session was started, but an insufficient number of logs were applied to make the database consistent. This file is still in the future of the last log applied. Note that this mistake can not always be caught. Action: Either apply more logs until the database is consistent or restore the database file from an older backup and repeat recovery.
使用_ALLOW_RESETLOGS_CORRUPTION 参数需谨慎,因为该参数可能导致数据库逻辑不一致,甚至可能把本来很简单的一个恢复弄的非常复杂甚至不可恢复的后果,建议在oracle support支持下使用.另外使用该参数resetlogs库之后,强烈建议通过逻辑方式重建库
发表在 Oracle备份恢复
标签为 ORA-01113, ORA-01152, ORA-01190, ORA-01194, ORA-01195, ORA-01196, _ALLOW_RESETLOGS_CORRUPTION
评论关闭