标签云
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 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)
- 操作系统 (100)
- 数据库 (1,589)
- DB2 (22)
- MySQL (70)
- Oracle (1,459)
- Data Guard (49)
- EXADATA (7)
- GoldenGate (21)
- ORA-xxxxx (158)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (13)
- ORACLE 21C (3)
- Oracle ASM (65)
- Oracle Bug (7)
- Oracle RAC (47)
- Oracle 安全 (6)
- Oracle 开发 (27)
- Oracle 监听 (27)
- Oracle备份恢复 (526)
- Oracle安装升级 (83)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (75)
- PostgreSQL (13)
- PostgreSQL恢复 (3)
- SQL Server (27)
- SQL Server恢复 (8)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (36)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (19)
-
最近发表
- ORA-00600: internal error code, arguments: [16703], [1403], [4] 原因
- 最近遇到几起ORA-600 16703故障(tab$被清空),请引起重视
- ORA-600 2662快速恢复之Patch scn工具
- TNS-12518: TNS:listener could not hand off client connection
- ora.storage无法启动报ORA-12514故障处理
- 断电引起文件scn异常数据库恢复
- ORA-16188: LOG_ARCHIVE_CONFIG settings inconsistent with previously started instance
- .[hudsonL@cock.li].mkp勒索加密数据库完美恢复
- 模拟带库实现rman远程备份
- 又一例:ORA-600 kclchkblk_4和2662故障
- Oracle误删除数据文件恢复
- Oracle 19C 备库DML重定向—DML Redirection
- ORA-01595/ORA-600 4194处理
- 从ORA-00283 ORA-16433报错开始恢复
- 近期又遇到ORA-600 16703和ORA-702故障
- RECOVER_YOUR_DATA勒索恢复
- ORA-01033: ORACLE initialization or shutdown in progress 故障处理
- Oracle 19c/21c最新patch信息-202401
- 存储故障,强制拉库报ORA-600 kcbzib_kcrsds_1处理
- ORA-600 kcrf_resilver_log_1故障处理
月归档:五月 2017
.wncry比特币勒索病毒恢复
以前也关注过各种比特币勒索,对于oracle数据库主要集中在pl/sql dev和文件加密勒索,以前不管哪种勒索都没有这次的波及的范围只广,影响之大.就连天朝的公安网都严重感染,很多部门业务无法正常情况.
感染之后现象
这里可以发现这次的比特币加密是有选择性的加密,不是所有文件都加密,而是根据文件后缀名来判断,然后给予加密勒索.
查看加密后文件
这次的故障和以往的加密勒索不一样,这次是整个文件全部加密,和以往的加密区别挺大的,因为是全文加密也给恢复带来了非常大的难度.
收到比特币
https://btc.com/12t9YDPgwueZ9NyMgw519p7AA8isjr6SMw
这个链表你可以发现.利索人收到大量比特币,一般不建议交比特币:1)助长了这种气焰,2)交钱也不一定可以解密(身边有失败的例子)
比较侥幸,我们虽然无法解密该加密文件,但是根据加密原理,在硬盘上运行过oracle(存放过oracle数据文件),那就在硬盘上面有痕迹,只要这个痕迹没有覆盖掉,我们就可以通过底层扫描block恢复出来其中的数据(类似:asm disk header 彻底损坏恢复).通过这个原理,我们今天顺利恢复了一个客户的数据库.如果这个方面无法自行恢复的,可以联系我们给予技术支持
Phone:17813235971 Q Q:107644445 E-Mail:dba@xifenfei.com
由于技术功底有限,目前我们只能对于数据库被加密勒索比特币的进行恢复,其他文件无法恢复.对于数据库,我们也需要评估现场之后才能确定是否可以恢复.
发表在 勒索恢复
标签为 .wncry, oracle 比特币, oracle勒索, oracle勒索病毒, wncry恢复, YOUR FILES ARE ENCRYPTED, 勒索恢复, 比特币, 比特币 oracle, 比特币加密, 比特币勒索
评论关闭
ora-600 2037 ORA-7445 kcbs_dump_adv_state解决
有客户系统断电,导致数据库无法启动,让我们帮忙解决,通过分析主要是ORA-600 2037和ORA-7445 _kcbs_dump_adv_state等错误,通过人工recover解决.
数据库报ORA-03113,无法启动成功
C:\Documents and Settings\Administrator>sqlplus / as sysdba SQL*Plus: Release 10.2.0.1.0 - Production on 星期五 5月 12 09:50:36 2017 Copyright (c) 1982, 2005, Oracle. All rights reserved. 已连接到空闲例程。 SQL> startup ORACLE 例程已经启动。 Total System Global Area 1258291200 bytes Fixed Size 1250548 bytes Variable Size 218106636 bytes Database Buffers 1031798784 bytes Redo Buffers 7135232 bytes 数据库装载完毕。 ORA-03113: 通信通道的文件结束
分析alert日志
Fri May 12 09:50:43 2017 ALTER DATABASE OPEN Fri May 12 09:50:43 2017 Beginning crash recovery of 1 threads parallel recovery started with 15 processes Fri May 12 09:50:43 2017 Started redo scan Fri May 12 09:50:43 2017 Completed redo scan 1240 redo blocks read, 277 data blocks need recovery Fri May 12 09:50:44 2017 Started redo application at Thread 1: logseq 5881, block 41179 Fri May 12 09:50:44 2017 Recovery of Online Redo Log: Thread 1 Group 1 Seq 5881 Reading mem 0 Mem# 0 errs 0: E:\ORACLE\PRODUCT\10.2.0\ORADATA\xff\REDO01.LOG Fri May 12 09:50:44 2017 Completed redo application Fri May 12 09:50:44 2017 Errors in file e:\oracle\product\10.2.0\admin\xff\bdump\xff_p006_6072.trc: ORA-00600: internal error code, arguments: [6110], [193], [3], [], [], [], [], [] Fri May 12 09:50:44 2017 Hex dump of (file 3, block 14004) in trace file e:\oracle\product\10.2.0\admin\xff\bdump\xff_p000_6024.trc Corrupt block relative dba: 0x00c036b4 (file 3, block 14004) Bad header found during crash/instance recovery Data in bad block: type: 255 format: 7 rdba: 0x06010601 last change scn: 0xa206.a2060601 seq: 0xb4 flg: 0x36 spare1: 0x1 spare2: 0x6 spare3: 0x673 consistency value in tail: 0x1b0a0708 check value in block header: 0x36b4 computed block checksum: 0xe4f5 Fri May 12 09:50:44 2017 Hex dump of (file 9, block 65507) in trace file e:\oracle\product\10.2.0\admin\xff\bdump\xff_p003_6056.trc Corrupt block relative dba: 0x0240ffe3 (file 9, block 65507) Bad header found during crash/instance recovery Data in bad block: type: 3 format: 6 rdba: 0x06020601 last change scn: 0xa206.a2060602 seq: 0xe3 flg: 0xff spare1: 0x1 spare2: 0x6 spare3: 0x6dc consistency value in tail: 0xc1028001 check value in block header: 0xffe3 computed block checksum: 0xff01 Fri May 12 09:50:44 2017 Reread of rdba: 0x00c036b4 (file 3, block 14004) found different data Fri May 12 09:50:44 2017 Reread of rdba: 0x0240ffe3 (file 9, block 65507) found different data Fri May 12 09:50:44 2017 Errors in file e:\oracle\product\10.2.0\admin\xff\bdump\xff_p005_6060.trc: ORA-00600: internal error code,arguments:[2037],[17442602],[2718302723],[255],[9],[203],[657105414],[2147549568] Fri May 12 09:50:44 2017 Errors in file e:\oracle\product\10.2.0\admin\xff\bdump\xff_p000_6024.trc: ORA-07445:exception encountered:core dump[ACCESS_VIOLATION][_kclcomplete+79][PC:0x72B0C7][ADDR:0x220][UNABLE_TO_READ][] Fri May 12 09:50:44 2017 Errors in file e:\oracle\product\10.2.0\admin\xff\bdump\xff_p006_6072.trc: ORA-07445: exception encountered:core dump[ACCESS_VIOLATION][_kcbzdh+2496][PC:0x4A4928][ADDR:0xB][UNABLE_TO_READ][] ORA-00600: internal error code, arguments: [6110], [193], [3], [], [], [], [], [] Errors in file e:\oracle\product\10.2.0\admin\xff\bdump\xff_p012_6128.trc: ORA-07445: exception encountered: core dump [ACCESS_VIOLATION] [_kcbs_dump_adv_state+723] [PC:0x5975A3] [ADDR:0xCBC0CBB2] [UNABLE_TO_READ] [] ORA-00600:internal error code,arguments:[2037],[17430318],[2718303745],[128],[1],[203],[4147028486],[2147549568]
错误比较明显由于坏块导致应用日志恢复异常,主要错误集中在ORA-600 2037,ORA-7445 _kcbs_dump_adv_state,ORA-7445_kcbzdh,ORA-7445 _kclcomplete等
dbv检查数据文件
E:\>dbv file=E:\ORACLE\PRODUCT\10.2.0\ORADATA\xff\SYSAUX01.DBF DBVERIFY: Release 10.2.0.1.0 - Production on 星期五 5月 12 09:57:39 2017 Copyright (c) 1982, 2005, Oracle. All rights reserved. DBVERIFY - 开始验证: FILE = E:\ORACLE\PRODUCT\10.2.0\ORADATA\xff\SYSAUX01.DBF 页 13353 标记为损坏 Corrupt block relative dba: 0x00c03429 (file 3, block 13353) Bad header found during dbv: Data in bad block: type: 1 format: 6 rdba: 0x3429a206 last change scn: 0x066f.066f3429 seq: 0x0 flg: 0x00 spare1: 0x6 spare2: 0xa2 spare3: 0x8c96 consistency value in tail: 0x06018001 check value in block header: 0x0 block checksum disabled 页 14004 标记为损坏 Corrupt block relative dba: 0x00c036b4 (file 3, block 14004) Bad header found during dbv: Data in bad block: type: 1 format: 6 rdba: 0x36b4a206 last change scn: 0x0673.067336b4 seq: 0x0 flg: 0x00 spare1: 0x6 spare2: 0xa2 spare3: 0xfb97 consistency value in tail: 0x06010210 check value in block header: 0x0 block checksum disabled 页 15261 标记为损坏 Corrupt block relative dba: 0x00c03b9d (file 3, block 15261) Bad header found during dbv: Data in bad block: type: 2 format: 6 rdba: 0x3b9da206 last change scn: 0x0673.06733b9d seq: 0x0 flg: 0x00 spare1: 0x6 spare2: 0xa2 spare3: 0x0 consistency value in tail: 0x06018001 check value in block header: 0x5549 block checksum disabled DBVERIFY - 验证完成 检查的页总数: 58880 处理的页总数 (数据): 19318 失败的页总数 (数据): 0 处理的页总数 (索引): 18610 失败的页总数 (索引): 0 处理的页总数 (其它): 13747 处理的总页数 (段) : 0 失败的总页数 (段) : 0 空的页总数: 7202 标记为损坏的总页数: 3 流入的页总数: 0 最高块 SCN : 178325323 (0.178325323) E:\>dbv file=E:\ORACLE\PRODUCT\10.2.0\ORADATA\xff\xff_BSE02 DBVERIFY: Release 10.2.0.1.0 - Production on 星期五 5月 12 10:10:24 2017 Copyright (c) 1982, 2005, Oracle. All rights reserved. DBVERIFY - 开始验证: FILE = E:\ORACLE\PRODUCT\10.2.0\ORADATA\xff\xff_BSE02 页 65507 标记为损坏 Corrupt block relative dba: 0x0240ffe3 (file 9, block 65507) Bad header found during dbv: Data in bad block: type: 2 format: 6 rdba: 0xffe3a206 last change scn: 0x06dc.06dcffe3 seq: 0x0 flg: 0x00 spare1: 0x6 spare2: 0xa2 spare3: 0xb32 consistency value in tail: 0x060102ff check value in block header: 0x0 block checksum disabled DBVERIFY - 验证完成 检查的页总数: 1310720 处理的页总数 (数据): 34102 失败的页总数 (数据): 0 处理的页总数 (索引): 30270 失败的页总数 (索引): 0 处理的页总数 (其它): 10850 处理的总页数 (段) : 0 失败的总页数 (段) : 0 空的页总数: 1235497 标记为损坏的总页数: 1 流入的页总数: 0 最高块 SCN : 178325221 (0.178325221)
确实如alert日志报错,file 3和9 都出现坏块导致实例恢复无法进行。根据错误ORA-600 2037和ORA-7445 _kcbs_dump_adv_state,初步判断和During Startup (Open Database) Alert Log Shows ORA-600[2037] and ORA-7445[kcbs_dump_adv_state] (Doc ID 551993.1)文章描述相符(而且版本也相符)
尝试recover datafile部分file
E:\>sqlplus / as sysdba SQL*Plus: Release 10.2.0.1.0 - Production on 星期五 5月 12 10:16:00 2017 Copyright (c) 1982, 2005, Oracle. All rights reserved. 连接到: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production With the Partitioning, OLAP and Data Mining options SQL> recover datafile 1; 完成介质恢复。 SQL> recover datafile 2; 完成介质恢复。 SQL> recover datafile 3; 完成介质恢复。 SQL> recover datafile 4; 完成介质恢复。 SQL> recover datafile 9; 完成介质恢复。 SQL> alter database open; alter database open * 第 1 行出现错误: ORA-00600: 内部错误代码, 参数: [kcratr1_lastbwr], [], [], [], [], [], [], []
ORA-00600 kcratr1_lastbwr错误比较明显,见ORA-00600:[Kcratr1_lastbwr] During Database Startup after a Crash (Doc ID 393984.1)
通过recover database处理
SQL> recover database; 完成介质恢复。 SQL> alter database open; 数据库已更改。
然后通过查询dba_extents 处理坏块对象
补充ORA-600 2037错误
Format: ORA-600 [2037] [a] [b] 1 [d] [e] [f] [g] VERSIONS: versions 8.0 and above DESCRIPTION: During recovery we are examining a block to ensure that it is not corrupt prior to applying any change vectors. The block has failed this check and this exception is raised. ARGUMENTS: Arg [a] Relative Data Block Address (RDBA) that the redo vector is for Arg [b] The Block format Arg {c} RDBA in the block itself Arg [d] The block type Arg [e] The sequence number Arg [f] Flags, if set Arg [g] The return value from the block head/tail checker.
asm磁盘分区丢失恢复
有朋友反馈,他们做了xx存储的双活之后,重启主机发现gi无法正常启动,分析发现所有该存储的磁盘分区信息丢失,导致asmlib无法发现磁盘(使用分区做asm disk)
类似如下错误(磁盘分区丢失)
--fdisk -l 显示部分结果 Disk /dev/mapper/datahds1: 1099.5 GB, 1099511627776 bytes 255 heads, 63 sectors/track, 133674 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000 --ls -l /dev/mapper/ 显示结果无分区信息 lrwxrwxrwx 1 root root 7 May 6 03:44 datahds1 -> ../dm-1 lrwxrwxrwx 1 root root 7 May 6 03:26 datahds2 -> ../dm-3 lrwxrwxrwx 1 root root 7 May 6 03:26 datahds3 -> ../dm-8 lrwxrwxrwx 1 root root 7 May 6 03:26 ocrhds1 -> ../dm-0 lrwxrwxrwx 1 root root 7 May 6 03:26 ocrhds2 -> ../dm-2 lrwxrwxrwx 1 root root 7 May 6 03:26 ocrhds3 -> ../dm-4
asm日志显示
SUCCESS: diskgroup DATADG was mounted NOTE: Instance updated compatible.asm to 11.2.0.0.0 for grp 3 SUCCESS: diskgroup OCRHDS was mounted ORA-15032: not all alterations performed ORA-15017: diskgroup "DATA" cannot be mounted ORA-15063: ASM discovered an insufficient number of disks for diskgroup "DATA"
分析系统日志
May 6 02:23:27 db2 kernel: sdb: unknown partition table May 6 02:23:27 db2 kernel: sde: unknown partition table May 6 02:23:27 db2 kernel: sdc: unknown partition table May 6 02:23:27 db2 kernel: sdf: unknown partition table May 6 02:23:27 db2 kernel: sdd: unknown partition table May 6 02:23:27 db2 kernel: sdj:Dev sdj: unable to read RDB block 0 May 6 02:23:27 db2 kernel: unable to read partition table May 6 02:23:27 db2 kernel: sdi: sdi1 May 6 02:23:27 db2 kernel: sdk: sdk1 May 6 02:23:27 db2 kernel: sdg: unknown partition table May 6 02:23:27 db2 kernel: sdl: sdl1 May 6 02:23:27 db2 kernel: sdm:Dev sdm: unable to read RDB block 0 May 6 02:23:27 db2 kernel: unable to read partition table May 6 02:23:27 db2 kernel: sdo:Dev sdo: unable to read RDB block 0 May 6 02:23:27 db2 kernel: unable to read partition table May 6 02:23:27 db2 kernel: sdn:Dev sdn: unable to read RDB block 0 May 6 02:23:27 db2 kernel: unable to read partition table May 6 02:23:27 db2 kernel: sdp:Dev sdp: unable to read RDB block 0 May 6 02:23:27 db2 kernel: unable to read partition table May 6 02:23:27 db2 kernel: sds:Dev sds: unable to read RDB block 0 May 6 02:23:27 db2 kernel: unable to read partition table May 6 02:23:27 db2 kernel: sdh: May 6 02:23:27 db2 kernel: sdt: sdt1 May 6 02:23:27 db2 kernel: sdv:Dev sdv: unable to read RDB block 0 May 6 02:23:27 db2 kernel: unable to read partition table May 6 02:23:27 db2 kernel: sdq:Dev sdq: unable to read RDB block 0 May 6 02:23:27 db2 kernel: unable to read partition table May 6 02:23:27 db2 kernel: sd 1:0:1:9: [sdr] Very big device. Trying to use READ CAPACITY(16). May 6 02:23:27 db2 kernel: sdr:Dev sdr: unable to read RDB block 0 May 6 02:23:27 db2 kernel: unable to read partition table May 6 02:23:27 db2 kernel: sd 2:0:0:9: [sdab] Very big device. Trying to use READ CAPACITY(16). May 6 02:23:27 db2 kernel: sdab: unknown partition table May 6 02:23:27 db2 kernel: sdac: unknown partition table May 6 02:23:27 db2 kernel: sdw: sdw1 May 6 02:23:27 db2 kernel: sdu:Dev sdu: unable to read RDB block 0 May 6 02:23:27 db2 kernel: unable to read partition table May 6 02:23:27 db2 kernel: sdx: sdx1 May 6 02:23:27 db2 kernel: sdy: sdy1 May 6 02:23:27 db2 kernel: sdaa: sdaa1 May 6 02:23:27 db2 kernel: sdz: sdz1 May 6 02:23:27 db2 kernel: sdae: unknown partition table May 6 02:23:27 db2 kernel: sdaf: unknown partition table May 6 02:23:27 db2 kernel: sdag: unknown partition table May 6 02:23:27 db2 kernel: sdai: May 6 02:23:27 db2 kernel: sdah: unknown partition table May 6 02:23:27 db2 kernel: sdad: unknown partition table May 6 02:23:28 db2 mcelog: failed to prefill DIMM database from DMI data
这里错误比较明显unknown partition table,磁盘的分区信息损坏.使用fdisk无法发现分区
partprobe也无效
[root@db2 oracle]# partprobe /dev/mapper/ocrhds3 [root@db2 oracle]# [root@db2 oracle]# ls -l /dev/mapper/ocrhds3* lrwxrwxrwx 1 root root 7 May 6 07:30 /dev/mapper/ocrhds3 -> ../dm-4
从尚需信息看,磁盘的分区表信息应该已经损坏,现在能够做的,就是希望运气好,磁盘的分区的实际数据没有损坏
分析磁盘实际分区数据
[root@db2 ~]$ dd if=/dev/mapper/datahds1 of=/tmp/datahds1.dd bs=1024k count=50 [root@db2 ~]$ dd if=/tmp/datahds1.dd of=/tmp/xff01.dd bs=3225 skip=1 [grid@db2 ~]$ kfed read /tmp/xff01.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: 3110278718 ; 0x00c: 0xb963163e 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: ORCLDISKHDSDATA1 ; 0x000: length=16 kfdhdb.driver.reserved[0]: 1146307656 ; 0x008: 0x44534448 kfdhdb.driver.reserved[1]: 826364993 ; 0x00c: 0x31415441 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: DATADG_0000 ; 0x028: length=11 kfdhdb.grpname: DATADG ; 0x048: length=6 kfdhdb.fgname: DATADG_0000 ; 0x068: length=11 kfdhdb.capname: ; 0x088: length=0 kfdhdb.crestmp.hi: 33050696 ; 0x0a8: HOUR=0x8 DAYS=0x2 MNTH=0x4 YEAR=0x7e1 kfdhdb.crestmp.lo: 3813740544 ; 0x0ac: USEC=0x0 MSEC=0x44 SECS=0x35 MINS=0x38 kfdhdb.mntstmp.hi: 33050701 ; 0x0b0: HOUR=0xd DAYS=0x2 MNTH=0x4 YEAR=0x7e1 kfdhdb.mntstmp.lo: 411385856 ; 0x0b4: USEC=0x0 MSEC=0x150 SECS=0x8 MINS=0x6
通过上述分析,我们可以初步判断,分区磁盘的信息很可能是好的(因为asm disk header是好的,根据一般的规则从前往后覆盖,既然header是好的,后面的block被覆盖的概率非常小)
通过准备新磁盘直接把磁盘分区dd到新设备上
dd if=/dev/mapper/ocrhds1 of=/dev/mapper/ocrhdsnew1 skip=1 bs=3225 dd if=/dev/mapper/ocrhds2 of=/dev/mapper/ocrhdsnew2 skip=1 bs=3225 dd if=/dev/mapper/ocrhds3 of=/dev/mapper/ocrhdsnew3 skip=1 bs=3225 dd if=/dev/mapper/datahds1 of=/dev/mapper/datahdsnew1 skip=1 bs=3225 dd if=/dev/mapper/datahds2 of=/dev/mapper/datahdsnew2 skip=1 bs=3225 dd if=/dev/mapper/datahds3 of=/dev/mapper/datahdsnew3 skip=1 bs=3225
asmlib重新扫描磁盘
[root@db1 disks]# oracleasm scandisks Reloading disk partitions: done Cleaning any stale ASM disks... Scanning system for ASM disks... Instantiating disk "HDSOCR3" Instantiating disk "HDSDATA2" Instantiating disk "HDSDATA1" Instantiating disk "HDSDATA3" Instantiating disk "HDSOCR1" Instantiating disk "HDSOCR2" [root@db1 disks]# ls -ltr total 0 brw-rw---- 1 grid asmadmin 8, 160 May 6 13:49 HDSOCR3 brw-rw---- 1 grid asmadmin 8, 192 May 6 13:49 HDSDATA2 brw-rw---- 1 grid asmadmin 8, 176 May 6 13:49 HDSDATA1 brw-rw---- 1 grid asmadmin 8, 208 May 6 13:49 HDSDATA3 brw-rw---- 1 grid asmadmin 8, 128 May 6 13:49 HDSOCR1 brw-rw---- 1 grid asmadmin 8, 144 May 6 13:49 HDSOCR2
kfed验证拷贝的分区
[root@db2 tmp]# /oracle/app/11.2.0/grid_1/bin/kfed read /dev/oracleasm/disks/HDSDATA1 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: 3110278718 ; 0x00c: 0xb963163e 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: ORCLDISKHDSDATA1 ; 0x000: length=16 kfdhdb.driver.reserved[0]: 1146307656 ; 0x008: 0x44534448 kfdhdb.driver.reserved[1]: 826364993 ; 0x00c: 0x31415441 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: DATADG_0000 ; 0x028: length=11 kfdhdb.grpname: DATADG ; 0x048: length=6 kfdhdb.fgname: DATADG_0000 ; 0x068: length=11 kfdhdb.capname: ; 0x088: length=0
asm和数据库启动正常
[grid@db2 ~]$ asmcmd ASMCMD> lsdg State Type Rebal Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Voting_files Name MOUNTED EXTERN N 512 4096 1048576 3145710 2378034 0 2378034 0 N DATADG/ MOUNTED NORMAL N 512 4096 1048576 15342 14416 5114 4651 0 Y OCRHDS/ ASMCMD> [oracle@db2 ~]$ sqlplus / as sysdba SQL*Plus: Release 11.2.0.4.0 Production on Sat May 6 13:54:21 2017 Copyright (c) 1982, 2013, Oracle. All rights reserved. Connected to an idle instance. SQL> startup ORACLE instance started. Total System Global Area 3.6077E+10 bytes Fixed Size 2260648 bytes Variable Size 7247757656 bytes Database Buffers 2.8723E+10 bytes Redo Buffers 104382464 bytes Database mounted. Database opened. SQL>
通过上述恢复,实现asm磁盘分区丢失数据0丢失
如果您遇到此类情况,无法解决请联系我们,提供专业ORACLE数据库恢复技术支持
Phone:17813235971 Q Q:107644445 E-Mail:dba@xifenfei.com