标签云
asm mount asm恢复 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 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-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 勒索恢复 比特币 oracle 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (93)
- 数据库 (1,498)
- DB2 (22)
- MySQL (64)
- Oracle (1,374)
- Data Guard (42)
- EXADATA (7)
- GoldenGate (21)
- ORA-xxxxx (154)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (12)
- ORACLE 21C (3)
- Oracle ASM (63)
- Oracle Bug (7)
- Oracle RAC (44)
- Oracle 安全 (6)
- Oracle 开发 (26)
- Oracle 监听 (26)
- Oracle备份恢复 (478)
- Oracle安装升级 (76)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (71)
- PostgreSQL (13)
- PostgreSQL恢复 (3)
- SQL Server (27)
- SQL Server恢复 (8)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (32)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (15)
-
最近发表
- Oracle 启动后一会儿就挂掉故障处理—ORA-600 17182
- 断电引起的oracle数据库异常恢复
- 等保修改oracle SYS用户名要求的请注意—ORA-00600 kokasgi1
- ORA-07445 opiaba—绑定变量超过65535导致实例crash
- Buffer I/O error on dev故障数据库恢复
- 12.1.0.2最新patch—202301
- 11.2.0.4最新patch信息—202301
- 网卡异常导致数据库实例启动异常
- 最新版oracle dul工具
- 误删除asm disk导致磁盘组无法mount数据库恢复
- .eight加密数据库恢复
- win强制修改盘符导致oracle异常恢复
- 再一例asm disk被误加入vg并且扩容lv恢复
- 重建control遗漏数据文件,reseltogs报ORA-1555错误处理
- InnoDB: Database page corruption on disk or a failed file read of page恢复
- _locked加密数据库恢复
- 部分oracle数据文件被加密完美恢复
- ORA-600 kcbzpbuf_1故障恢复
- Oracle 19c 断电异常恢复
- Oracle Recovery Tools快速恢复ORA-19909
友情链接
分类目录归档:非常规恢复
再一例asm disk被误加入vg并且扩容lv恢复
又一客户把三块asm disk磁盘加入到vg里面(两个节点的root vg中),并且还进行了扩容
加入之后,还对该lv里面进行了expdp数据导出(导出一半失败了,数据库挂了),进而引起了大量的asm磁盘中数据块被文件系统中的expdp导出的dmp复写

通过对损坏磁盘进行kfed分析大概判断损坏到90GB位置

对于这种asm磁盘损坏比较多的情况,常规kfed无法进行修复,只能采用底层基于block层面的扫描恢复,参考:
asm disk header 彻底损坏恢复
通过底层处理恢复出来数据文件:

然后通过可以有的2天之前的备份,结合dul工具,恢复出来最近数据,业务层面进行整合,完成本次数据恢复
有过类似的恢复案例:
asm disk被加入vg恢复
又一例asm disk 加入vg故障
重建control遗漏数据文件,reseltogs报ORA-1555错误处理
又一客户,误删除oracle redo导致数据库无法正常启动,自己尝试重建ctl,结果遗漏部分oracle数据文件并且尝试过resetlogs,导致部分文件resetlogs scn不一致.导致重建ctl失败
Fri Feb 10 12:41:20 2023 CREATE CONTROLFILE REUSE DATABASE "orcl" RESETLOGS NOARCHIVELOG MAXLOGFILES 50 MAXLOGMEMBERS 5 MAXDATAFILES 100 MAXINSTANCES 8 MAXLOGHISTORY 226 LOGFILE GROUP 1 'H:\BaiduNetdisk\couga/redo01.log' SIZE 50M, GROUP 2 'H:\BaiduNetdisk\couga/redo02.log' SIZE 50M, GROUP 3 'H:\BaiduNetdisk\couga/redo03.log' SIZE 50M DATAFILE 'H:\BaiduNetdisk\couga\system01.dbf', 'H:\BaiduNetdisk\couga\cougaerp.DBF', 'H:\BaiduNetdisk\couga\cougajh.DBF', 'H:\BaiduNetdisk\couga\example01.dbf', 'H:\BaiduNetdisk\couga\sysaux01.dbf', 'H:\BaiduNetdisk\couga\undotbs01.dbf', 'H:\BaiduNetdisk\couga\users01.dbf' CHARACTER SET zhs16gbk WARNING: Default Temporary Tablespace not specified in CREATE DATABASE command Default Temporary Tablespace will be necessary for a locally managed database in future release Errors in file c:\app\xff\diag\rdbms\orcl\orcl11\trace\orcl11_ora_4132.trc: ORA-01189: ????????????? RESETLOGS ORA-01110: ???? 6: 'H:\BaiduNetdisk\couga\cougajh.DBF'
通过OraRecovery工具修改相关异常文件头resetlogs scn之后,重建ctl成功
尝试resetlogs 数据库报ORA-00704 ORA-00604 ORA-01555错误

