标签云
asm恢复 bbed bootstrap$ dul kcbzib_kcrsds_1 kccpb_sanity_check_2 kcratr_nab_less_than_odr MySQL恢复 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-600 kdsgrp1 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)
- 操作系统 (112)
- 数据库 (1,862)
- DB2 (22)
- MySQL (82)
- Oracle (1,688)
- 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备份恢复 (646)
- Oracle安装升级 (106)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (90)
- PostgreSQL (37)
- pdu工具 (7)
- PostgreSQL恢复 (13)
- SQL Server (34)
- SQL Server恢复 (14)
- TimesTen (7)
- 达梦数据库 (5)
- 达梦恢复 (3)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (48)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (31)
-
最近发表
- 记录block 0损坏,数据文件大量坏块,使用不当数据库版本恢复等各种操作之后的故障处理
- 需要注意:dbv 检测controlfile可能不准
- 达梦数据库redo异常强制拉库
- dd破坏包含50多个pdb的asm 磁盘组恢复
- Oracle数据库系统回滚段异常处理-ORA-600 4137/4193
- 使用deepseek进行Oracle恢复,引起重大故障
- 接手一个只差临门一脚的数据库恢复
- 硬件故障后数据文件大小不对故障处理—Oracle碎片扫描恢复
- 1.5T MySQL数据库完美恢复
- WARNING: detected duplicate paths to the same disk导致crs无法正常启动故障解决
- asm dd 10M导致system文件部分坏块修复
- Oracle 19c 202604补丁(RUs+OJVM)-19.31
- Oracle故障第一现场被恢复混乱的数据库恢复
- impdp报ORA-39083 ORA-14102错误处理
- 一次断电引起的Oracle故障恢复-ora-600 2662故障
- OraScan(Oracle 碎片扫描工具) 使用说明
- .[xueyuanjie@onionmail.org].AIR勒索加密数据库恢复
- oracleasm createdisk破坏的acfs文件系统恢复
- 先offline数据文件,再resetlogs导致恢复复杂的故障处理
- exp dmp导入报IMP-00098: INTERNAL ERROR: impgst2故障处理
分类目录归档:Oracle ASM
dd破坏包含50多个pdb的asm 磁盘组恢复
前段时间刚刚恢复了一个客户dd了34个磁盘中的2个磁盘的1-2G多的数据(在生产环境错误执行dd命令破坏asm磁盘故障恢复),这次又遇到一个客户dd了asm 的两个磁盘的100m和10m,这次故障麻烦的是由于dd了disk 0和disk 1,ausize为4M,有50多个pdb在该磁盘组中,相对恢复比较麻烦,通过不懈努力,最后终于最大限度恢复客户数据,避免了进一步的损失
故障误操作
近期又一个可以误执行了dd命令,破坏了生产库的两个asm disk磁盘

上述截图中可以确认两个信息
1.sdh盘被dd掉了10m,sdg盘被dd掉了100M
2.sdg对应的是asm-data1,sdh对应的是asm-data2
dd误操作之后,data磁盘组开始报错,然后直接dismount.

分析原磁盘组中asm磁盘情况
1.确定损坏磁盘在磁盘组中位置
通过asm的alert日志分析损坏的盘对应的磁盘组信息

基于这个信息,我们可以确认asm-data1 对应的是DATA磁盘组的disk 0,asm-data2对应的是DATA磁盘组的disk 1,也就是说现在DATA磁盘组的0号盘被dd了100M,1号盘被dd了10m
2.确认ausize大小
通过分析该磁盘组的其他磁盘确认ausize大小
kfdhdb.ausize: 4194304 ; 0x0bc: 0×00400000
可以确认该磁盘组的au大小为4M
3.磁盘组后续进行了一次加盘扩容

在25年6月份,对data磁盘组加了三块盘
4.sdh(asm-data2)磁盘还被加入到了arch磁盘组中

比较幸运由于在另外一个节点上sdh磁盘权限没有正确修改,导致该增加没有完全成功,也就是该磁盘没有被reblance(如果加入成功并正常reblance,那后果比现在严重很多)
5.通过结合asm日志以及kfed,磁盘物理大小等信息,并且通过kfed构造出来损坏的磁盘头信息,列出故障之前DATA磁盘组所有磁盘的情况(为了避免udev别名带来的影响,我直接使用物理磁盘名称来显示)

