标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-00742 ORA-01110 ORA-01555 ORA-01578 ORA-01595 ORA-08103 ORA-600 2131 ORA-600 2662 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)
- 操作系统 (103)
- 数据库 (1,764)
- DB2 (22)
- MySQL (77)
- Oracle (1,605)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (166)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (69)
- Oracle Bug (8)
- Oracle RAC (54)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (588)
- Oracle安装升级 (97)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (86)
- PostgreSQL (30)
- pdu工具 (6)
- PostgreSQL恢复 (9)
- SQL Server (32)
- SQL Server恢复 (13)
- TimesTen (7)
- 达梦数据库 (3)
- 达梦恢复 (1)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (39)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (22)
-
最近发表
- 文件系统格式化MySQL数据库恢复
- .sstop勒索加密数据库恢复
- 解决一次硬件恢复之后数据文件0kb的故障恢复case
- Error in invoking target ‘libasmclntsh19.ohso libasmperl19.ohso client_sharedlib’问题处理
- ORA-01171: datafile N going offline due to error advancing checkpoint
- linux环境oracle数据库被文件系统勒索加密为.babyk扩展名溯源
- ORA-600 ksvworkmsgalloc: bad reaper
- ORA-600 krccfl_chunk故障处理
- Oracle Recovery Tools恢复案例总结—202505
- ORA-600 kddummy_blkchk 数据库循环重启
- 记录一次asm disk加入到vg通过恢复直接open库的案例
- CHECKDB 发现了 N 个分配错误和 M 个一致性错误
- 达梦数据库dm.ctl文件异常恢复
- Oracle Recovery Tools修复ORA-00742、ORA-600 ktbair2: illegal inheritance故障
- 可能是 tempdb 空间用尽或某个系统表不一致故障处理
- 11.2.0.4库中遇到ORA-600 kcratr_nab_less_than_odr报错
- [MY-013183] [InnoDB] Assertion failure故障处理
- Oracle 19c 202504补丁(RUs+OJVM)-19.27
- Oracle Recovery Tools修复ORA-600 6101/kdxlin:psno out of range故障
- pdu完美支持金仓数据库恢复(KingbaseES)
年归档:2022
win文件系统损坏oracle恢复
有客户反馈数据文件无法拷贝也无法正常操作,通过查看系统日志发现ntfs文件系统异常
在文件系统中看数据文件状态正常,但是拷贝文件报错

通过恢复工具查看文件发现文件大小为0kb

通过文件系统层面扫描,然后进行相关数据恢复,依旧报错(恢复文件大小错误)

经过进一步人工修复文件系统目录,实现数据完整恢复,实现数据0丢失

基于这种情况如果通过文件系统层面无法恢复,对于此类oracle block级别进行处理,类似以前恢复case:
dbca删除库和rm删库恢复
文件系统损坏导致数据文件异常恢复
Oracle 数据文件大小为0kb或者文件丢失恢复
asm disk 磁盘部分被清空恢复
由于未知原因导致磁盘组的一个磁盘前面1G被置空(data磁盘组一共5个1T磁盘,第一个盘未知原因置空了1G数据)
[root@oradb1 ~]#kfed read /dev/mapper/asm-disk1 kfbh.endian: 0 ; 0x000: 0x00 kfbh.hard: 0 ; 0x001: 0x00 kfbh.type: 0 ; 0x002: KFBTYP_INVALID kfbh.datfmt: 0 ; 0x003: 0x00 kfbh.block.blk: 0 ; 0x004: blk=0 kfbh.block.obj: 0 ; 0x008: file=0 kfbh.check: 0 ; 0x00c: 0x00000000 kfbh.fcn.base: 0 ; 0x010: 0x00000000 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 7F539088C400 00000000 00000000 00000000 00000000 [................] Repeat 255 times KFED-00322: Invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type][][0] ………… [root@oradb1 ~]#kfed read /dev/mapper/asm-disk1 aun=999 kfbh.endian: 0 ; 0x000: 0x00 kfbh.hard: 0 ; 0x001: 0x00 kfbh.type: 0 ; 0x002: KFBTYP_INVALID kfbh.datfmt: 0 ; 0x003: 0x00 kfbh.block.blk: 0 ; 0x004: blk=0 kfbh.block.obj: 0 ; 0x008: file=0 kfbh.check: 0 ; 0x00c: 0x00000000 kfbh.fcn.base: 0 ; 0x010: 0x00000000 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 7F8FEB795400 00000000 00000000 00000000 00000000 [................] Repeat 255 times KFED-00322: Invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type][][0]
通过分析disk 1和disk 2的前面1001MB数据,以及asm的数据分布特性,可以确认丢失的1000MB数据为39号文件的数据(和客户当时这个库是通过rman还原过来的操作有关系)
对于这样的情况,通过底层扫描,可以很好的恢复数据,参考以前类似文章
asm disk被加入vg恢复
asm disk header 彻底损坏恢复
asm磁盘dd破坏恢复
通过底层恢复,恢复结果如下

dbv检查数据文件