Fri Feb 10 12:46:04 2023 SMON: enabling cache recovery ORA-01555 caused by SQL statement below (SQL ID: 4krwuz0ctqxdt, SCN: 0x0000.09dab82d): select ctime, mtime, stime from obj$ where obj# = :1 Errors in file c:\app\xff\diag\rdbms\orcl\orcl11\trace\orcl11_ora_7088.trc: ORA-00704: 引导程序进程失败 ORA-00704: 引导程序进程失败 ORA-00604: 递归 SQL 级别 1 出现错误 ORA-01555: 快照过旧: 回退段号 5 (名称为 "_SYSSMU5_1527469038$") 过小 Errors in file c:\app\xff\diag\rdbms\orcl\orcl11\trace\orcl11_ora_7088.trc: ORA-00704: 引导程序进程失败 ORA-00704: 引导程序进程失败 ORA-00604: 递归 SQL 级别 1 出现错误 ORA-01555: 快照过旧: 回退段号 5 (名称为 "_SYSSMU5_1527469038$") 过小 Error 704 happened during db open, shutting down database USER (ospid: 7088): terminating the instance due to error 704
通过类似方法处理:
在数据库open过程中常遇到ORA-01555汇总
数据库open过程遭遇ORA-1555对应sql语句补充
顺利open数据库,并且逻辑方式导出数据,完成恢复
发表在 非常规恢复
评论关闭
oracle drop tablespace 恢复最后一招
客户由于不太熟悉oracle数据库,加入错误的数据文件到一个业务表空间,然后经过一系列操作,最终结果是做了drop tablespace xxx including contents and datafiles操作,导致表空间被删除,而且该数据库未做任何备份和归档.通过检查操作系统和数据库alert日志,确认文件已经从os层面彻底删除
对于这种情况,如果立即保护现场,然后通过反删除软件进行恢复,运气好还可以恢复出来被删除的数据文件,然后再通过dul之类的工具恢复其中数据,这个客户库一直没有关闭,而且尝试各种工具恢复,解决均没有正常恢复出来被删除的几个数据文件.对于这种情况,正常os层面的方法肯定无法恢复了,尝试使用基于block层面技术进行扫描磁盘恢复,结果发现运气还不错,绝大部分block都被找到,参考类似恢复方法:Oracle 数据文件大小为0kb或者文件丢失恢复通过类似分析,找出来绝大多数没有覆盖的block,恢复出来被删除的含数据的file 18,20,21,并通过检测整体恢复效果如下

通过dul工具结合客户提供的表定语以及获取到大表id信息,相互关联,快速恢复客户绝大多数数据,最大限度挽回客户损失.

对于oracle 删除表空间之类的操作,我们可以做到block层面深入恢复,理论上只要你被删除的数据文件在磁盘上还有一个block没有被覆盖,我们都可以把里面的数据恢复出来,最大限度的减少因为这种误操作而引起的损失.如果有类似需求无法自行解决,可以联系我们进行最大限度、最快速度的抢救数据.
电话/微信:17813235971 Q Q:107644445