客户现场情况说明
1.客户有一个大概1年多之前的dataguard(后续没有继续同步),已经进行了failover激活
2.客户的备份系统中有一个大概1个月之前的备份,但是备份库缺少归档,我接手之时,已经被维护厂商强制拉起
3.在我恢复之前,有专业的工程师已经对其这个现场进行了分析,但是没有拿出好的恢复方案
恢复难点说明
1.该磁盘组的disk 0 被dd掉了100M,这个导致kfdhdb.f1b1locn记录被清空,也就无法获取到存储指向ASM file 1 文件目录表,这个值虽然被清空,但是根据经验或者对比其他磁盘组的disk 0 可以确认指定aun为10
2.f1b1locn指向的au中存储中asm元数据1-255以及256-1023的file的前面60个au的extent映射表,由于这个在aun为10(也就是aun*aus=40M)的位置,但是这个位置也已经被dd掉了,从原理上业务文件256-1023的前面60个au的extent映射表彻底丢失
3.通过工具扫描,发现存储别名信息的au也在disk 0的前面100M之内(也被dd掉了),导致通过别名直接定位文件的起点的恢复思路也不可行,而且别名丢失导致以别名的数据文件后续识别有一定的难度(无法获取asm里面文件的完整路径)
4.该库有50多套pdb组成,也就意味着通过数据库碎片扫描的方式无法恢复(因为每个pdb里面都是由默认的种子创建而成,也就意味着rfile 1,4,9是重复的)
5.由于中途加过一次磁盘,因引起这个asm里面的文件进行重新reblance,使得部分文件同一个block记录在不同磁盘的au上(数据文件块可能重复)
6.由于该磁盘组中asm disk 大小不等,导致文件au分布在各个磁盘上不均匀,无明显规律可循
恢复操作
1.通过kfed对损坏的asm-data1、asm-disk2的磁盘头进行构造,便于后续的恢复工具识别
2.通过工具对data中所有磁盘进行扫描,主要扫描文件extent映射表信息和ACD中关于asm文件的分配信息
2.1> 通过对这些信息进行综合分析,确认asm file >=1024的文件的extent映射表信息完整,数据可以直接恢复,效果类似

2.2> 对于256-1023号文件通过asm file的extent信息缺少0-59 au的数据,结合acd中获取的部分au分配信息,可以尽可能完整的恢复出来这些数据(由于disk 0中的acd信息丢失,所以不是100%完整)

3.对于绝对文件号非1,4,9的文件,而且asm file 小于1024的数据文件,结合rdba碎片重组的方式再一次进行恢复,避免上面2.2中恢复中前面240M(60个au),有部分au信息丢失导致文件不完整的情况
通过上述多种方法恢复,整体恢复数据文件类似(由于文件较多,存放多个目录和根据规则取了多种名字)

4.由于asm的文件目录,别名信息全部丢失,而且该库有50多个pdb,无法确认恢复出来的上千个文件和pdb对应的关系,对于这种情况,临时写了一个小程序,对这些文件进行读取,获取file#,rfile#,ts#,tsname,文件大小,dbid,dbname,scn等信息(obet(Oracle Block Editor Tool)第二版发布

通过把这些信息和历史的控制文件中的信息进行匹配,确认各个文件所属的pdb关系
5.通过4中获取的文件和pdb对应关系然后通过dbms_pdb.recover包实现把恢复的文件插入到新的cdb库中,在这个插入和open库过程中遇到各种错误,都一一解决





6.最终完成客户数据恢复要求(为了保证数据不被再次修改,客户要求所有恢复的pdb不能打开到读写模式)

