标签云
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,671)
- DB2 (22)
- MySQL (73)
- Oracle (1,533)
- Data Guard (52)
- 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备份恢复 (560)
- Oracle安装升级 (92)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (78)
- 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)
-
最近发表
- Kylin Linux 安装19c
- ORA-600 krse_arc_complete.4
- Oracle 19c 202410补丁(RUs+OJVM)
- ntfs MFT损坏(ntfs文件系统故障)导致oracle异常恢复
- .mkp扩展名oracle数据文件加密恢复
- 清空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恢复
标签归档:删除分区恢复
删除分区 oracle asm disk 恢复
接到一个朋友数据库故障请求case.大概操作是这样的:有一个39T的lun,通过parted分了15个分区,给oracle asm使用创建磁盘组data4,然后分了4个分区做成data5(由于ausize写错误了),删除掉磁盘组和这四个分区.然后重新分配了6个分区,并且使用最后5个分区创建了data5磁盘组.使用了一段时间之后,由于oracle空间不足,检查的时候误以为这个lun就前面15个分区使用,人工把后面的6个分区给删除了,并且创建了4个新分区,然后发现数据库crash了,发现误删除了在使用的分区.然后又把新创建的4个分区给删除了.接手该故障的时候,这个39T lun的分区信息如下
[root@node1 linux64]# parted /dev/mapper/36000d31003d39e000000000000000004 GNU Parted 2.1 Using /dev/mapper/36000d31003d39e000000000000000004 Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) print Model: Linux device-mapper (multipath) (dm) Disk /dev/mapper/36000d31003d39e000000000000000004: 39.6TB Sector size (logical/physical): 512B/4096B Partition Table: gpt Number Start End Size File system Name Flags 1 2097kB 2000GB 2000GB asmdata4-1 2 2000GB 4000GB 2000GB asmdata4-2 3 4000GB 6000GB 2000GB asmdata4-3 4 6000GB 8000GB 2000GB asmdata4-4 5 8000GB 10.0TB 2000GB asmdata4-5 6 10.0TB 12.0TB 2000GB asmdata4-6 7 12.0TB 14.0TB 2000GB asmdata4-7 8 14.0TB 16.0TB 2000GB asmdata4-8 9 16.0TB 18.0TB 2000GB asmdata4-9 10 18.0TB 20.0TB 2000GB asmdata4-10 11 20.0TB 22.0TB 2000GB asmdata4-11 12 22.0TB 24.0TB 2000GB asmdata4-12 13 24.0TB 26.0TB 2000GB asmdata4-13 14 26.0TB 28.0TB 2000GB asmdata4-14 15 28.0TB 30.0TB 2000GB asmdata4-15
客户正常使用情况下,这个lun上面相关分区的asm disk信息
SQL> CREATE DISKGROUP DATA4 EXTERNAL REDUNDANCY DISK '/dev/mapper/36000d31003d39e000000000000000004p1' SIZE 1907346M , '/dev/mapper/36000d31003d39e000000000000000004p2' SIZE 1907350M , '/dev/mapper/36000d31003d39e000000000000000004p3' SIZE 1907348M , '/dev/mapper/36000d31003d39e000000000000000004p4' SIZE 1907348M , '/dev/mapper/36000d31003d39e000000000000000004p5' SIZE 1907350M ATTRIBUTE 'compatible.asm'='11.2.0.0.0','au_size'='8M' /* ASMCA */ SQL> ALTER DISKGROUP DATA4 ADD DISK '/dev/mapper/36000d31003d39e000000000000000004p10' SIZE 1907348M , '/dev/mapper/36000d31003d39e000000000000000004p6' SIZE 1907348M , '/dev/mapper/36000d31003d39e000000000000000004p7' SIZE 1907348M , '/dev/mapper/36000d31003d39e000000000000000004p8' SIZE 1907350M , '/dev/mapper/36000d31003d39e000000000000000004p9' SIZE 1907348M /* ASMCA */ SQL> ALTER DISKGROUP DATA4 ADD DISK '/dev/mapper/36000d31003d39e000000000000000004p11' SIZE 1907348M , '/dev/mapper/36000d31003d39e000000000000000004p12' SIZE 1907350M , '/dev/mapper/36000d31003d39e000000000000000004p13' SIZE 1907348M , '/dev/mapper/36000d31003d39e000000000000000004p14' SIZE 1907348M , '/dev/mapper/36000d31003d39e000000000000000004p15' SIZE 1907350M /* ASMCA */ SQL> CREATE DISKGROUP DATA5 EXTERNAL REDUNDANCY DISK '/dev/mapper/36000d31003d39e000000000000000004p17' SIZE 1716614M , '/dev/mapper/36000d31003d39e000000000000000004p18' SIZE 1716614M , '/dev/mapper/36000d31003d39e000000000000000004p19' SIZE 1716614M , '/dev/mapper/36000d31003d39e000000000000000004p20' SIZE 1716614M , '/dev/mapper/36000d31003d39e000000000000000004p21' SIZE 1621246M ATTRIBUTE 'compatible.asm'='11.2.0.0.0','au_size'='4M' /* ASMCA */
基于客户现在的情况,data4中的所有分区都正常,主要是要找出来data5中的5个分区的数据.因为客户不确定p16分区大小,导致后续的5个分区起始位置不好定位.从而使得恢复无法进行.通过shell脚本结合kfed尝试定位asm disk header信息
#!/bin/bash j=xxxxxxxxxxx for ((i=xxxxxx; i<=j; i++)) do echo "-----$i--------" >> /home/get_au1.txt kfed read /dev/mapper/36000d31003d39e000000000000000004 aun=$i | > grep "kfdhdb.dskname: DATA" >> /home/get_au.txt done
结果发现无法获取到结果,通过分析发现这里由于lun过大,导致aun值过大,从而使得kfed溢出无法读取到正常值.根据parted的特性,人工dd部分block进行分析
[root@node1 bak]# kfed read xifenfei.dd aun=134|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: 3357988283 ; 0x00c: 0xc826d5bb 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: ORCLDISK ; 0x000: length=8 kfdhdb.driver.reserved[0]: 0 ; 0x008: 0x00000000 kfdhdb.driver.reserved[1]: 0 ; 0x00c: 0x00000000 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: 186646528 ; 0x020: 0x0b200000 kfdhdb.dsknum: 0 ; 0x024: 0x0000 kfdhdb.grptyp: 1 ; 0x026: KFDGTP_EXTERNAL kfdhdb.hdrsts: 3 ; 0x027: KFDHDR_MEMBER kfdhdb.dskname: DATA5_0000 ; 0x028: length=10 kfdhdb.grpname: DATA5 ; 0x048: length=5 kfdhdb.fgname: DATA5_0000 ; 0x068: length=10 kfdhdb.capname: ; 0x088: length=0 kfdhdb.crestmp.hi: 33116450 ; 0x0a8: HOUR=0x2 DAYS=0x9 MNTH=0x4 YEAR=0x7e5 kfdhdb.crestmp.lo: 477378560 ; 0x0ac: USEC=0x0 MSEC=0x10e SECS=0x7 MINS=0x7 kfdhdb.mntstmp.hi: 33116450 ; 0x0b0: HOUR=0x2 DAYS=0x9 MNTH=0x4 YEAR=0x7e5 kfdhdb.mntstmp.lo: 486256640 ; 0x0b4: USEC=0x0 MSEC=0x2ec SECS=0xf MINS=0x7 kfdhdb.secsize: 512 ; 0x0b8: 0x0200 kfdhdb.blksize: 4096 ; 0x0ba: 0x1000 kfdhdb.ausize: 4194304 ; 0x0bc: 0x00400000 kfdhdb.mfact: 454272 ; 0x0c0: 0x0006ee80 kfdhdb.dsksize: 429153 ; 0x0c4: 0x00068c61 kfdhdb.pmcnt: 2 ; 0x0c8: 0x00000002
顺利找到了data5中的第一块磁盘,而且确定了起始位置,然后构造相关的dd语句把分区的数据dd到一个新磁盘中
dd if=/dev/mapper/36000d31003d39e000000000000000004 bs=4M skip=xxxxx count=429153 of=/dev/sdu
通过类似方法依次处理,最终把5块asm disk全部找到,并且顺利dd到新的磁盘中.尝试启动crs,并mount data5
data5 磁盘组mount成功之后,数据库顺利启动,实现lun中删除分区之后,asm磁盘组数据完美恢复
这次运气还不错,仅仅是对lun的分区使用了parted进行了删除和创建等操作,没有格式化文件系统和做成新的asm disk,不然数据会有一部分丢失.对于有部分破坏的分区,需要通过底层碎片的方法进行最大限度抢救数据.参考类似文档:
asm disk被加入vg恢复
又一例asm格式化文件系统恢复
文件系统损坏导致数据文件异常恢复
一次完美的asm disk被格式化ntfs恢复
Oracle 数据文件大小为0kb或者文件丢失恢复
再一起asm disk被格式化成ext3文件系统故障恢复
oracle asm disk格式化恢复—格式化为ext4文件系统
oracle asm disk格式化恢复—格式化为ntfs文件系统
分享oracleasm createdisk重新创建asm disk后数据0丢失恢复案例