然后把数据库恢复出来数据文件中的数据恢复到新库中,至此完成该case恢复
File #xxx found in data dictionary but not in controlfile. Creating OFFLINE file ‘MISSING00XXX’ in the controlfile
接手客户的库,已经被强制resetlogs 报ORA-600 2662错误
Sat Mar 19 20:07:48 2022 alter database open resetlogs RESETLOGS is being done without consistancy checks. This may result in a corrupted database. The database should be recreated. RESETLOGS after incomplete recovery UNTIL CHANGE 26228222518 Clearing online redo logfile 1 /u2/oradb/oradata/xff/redo01.log Clearing online log 1 of thread 1 sequence number 0 Clearing online redo logfile 1 complete Online log /u2/oradb/oradata/xff/redo01.log: Thread 1 Group 1 was previously cleared Online log /u2/oradb/oradata/xff/redo02.log: Thread 1 Group 2 was previously cleared Online log /u2/oradb/oradata/xff/redo03.log: Thread 1 Group 3 was previously cleared Sat Mar 19 20:08:02 2022 Setting recovery target incarnation to 2 Sat Mar 19 20:08:07 2022 Assigning activation ID 2327373166 (0x8ab8e56e) Thread 1 opened at log sequence 1 Current log# 1 seq# 1 mem# 0: /u2/oradb/oradata/xff/redo01.log Successful open of redo thread 1 Sat Mar 19 20:08:14 2022 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Sat Mar 19 20:08:14 2022 SMON: enabling cache recovery ORA-00600: internal error code, arguments: [2662], [6], [458447781], [6], [458448180], [12583056] ORA-00600: internal error code, arguments: [2662], [6], [458447780], [6], [458448180], [12583056] ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00600: internal error code, arguments: [2662], [6], [458447778], [6], [458448180], [12583056] Incident details in: /u2/oradb/diag/rdbms/xifenfei/xifenfei/incident/incdir_1181122/xifenfei_ora_19893_i1181122.trc Errors in file /u2/oradb/diag/rdbms/xifenfei/xifenfei/incident/incdir_1181122/xifenfei_ora_19893_i1181122.trc: ORA-00603: ORACLE server session terminated by fatal error ORA-00600: internal error code, arguments: [2662], [6], [458447781], [6], [458448180], [12583056] ORA-00600: internal error code, arguments: [2662], [6], [458447780], [6], [458448180], [12583056] ORA-01092: ORACLE instance terminated. Disconnection forced ORA-00600: internal error code, arguments: [2662], [6], [458447778], [6], [458448180], [12583056]
接手之后尝试获取创建控制文件脚本,报ORA-16433
Mon Mar 21 15:20:37 2022 alter database backup controlfile to trace as '/tmp/ctl' ORA-16433 signalled during: alter database backup controlfile to trace as '/tmp/ctl'...
经过一些处理之后resetlogs 成功,但是悲剧产生了(客户之前自己重建过ctl,遗漏大量数据文件,然后我参照客户的ctl进行处理)使得新的ctl中遗漏的很多数据文件,库被resetlogs打开,导致部分文件的resetlog scn不一致,另外数据库还有ORA-600 4137错误需要处理
Mon Mar 21 15:35:01 2022 alter database open resetlogs RESETLOGS is being done without consistancy checks. This may result in a corrupted database. The database should be recreated. RESETLOGS after incomplete recovery UNTIL CHANGE 26228222522 Clearing online redo logfile 1 /u2/oradb/oradata/xff/redo01.log Clearing online redo logfile 1 complete Resetting resetlogs activation ID 2327373166 (0x8ab8e56e) Errors in file /u2/oradb/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_ora_4029.trc: ORA-00367: checksum error in log file header ORA-00322: log 1 of thread 1 is not current copy ORA-00312: online log 1 thread 1: '/u2/oradb/oradata/xff/redo01.log' Errors in file /u2/oradb/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_ora_4029.trc: ORA-00367: checksum error in log file header ORA-00322: log 2 of thread 1 is not current copy ORA-00312: online log 2 thread 1: '/u2/oradb/oradata/xff/redo02.log' Errors in file /u2/oradb/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_ora_4029.trc: ORA-00367: checksum error in log file header ORA-00322: log 3 of thread 1 is not current copy ORA-00312: online log 3 thread 1: '/u2/oradb/oradata/xff/redo03.log' Mon Mar 21 15:35:16 2022 Setting recovery target incarnation to 2 Mon Mar 21 15:35:23 2022 Assigning activation ID 2327514749 (0x8abb0e7d) Thread 1 opened at log sequence 1 Current log# 1 seq# 1 mem# 0: /u2/oradb/oradata/xff/redo01.log Successful open of redo thread 1 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Mon Mar 21 15:35:30 2022 SMON: enabling cache recovery Undo initialization finished serial:0 start:191905344 end:191905754 diff:410 (4 seconds) Dictionary check beginning Tablespace 'TEMP' #3 found in data dictionary, but not in the controlfile. Adding to controlfile. Tablespace 'DS_POS' #9 found in data dictionary, but not in the controlfile. Adding to controlfile. Mon Mar 21 15:36:00 2022 File #498 found in data dictionary but not in controlfile. Creating OFFLINE file 'MISSING00498' in the controlfile. ………… File #567 found in data dictionary but not in controlfile. Creating OFFLINE file 'MISSING00567' in the controlfile. This file can no longer be recovered so it must be dropped. Dictionary check complete Verifying file header compatibility for 11g tablespace encryption.. Verifying 11g file header compatibility for tablespace encryption completed Mon Mar 21 15:36:08 2022 SMON: enabling tx recovery ********************************************************************* WARNING: The following temporary tablespaces contain no files. 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 Errors in file /u2/oradb/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_smon_4017.trc (incident=1325274): ORA-00600: internal error code, arguments: [4137], [28.27.4413199], [0], [0], [], [], [], [], [], [], [], [] Incident details in: /u2/oradb/diag/rdbms/xifenfei/xifenfei/incident/incdir_1325274/xifenfei_smon_4017_i1325274.trc Use ADRCI or Support Workbench to package the incident. Mon Mar 21 15:36:10 2022 db_recovery_file_dest_size of 49770 MB is 0.00% used. This is a user-specified limit on the amount of space that will be used by this database for recovery-related files, and does not reflect the amount of space available in the underlying filesystem or ASM diskgroup. Mon Mar 21 15:36:10 2022 Starting background process CJQ0 Mon Mar 21 15:36:10 2022 CJQ0 started with pid=27, OS id=4155 Mon Mar 21 15:36:10 2022 Errors in file /u2/oradb/diag/rdbms/xifenfei/xifenfei/trace/xifenfei_smon_4017.trc (incident=1325275): ORA-00600: internal error code, arguments: [4137], [36.20.1072031], [0], [0], [], [], [], [], [], [], [], [] Incident details in: /u2/oradb/diag/rdbms/xifenfei/xifenfei/incident/incdir_1325275/xifenfei_smon_4017_i1325275.trc Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. Mon Mar 21 15:36:10 2022 Completed: alter database open resetlogs
对于类似:File #567 found in data dictionary but not in controlfile.Creating OFFLINE file ‘MISSING00567′ in the controlfile.
错误处理方法:(参照bbed解决ORA-01190
1. 从操作系统中找出来所有遗漏的文件
2. 通过bbed修改文件头信息
3. 重建ctl
4. 重新打开库
Mon Mar 21 16:06:39 2022 alter database open resetlogs RESETLOGS after complete recovery through change 28991030095 Clearing online redo logfile 1 /u2/oradb/oradata/xff/redo01.log Clearing online log 1 of thread 1 sequence number 0 Clearing online redo logfile 1 complete Resetting resetlogs activation ID 2327514749 (0x8abb0e7d) Online log /u2/oradb/oradata/xff/redo01.log: Thread 1 Group 1 was previously cleared Online log /u2/oradb/oradata/xff/redo02.log: Thread 1 Group 2 was previously cleared Online log /u2/oradb/oradata/xff/redo03.log: Thread 1 Group 3 was previously cleared Mon Mar 21 16:06:53 2022 Setting recovery target incarnation to 2 Mon Mar 21 16:07:00 2022 Assigning activation ID 2327541328 (0x8abb7650) Thread 1 opened at log sequence 1 Current log# 1 seq# 1 mem# 0: /u2/oradb/oradata/xff/redo01.log Successful open of redo thread 1 Mon Mar 21 16:07:07 2022 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Mon Mar 21 16:07:07 2022 SMON: enabling cache recovery Undo initialization finished serial:0 start:193802264 end:193802294 diff:30 (0 seconds) Dictionary check beginning Tablespace 'TEMP' #3 found in data dictionary, but not in the controlfile. Adding to controlfile. Mon Mar 21 16:07:38 2022 Dictionary check complete Verifying file header compatibility for 11g tablespace encryption.. Verifying 11g file header compatibility for tablespace encryption completed Mon Mar 21 16:07:38 2022 SMON: enabling tx recovery ********************************************************************* WARNING: The following temporary tablespaces contain no files. 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 ********************************************************** WARNING: Files may exists in db_recovery_file_dest that are not known to the database. Use the RMAN command CATALOG RECOVERY AREA to re-catalog any such files. If files cannot be cataloged, then manually delete them using OS command. One of the following events caused this: 1. A backup controlfile was restored. 2. A standby controlfile was restored. 3. The controlfile was re-created. 4. db_recovery_file_dest had previously been enabled and then disabled. ********************************************************** replication_dependency_tracking turned off (no async multimaster replication found) Starting background process QMNC Mon Mar 21 16:07:40 2022 QMNC started with pid=23, OS id=5476 LOGSTDBY: Validating controlfile with logical metadata LOGSTDBY: Validation complete Mon Mar 21 16:07:41 2022 db_recovery_file_dest_size of 49770 MB is 0.00% used. This is a user-specified limit on the amount of space that will be used by this database for recovery-related files, and does not reflect the amount of space available in the underlying filesystem or ASM diskgroup. Completed: alter database open resetlogs
至此数据库open成功,增加temp文件,然后逻辑迁移库
发表在 Oracle备份恢复
评论关闭