然后由客户的运维厂商或者应用厂商把需要的数据迁移或者整合到新库中并恢复业务,完成本次恢复任务
WARNING: detected duplicate paths to the same disk导致crs无法正常启动故障解决
最近一周之内,两个客户由于错误修改asm_diskstring=’/dev/dm*’,’/dev/mapper/*’,导致后续集群无法启动成功,查看asm的alert日志发现类似错误(为了说明类似问题,实际中情况比现在复杂)
WARNING: detected duplicate paths to the same disk: '/dev/mapper/mpathi' and '/dev/dm-3' ERROR: diskgroup CRS was not mounted ORA-15032: not all alterations performed ORA-15017: diskgroup "CRS" cannot be mounted ORA-15040: diskgroup is incomplete
由于asm的vote磁盘组无法mount,从而使得crs无法正常启动,进而导致集群无法正常启动和工作.而在系统中mpathi和dm-3是同一块磁盘
[root@rac1 mapper]# ls -ltr mpathi lrwxrwxrwx 1 root root 7 May 24 13:09 mpathi -> ../dm-3
GPnP profile中关于asm_diskstring配置
[grid@rac1 trace]$ gpnptool get -o- …… <orcl:ASM-Profile id="asm" DiscoveryString="/dev/dm*,/dev/mapper/mpath*" SPFile="+DATA/cimp-cluster/asmparameterfile/registry.253.889969697"/> ……
对于这样的情况,需要把profile中值修改了才行,通过重建asm spfile来实现
---pfile large_pool_size= 12M instance_type= 'asm' remote_login_passwordfile= 'EXCLUSIVE' asm_diskstring= '/dev/mapper/*' asm_power_limit= 1 diagnostic_dest= '/opt/app/grid'
创建spfile(create spfile=’+CRS’ from pfile=’/tmp/pfile’)
NOTE: Attempting voting file refresh on diskgroup CRS NOTE: Refresh completed on diskgroup CRS. No voting file found. NOTE: Voting file relocation is required in diskgroup CRS NOTE: Attempting voting file relocation on diskgroup CRS NOTE: voting file deletion on grp 1 disk CRS_0000 NOTE: voting file deletion on grp 1 disk CRS_0001 NOTE: voting file deletion on grp 1 disk CRS_0002 NOTE: No voting file found on diskgroup CRS Sun May 24 13:23:25 2026 NOTE: updated gpnp profile ASM SPFILE to NOTE: updated gpnp profile ASM diskstring: /dev/mapper/* NOTE: updated gpnp profile ASM diskstring: /dev/mapper/* NOTE: updated gpnp profile ASM SPFILE to +CRS/cluster/asmparameterfile/registry.253.1234099407
主要注意在create spfile的过程中voting file的信息被删除,使用kfed进行验证
[root@rac1 dbs]# kfed read /dev/asm_mpathi|grep vf kfdhdb.vfstart: 0 ; 0x0ec: 0x00000000 kfdhdb.vfend: 0 ; 0x0f0: 0x00000000 [root@rac1 dbs]# kfed read /dev/asm_mpatha|grep vf kfdhdb.vfstart: 0 ; 0x0ec: 0x00000000 kfdhdb.vfend: 0 ; 0x0f0: 0x00000000 [root@rac1 dbs]# kfed read /dev/asm_mpathd|grep vf kfdhdb.vfstart: 0 ; 0x0ec: 0x00000000 kfdhdb.vfend: 0 ; 0x0f0: 0x00000000
需要执行replace votedisk
[root@rac1 dbs]# crsctl replace votedisk +CRS Successful addition of voting disk 99df870869c64f78bf944b40bfff8644. Successful addition of voting disk e6db086a74d64f49bf0aff02944bcac5. Successful addition of voting disk e88a412fe04b4fe6bf1ca067bca779b8. Successful deletion of voting disk 615579e778684f54bf31c0ce83709f37. Successful deletion of voting disk 9e48b89f95084fefbfb7648897508684. Successful deletion of voting disk 274b913b3b874f7cbfb6b025028b4eaa. Successfully replaced voting disk group with +CRS. CRS-4266: Voting file(s) successfully replaced
这样操作完成之后,再次查看GPnP profile中关于asm_diskstring配置
[grid@rac1 trace]$ gpnptool get -o- …… <orcl:ASM-Profile id="asm" DiscoveryString="/dev/asm_*" SPFile="+DATA/cimp-cluster/asmparameterfile/registry.253.1234099407"/> ……
然后再次重启集群,一切恢复正常,解决了asm_diskstring=’/dev/dm*’,’/dev/mapper/*’误操作引起的WARNING: detected duplicate paths to the same disk:故障
发表在 Oracle ASM, Oracle RAC
评论关闭
oracleasm createdisk破坏的acfs文件系统恢复
接到一个朋友请求,客户12.2.0.1的asm被执行了oracleasm createdisk,把之前的asmdisk给重建了

根据以前恢复经验,这个故障会把前面1M的数据全部重置
删除asmlib磁盘导致磁盘组故障恢复
分享oracleasm createdisk重新创建asm disk后数据0丢失恢复案例
这个客户有点特殊,他的asm 磁盘组中跑的不是oracle 数据库而是直接跑acfs,然后再里面跑mysql数据库,也就是利用grid实现mysql的底层高可用,acfs实现共享挂载(我的理解一次也只能启动一个节点的mysql),现在asm disk的头被oracleasm createdisk重置之后,导致asm磁盘组无法mount,从而acfs也无法mount.对于这个故障,让现场提供被破坏磁盘使用dd前面100M 发给我进行分析
使用kfed读取asm disk磁盘头信息
H:\TEMP\0423\0423>kfed read data3_100m 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: 1096040823 ; 0x00c: 0x41544177 kfbh.fcn.base: 0 ; 0x010: 0x00000000 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 005B78600 00000000 00000000 00000000 41544177 [............wATA] 005B78610 00000000 00000000 00000000 00000000 [................] 005B78620 4C43524F 4B534944 41544144 00000033 [ORCLDISKDATA3...] 005B78630 00000000 00000000 00000000 00000000 [................] Repeat 252 times KFED-00322: Invalid content encountered during block traversal: [kfbtTraverseBlock][Invalid OSM block type][][0]
这里可以发现比较明显的asmlib的标记信息ORCLDISKDATA3,证明该磁盘被oracleasm createdisk重建之后,没有再进行kfed修复或者重建新磁盘组
SUCCESS: CREATE DISKGROUP DATA EXTERNAL REDUNDANCY DISK '/dev/oracleasm/disks/DATA1' SIZE 1430507M DISK '/dev/oracleasm/disks/DATA2' SIZE 1430507M DISK '/dev/oracleasm/disks/DATA3' SIZE 1430507M ATTRIBUTE 'compatible.asm'='12.2.0.1','compatible.advm'='12.2.0.1','au_size'='4M' SUCCESS: CREATE DISKGROUP CRS EXTERNAL REDUNDANCY DISK '/dev/oracleasm/disks/CRS' SIZE 190732M ATTRIBUTE 'compatible.asm'='12.2.0.1','compatible.advm'='12.2.0.1','au_size'='4M' /* ASMCA */
通过alert日志中磁盘组的创建语句,确认该磁组是ausize为4M,这样的情况下,asm的磁盘头备份备份和au备份应该都是好的,直接通过winhex来确认

