标签云
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,655)
- DB2 (22)
- MySQL (71)
- Oracle (1,519)
- Data Guard (51)
- EXADATA (8)
- GoldenGate (21)
- ORA-xxxxx (158)
- 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备份恢复 (553)
- Oracle安装升级 (90)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (76)
- 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)
-
最近发表
- 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故障处理
- 19c库启动报ORA-600 kcbzib_kcrsds_1
- DBMS_SESSION.set_context提示ORA-01031问题解决
- redo写丢失导致ORA-600 kcrf_resilver_log_1故障
- 硬件故障导致ORA-01242 ORA-01122等错误
- 200T 数据库非归档无备份恢复
- 利用flashback快速恢复failover 的备库
- [comingback2022@cock.li].eking和[tsai.shen@mailfence.com].faust扩展名勒索病毒数据库可以完美恢复
- opatch auto 出现unable to get oracle owner for 错误
- Oracle 23ai 表和视图的列最多支持到4096个
- 断电引起redo和数据文件不一致故障恢复
- ORA-03113: 通信通道的文件结尾
标签归档:asm磁盘组异常恢复
再一例asm disk被误加入vg并且扩容lv恢复
又一客户把三块asm disk磁盘加入到vg里面(两个节点的root vg中),并且还进行了扩容
加入之后,还对该lv里面进行了expdp数据导出(导出一半失败了,数据库挂了),进而引起了大量的asm磁盘中数据块被文件系统中的expdp导出的dmp复写
![20230217200348](https://www.xifenfei.com/wp-content/uploads/2023/02/20230217200348.jpg)
通过对损坏磁盘进行kfed分析大概判断损坏到90GB位置
![20230217200625](https://www.xifenfei.com/wp-content/uploads/2023/02/20230217200625.jpg)
对于这种asm磁盘损坏比较多的情况,常规kfed无法进行修复,只能采用底层基于block层面的扫描恢复,参考:
asm disk header 彻底损坏恢复
通过底层处理恢复出来数据文件:
![datafile](https://www.xifenfei.com/wp-content/uploads/2023/02/datafile.jpg)
然后通过可以有的2天之前的备份,结合dul工具,恢复出来最近数据,业务层面进行整合,完成本次数据恢复
有过类似的恢复案例:
asm disk被加入vg恢复
又一例asm disk 加入vg故障
pvcreate asm disk导致asm磁盘组异常恢复
一客户asm磁盘组异常,无法正常mount
SQL> alter diskgroup datadg mount 2022-05-28T19:08:55.114960+08:00 NOTE: cache registered group DATADG 1/0x2B504997 NOTE: cache began mount (first) of group DATADG 1/0x2B504997 NOTE: Assigning number (1,3) to disk (/dev/oracleasm/disks/DATA05) NOTE: Assigning number (1,2) to disk (/dev/oracleasm/disks/DATA03) NOTE: Assigning number (1,1) to disk (/dev/oracleasm/disks/DATA02) 2022-05-28T19:08:55.150062+08:00 ERROR: no read quorum in group: required 1, found 0 disks 2022-05-28T19:08:55.150684+08:00 NOTE: cache dismounting (clean) group 1/0x2B504997 (DATADG) NOTE: messaging CKPT to quiesce pins Unix process pid: 15103, image: oracle@XFF01 (TNS V1-V3) NOTE: dbwr not being msg'd to dismount NOTE: LGWR not being messaged to dismount NOTE: cache dismounted group 1/0x2B504997 (DATADG) NOTE: cache ending mount (fail) of group DATADG number=1 incarn=0x2b504997 NOTE: cache deleting context for group DATADG 1/0x2b504997 2022-05-28T19:08:55.191073+08:00 GMON dismounting group 1 at 36 for pid 37, osid 15103 2022-05-28T19:08:55.191258+08:00 NOTE: Disk DATA02 in mode 0x8 marked for de-assignment NOTE: Disk DATA03 in mode 0x8 marked for de-assignment NOTE: Disk DATA05 in mode 0x8 marked for de-assignment ERROR: diskgroup DATADG was not mounted ORA-15032: not all alterations performed ORA-15017: diskgroup "DATADG" cannot be mounted ORA-15040: diskgroup is incomplete
通过报错信息,初步判断是由于少了asm disk导致(依据:1. ORA-15040,2.asmlib中的DATA01丢失),初步判断由于某种原因导致asmlib的磁盘异常,从而使得asm磁盘组无法正常mount,通过对dd 到本地的asm磁盘进行分析
C:\Users\XFF>kfed read H:\TEMP\asmdd\sdb6-o.dd 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 0066E8200 00000000 00000000 00000000 00000000 [................] Repeat 31 times 0066E8400 4542414C 454E4F4C 00000001 00000000 [LABELONE........] 0066E8410 4E06D490 00000020 324D564C 31303020 [...N ...LVM2 001] 0066E8420 34535542 476A7667 42546C48 6D384675 [BUS4gvjGHlTBuF8m] 0066E8430 7A385273 4B495777 73336242 33637449 [sR8zwWIKBb3sItc3] 0066E8440 48001000 000001E8 00100000 00000000 [...H............] 0066E8450 00000000 00000000 00000000 00000000 [................] 0066E8460 00000000 00000000 00001000 00000000 [................] 0066E8470 000FF000 00000000 00000000 00000000 [................] 0066E8480 00000000 00000000 00000002 00000000 [................] 0066E8490 00000000 00000000 00000000 00000000 [................] Repeat 214 times KFED-00322: Invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type][][0]
通过这部分信息可以确认,一个asm disk被创建了pv,进一步分析pv信息
对于这样的情况,表示asm disk被创建了pv但是pv没有加入到任何vg中,也就意味着该disk没有太大破坏,通过信息确认
![20220529124428](https://www.xifenfei.com/wp-content/uploads/2022/05/20220529124428.jpg)
![20220529124734](https://www.xifenfei.com/wp-content/uploads/2022/05/20220529124734.jpg)
主要是这两个部分信息被损坏,可以通过一些方法对这两个block信息进行重构
C:\Users\XFF>kfed read H:\TEMP\asmdd\sdb6.dd|more kfbh.endian: 1 ; 0x000: 0x01 kfbh.hard: 130 ; 0x001: 0x82 kfbh.type: 1 ; 0x002: KFBTYP_DISKHEAD kfbh.datfmt: 1 ; 0x003: 0x01 kfbh.block.blk: 0 ; 0x004: blk=0 kfbh.block.obj: 2147483648 ; 0x008: disk=0 kfbh.check: 3196491921 ; 0x00c: 0xbe869891 kfbh.fcn.base: 0 ; 0x010: 0x00000000 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 kfdhdb.driver.provstr: ORCLDISKDATA01 ; 0x000: length=14 kfdhdb.driver.reserved[0]: 1096040772 ; 0x008: 0x41544144 kfdhdb.driver.reserved[1]: 12592 ; 0x00c: 0x00003130 kfdhdb.driver.reserved[2]: 0 ; 0x010: 0x00000000 kfdhdb.driver.reserved[3]: 0 ; 0x014: 0x00000000 kfdhdb.driver.reserved[4]: 0 ; 0x018: 0x00000000 kfdhdb.driver.reserved[5]: 0 ; 0x01c: 0x00000000 kfdhdb.compat: 203424000 ; 0x020: 0x0c200100 kfdhdb.dsknum: 0 ; 0x024: 0x0000 kfdhdb.grptyp: 1 ; 0x026: KFDGTP_EXTERNAL kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER kfdhdb.dskname: DATA01 ; 0x028: length=6 kfdhdb.grpname: DATADG ; 0x048: length=6 kfdhdb.fgname: DATA01 ; 0x068: length=6 kfdhdb.capname: ; 0x088: length=0 kfdhdb.crestmp.hi: 33083792 ; 0x0a8: HOUR=0x10 DAYS=0xc MNTH=0x4 YEAR=0x7e3 kfdhdb.crestmp.lo: 2268043264 ; 0x0ac: USEC=0x0 MSEC=0x3e6 SECS=0x32 MINS=0x21 kfdhdb.mntstmp.hi: 33134479 ; 0x0b0: HOUR=0xf DAYS=0x1c MNTH=0x5 YEAR=0x7e6 -- More -- C:\Users\XFF>kfed read H:\TEMP\asmdd\sdb6.dd blkn=1|more kfbh.endian: 1 ; 0x000: 0x01 kfbh.hard: 130 ; 0x001: 0x82 kfbh.type: 2 ; 0x002: KFBTYP_FREESPC kfbh.datfmt: 2 ; 0x003: 0x02 kfbh.block.blk: 1 ; 0x004: blk=1 kfbh.block.obj: 2147483648 ; 0x008: disk=0 kfbh.check: 2177715180 ; 0x00c: 0x81cd4bec kfbh.fcn.base: 3721754 ; 0x010: 0x0038ca1a kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 kfdfsb.aunum: 0 ; 0x000: 0x00000000 kfdfsb.max: 1014 ; 0x004: 0x03f6 kfdfsb.cnt: 1014 ; 0x006: 0x03f6 kfdfsb.bound: 0 ; 0x008: 0x0000 kfdfsb.flag: 1 ; 0x00a: B=1 kfdfsb.ub1spare: 0 ; 0x00b: 0x00 kfdfsb.spare[0]: 0 ; 0x00c: 0x00000000 kfdfsb.spare[1]: 0 ; 0x010: 0x00000000 kfdfsb.spare[2]: 0 ; 0x014: 0x00000000 kfdfse[0].fse: 0 ; 0x018: FREE=0x0 FRAG=0x0 kfdfse[1].fse: 0 ; 0x019: FREE=0x0 FRAG=0x0 kfdfse[2].fse: 0 ; 0x01a: FREE=0x0 FRAG=0x0 kfdfse[3].fse: 0 ; 0x01b: FREE=0x0 FRAG=0x0 kfdfse[4].fse: 0 ; 0x01c: FREE=0x0 FRAG=0x0 kfdfse[5].fse: 0 ; 0x01d: FREE=0x0 FRAG=0x0 kfdfse[6].fse: 0 ; 0x01e: FREE=0x0 FRAG=0x0 kfdfse[7].fse: 0 ; 0x01f: FREE=0x0 FRAG=0x0 kfdfse[8].fse: 0 ; 0x020: FREE=0x0 FRAG=0x0
通过dd写入到原磁盘,通过oracleasm scandisks扫描磁盘
磁盘组mount成功
![mount](https://www.xifenfei.com/wp-content/uploads/2022/05/mount.png)
数据库顺利open
![20220529140558](https://www.xifenfei.com/wp-content/uploads/2022/05/20220529140558.jpg)
这个案例能够完美恢复,主要是客户没有做进一步破坏,没有把这个pv加入到vg中并且写入数据,以前有过类似案例因为写入了数据,恢复比这个难多了,效果也没有这个好asm disk被加入vg恢复
如果不幸有类似oracle asm disk被破坏(格式化,dd部分,做成lv等),需要进行恢复支持,可以联系我们,做专业的恢复评估,最大限度,最快速度抢救数据,减少损失
Phone:17813235971 Q Q:107644445
![QQ咨询惜分飞 QQ咨询惜分飞](http://www.xifenfei.com/wp-content/themes/img/site_qq.jpg)
恢复过部分asm异常案例:
删除分区 oracle asm disk 恢复
asm disk 磁盘部分被清空恢复
又一例asm格式化文件系统恢复
一次完美的asm disk被格式化ntfs恢复
oracle asm disk格式化恢复—格式化为ext4文件系统
oracle asm disk格式化恢复—格式化为ntfs文件系统
分享oracleasm createdisk重新创建asm disk后数据0丢失恢复案例
发表在 Oracle, Oracle ASM
标签为 asm lvm恢复, asm恢复, asm磁盘组异常恢复, ORA-15032 ORA-15017 ORA-15040, pvcreate asm disk
评论关闭