再次通过kfed来确认相关磁盘头信息
H:\TEMP\0423\0423>kfed read data3_100m aus=4096k blkn=1022 aun=1|grep name kfdhdb.dskname: DATA_0002 ; 0x028: length=9 kfdhdb.grpname: DATA ; 0x048: length=4 kfdhdb.fgname: DATA_0002 ; 0x068: length=9 kfdhdb.capname: ; 0x088: length=0 H:\TEMP\0423\0423>kfed read data3_100m aus=4096k blkn=0 aun=11|grep name kfdhdb.dskname: DATA_0002 ; 0x028: length=9 kfdhdb.grpname: DATA ; 0x048: length=4 kfdhdb.fgname: DATA_0002 ; 0x068: length=9 kfdhdb.capname: ; 0x088: length=0
基于上述情况,证明磁盘头和au的备份都还在,而且au的备份是4M,完全包含了被createdisk破坏的1M数据,直接吧这个au给还原回去理论上就可以了,但是很不幸,这样处理之后,crs启动过程依旧无法找到表决盘

通过分析crs盘的情况,发现它的偏移量是错误的

通过分析是由于磁盘分区问题导致
磁盘 /dev/sdc:200.0 GB, 199996997632 字节,390619136 个扇区 Units = 扇区 of 1 * 512 = 512 bytes 扇区大小(逻辑/物理):512 字节 / 512 字节 I/O 大小(最小/最佳):512 字节 / 1048576 字节 磁盘标签类型:dos 磁盘标识符:0x00000000 设备 Boot Start End Blocks Id System /dev/sdc1 1 390619135 195309567+ ee GPT 磁盘 /dev/sdd:1500.0 GB, 1499996356608 字节,2929680384 个扇区 Units = 扇区 of 1 * 512 = 512 bytes 扇区大小(逻辑/物理):512 字节 / 512 字节 I/O 大小(最小/最佳):512 字节 / 1048576 字节 磁盘标签类型:gpt Disk identifier: 99F1679E-DC32-4F6A-B85D-D91C87B09775 # Start End Size Type Name 1 2048 2929678335 1.4T Linux LVM
至此这个被oracleasm createdisk的case完美恢复,数据0丢失


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

