oracle数据库被加密为.megac.megac后缀名,加密情况如下:
加密说明文件类似:
恢复数据截图:
这类的数据库加密,我们可以直接通过解密处理,open数据库,导出数据,恢复之后立即可用.如果需要可以联系我们从底层进行恢复:Phone:17813235971 Q Q:107644445
E-Mail:dba@xifenfei.com
dbca删除库和rm删库恢复
由于误操作删除库的事情偶有发生,遇到过dbca误删除数据库,遇到过rm删除数据文件的故障.近期有过两次类似的恢复请求,一次是win平台dbca本该删除测试库,结果选择错误把生产库给删除,发生误操作之后,没有及时对磁盘进行卸载,而是有一些写操作,当事人找了各种反删除软件进行恢复,结果只是成功了恢复了部分文件,核心文件全部丢失.另外一次是linux平台误操作,rm -rf 删除了整个oracle目录,而且数据文件也全部在里面,所幸没有任何写操作.
对于dbca客户已经使用反删除软件进行恢复,但是效果不行,我们直接从底层扫描,恢复出来需要数据
有个别文件少量block被覆盖,而且客户只要其中部分核心表数据,因此直接使用dul恢复出客户需要数据,完美完成恢复
对于rm掉所有数据文件的客户,通过extundelete进行反删除恢复(参考:extundelete恢复Linux被删除文件),由于句柄丢失,导致有几个数据文件恢复失败.通过linux平台底层恢复,实现需要数据文件完全恢复,数据库正常open,实现完美恢复
对于这类删库的操作,一定要保护好现场,对数据文件存在分区不要有二次写操作,尽可能的减少覆盖.理论上数据文件在磁盘上,都可以恢复出来.如果有遇到数据库文件误删除,或者文件系统损坏的恢复需求,无法自行解决,可以联系我们从底层进行恢复:Phone:17813235971 Q Q:107644445 E-Mail:dba@xifenfei.com
类似恢复案例:
又一例asm格式化文件系统恢复
文件系统损坏导致数据文件异常恢复
Oracle 数据文件大小为0kb或者文件丢失恢复
oracle asm disk格式化恢复—格式化为ntfs文件系统
oracle asm disk格式化恢复—格式化为ext4文件系统
ORA-15042: ASM disk “N” is missing from group number “M” 故障恢复
.chch后缀名加密恢复
最近有数据库被.chch病毒加密,通过分析,此类病毒可以通过数据库层面较好恢复
通过恢复处理,实现数据较好恢复效果如下
如果有此类的加密场景数据库,可以联系我们
SQL Server truncate table 恢复
从本质上来说,sql server的truncate操作也是和oracle类似的,实际数据依旧存在磁盘之上,通过对底层的分析没有覆盖的部分,依然可以恢复出来,这里列举出来大概的恢复截图,原表数据4605条记录
对其truncate操作
通过恢复出来,解析出来被truncate表的insert sql语句
插入数据之后,验证效果
至此我们可以实现sql server数据库被truncate表的恢复支持,只要没有覆盖的数据,理论上都可以恢复
当你的SQL Server数据库因为误操作导致数据丢失，且无法自行解决，请联系我们，提供专业SQL Server数据库恢复技术支持
Phone/微信:17813235971 Q Q:107644445 E-Mail:dba@xifenfei.com
SQL Server delete恢复
对于sql server的delete操作,其实本质也是类似oracle的,我们可以通过两种途径进行恢复:1.直接解析sql的日志,2.直接读取mdf/ndf文件找出来被标记为删除的记录,在有日志的情况下,通过日志分析能够更加准确的定位记录(因为根据删除标记可能找到的记录不是这次删除操作的),这里来一个简单的恢复过程,一张sql server的表,记录数为83条
对其进行delete删除操作
进行恢复分析,直接生成insert语句,反插入库即可
同时我们还可以根据需要生成对应的redo/undo相关sql语句
至此我们已经分析,可以比较完美的恢复sql server delete误操作丢失的数据.
当你的SQL Server数据库因为误操作导致数据丢失，且无法自行解决，请联系我们，提供专业SQL Server数据库恢复技术支持
Phone/微信:17813235971 Q Q:107644445 E-Mail:dba@xifenfei.com
SQL Server drop table 恢复
sql server drop table本质上数据也还是在磁盘上,通过底层技术依旧像Oracle一样可以恢复,测试一张表的drop恢复操作
备份表数据,用于删除前后对比
删除表数据
我们对数据进行恢复(可以恢复表结构和表数据)
对比恢复前后数据
通过对比发现我们实现drop table数据完美恢复.
当你的SQL Server数据库因为误操作导致数据丢失，且无法自行解决，请联系我们，提供专业SQL Server数据库恢复技术支持
Phone/微信:17813235971 Q Q:107644445 E-Mail:dba@xifenfei.com
oracle dmp被加密恢复
接到朋友恢复请求,oracle dmp文件被加密
通过分析文件发现该加密主要是对头尾部分block按照每16byte中8个byte置空和部分加密
通过进行恢复,对损坏部分进行跳过,剩余数据直接导入数据库,通过show=y测试数据可以正常入库,实现了dmp文件表数据的完美恢复
当你的Oracle dmp因为因为某种原因损坏，且无法自行解决，请联系我们，提供专业数据库恢复技术支持
Phone/微信:17813235971 Q Q:107644445 E-Mail:dba@xifenfei.com
.READINSTRUCTIONS加密数据库恢复
有朋友win文件系统被加密,后缀名为.READINSTRUCTIONS,上面运行有oracle数据库
通过分析,该病毒加密破坏相对比较严重,无法实现100%恢复,但是通过一系列处理,绝大部分数据还是可以顺利恢复出来
如果有文件系统加密数据库(Oracle,SQL Server),我们可以提供恢复服务,承诺恢复之后确认数据有价值再收费.如果有需要请联系我们:
电话/微信:17813235971 Q Q:107644445 E-Mail:dba@xifenfei.com
.READINSTRUCTIONS加密数据库恢复
有朋友win文件系统被加密,后缀名为.READINSTRUCTIONS,上面运行有oracle数据库
通过分析,该病毒加密破坏相对比较严重,无法实现100%恢复,但是通过一系列处理,绝大部分数据还是可以顺利恢复出来
如果有文件系统加密数据库(Oracle,SQL Server),我们可以提供恢复服务,承诺恢复之后确认数据有价值再收费.如果有需要请联系我们:电话/微信:17813235971 Q Q:107644445 E-Mail:dba@xifenfei.com
ORA-15196: invalid ASM block header [kfc.c:26368] [endian_kfbh]故障处理
客户对asm进行扩容,由于配置不恰当,在使用asmca增加asm disk的时候直接选中了已经被用作文件系统的vg中的磁盘
Tue Nov 19 09:48:48 2019 Non critical error ORA-48180 cFri Nov 22 12:47:48 2019 SQL> ALTER DISKGROUP XIFENFEI ADD DISK '/dev/rhdisk29' SIZE 491520M , '/dev/rhdisk30' SIZE 491520M , '/dev/rhdisk31' SIZE 491520M /* ASMCA */ NOTE: GroupBlock outside rolling migration privileged region NOTE: Assigning number (4,15) to disk (/dev/rhdisk29) NOTE: Assigning number (4,16) to disk (/dev/rhdisk30) NOTE: Assigning number (4,17) to disk (/dev/rhdisk31) NOTE: requesting all-instance membership refresh for group=4 NOTE: initializing header on grp 4 disk XIFENFEI_0015 NOTE: initializing header on grp 4 disk XIFENFEI_0016 NOTE: initializing header on grp 4 disk XIFENFEI_0017 NOTE: requesting all-instance disk validation for group=4 Fri Nov 22 12:47:51 2019 NOTE: skipping rediscovery for group 4/0xb08c40b (XIFENFEI) on local instance. NOTE: requesting all-instance disk validation for group=4 NOTE: skipping rediscovery for group 4/0xb08c40b (XIFENFEI) on local instance. Fri Nov 22 12:47:59 2019 NOTE: initiating PST update: grp = 4 Fri Nov 22 12:47:59 2019 GMON updating group 4 at 12 for pid 27, osid 12649908 NOTE: PST update grp = 4 completed successfully NOTE: membership refresh pending for group 4/0xb08c40b (XIFENFEI) GMON querying group 4 at 13 for pid 18, osid 39912680 Fri Nov 22 12:48:01 2019 NOTE: cache opening disk 15 of grp 4: XIFENFEI_0015 path:/dev/rhdisk29 NOTE: cache opening disk 16 of grp 4: XIFENFEI_0016 path:/dev/rhdisk30 NOTE: cache opening disk 17 of grp 4: XIFENFEI_0017 path:/dev/rhdisk31 NOTE: Attempting voting file refresh on diskgroup XIFENFEI NOTE: Refresh completed on diskgroup XIFENFEI. No voting file found. GMON querying group 4 at 14 for pid 18, osid 39912680 SUCCESS: refreshed membership for 4/0xb08c40b (XIFENFEI) SUCCESS: ALTER DISKGROUP XIFENFEI ADD DISK '/dev/rhdisk29' SIZE 491520M , '/dev/rhdisk30' SIZE 491520M , '/dev/rhdisk31' SIZE 491520M /* ASMCA */
发现增加错磁盘之后,从vg里面强制踢掉被asm使用的磁盘,并且尝试在asm中删除这些磁盘,并加入新磁盘
Fri Nov 22 12:52:03 2019 SQL> ALTER DISKGROUP XIFENFEI DROP DISK 'XIFENFEI_0015','XIFENFEI_0016','XIFENFEI_0017' /* ASMCA */ NOTE: GroupBlock outside rolling migration privileged region Fri Nov 22 12:52:03 2019 NOTE: stopping process ARB0 NOTE: rebalance interrupted for group 4/0xb08c40b (XIFENFEI) NOTE: requesting all-instance membership refresh for group=4 NOTE: membership refresh pending for group 4/0xb08c40b (XIFENFEI) Fri Nov 22 12:52:12 2019 GMON querying group 4 at 15 for pid 18, osid 39912680 SUCCESS: refreshed membership for 4/0xb08c40b (XIFENFEI) SUCCESS: ALTER DISKGROUP XIFENFEI DROP DISK 'XIFENFEI_0015','XIFENFEI_0016','XIFENFEI_0017' /* ASMCA */ NOTE: starting rebalance of group 4/0xb08c40b (XIFENFEI) at power 1 Starting background process ARB0 ………… Fri Nov 22 12:58:26 2019 SQL> ALTER DISKGROUP XIFENFEI ADD DISK '/dev/rhdisk7' SIZE 491520M /* ASMCA */ NOTE: GroupBlock outside rolling migration privileged region Fri Nov 22 12:58:26 2019 NOTE: stopping process ARB0 NOTE: rebalance interrupted for group 4/0xb08c40b (XIFENFEI) NOTE: ASM did background COD recovery for group 4/0xb08c40b (XIFENFEI) NOTE: Assigning number (4,18) to disk (/dev/rhdisk7) NOTE: requesting all-instance membership refresh for group=4 NOTE: initializing header on grp 4 disk XIFENFEI_0018 NOTE: requesting all-instance disk validation for group=4 NOTE: skipping rediscovery for group 4/0xb08c40b (XIFENFEI) on local instance. NOTE: requesting all-instance disk validation for group=4 NOTE: skipping rediscovery for group 4/0xb08c40b (XIFENFEI) on local instance. Fri Nov 22 12:58:41 2019 NOTE: initiating PST update: grp = 4 Fri Nov 22 12:58:41 2019 GMON updating group 4 at 16 for pid 27, osid 12649908 NOTE: PST update grp = 4 completed successfully Fri Nov 22 12:58:41 2019 NOTE: membership refresh pending for group 4/0xb08c40b (XIFENFEI) GMON querying group 4 at 17 for pid 18, osid 39912680 NOTE: cache opening disk 18 of grp 4: XIFENFEI_0018 path:/dev/rhdisk7 NOTE: Attempting voting file refresh on diskgroup XIFENFEI NOTE: Refresh completed on diskgroup XIFENFEI. No voting file found. GMON querying group 4 at 18 for pid 18, osid 39912680 SUCCESS: refreshed membership for 4/0xb08c40b (XIFENFEI) NOTE: starting rebalance of group 4/0xb08c40b (XIFENFEI) at power 1 SUCCESS: ALTER DISKGROUP XIFENFEI ADD DISK '/dev/rhdisk7' SIZE 491520M /* ASMCA */ Starting background process ARB0 Fri Nov 22 12:58:46 2019 ARB0 started with pid=44, OS id=54460432 ………… Fri Nov 22 12:59:57 2019 SQL> ALTER DISKGROUP XIFENFEI ADD DISK '/dev/rhdisk10' SIZE 491520M , '/dev/rhdisk11' SIZE 491520M , '/dev/rhdisk8' SIZE 491520M , '/dev/rhdisk9' SIZE 491520M /* ASMCA */ NOTE: GroupBlock outside rolling migration privileged region Fri Nov 22 12:59:57 2019 NOTE: stopping process ARB0 NOTE: rebalance interrupted for group 4/0xb08c40b (XIFENFEI) NOTE: ASM did background COD recovery for group 4/0xb08c40b (XIFENFEI) NOTE: Assigning number (4,19) to disk (/dev/rhdisk10) NOTE: Assigning number (4,20) to disk (/dev/rhdisk11) NOTE: Assigning number (4,21) to disk (/dev/rhdisk8) NOTE: Assigning number (4,22) to disk (/dev/rhdisk9) NOTE: requesting all-instance membership refresh for group=4 NOTE: initializing header on grp 4 disk XIFENFEI_0019 NOTE: initializing header on grp 4 disk XIFENFEI_0020 NOTE: initializing header on grp 4 disk XIFENFEI_0021 NOTE: initializing header on grp 4 disk XIFENFEI_0022 NOTE: requesting all-instance disk validation for group=4 NOTE: skipping rediscovery for group 4/0xb08c40b (XIFENFEI) on local instance. Fri Nov 22 13:00:08 2019 NOTE: requesting all-instance disk validation for group=4 Fri Nov 22 13:00:08 2019 NOTE: skipping rediscovery for group 4/0xb08c40b (XIFENFEI) on local instance. NOTE: initiating PST update: grp = 4 Fri Nov 22 13:00:13 2019 GMON updating group 4 at 19 for pid 27, osid 12649908 NOTE: PST update grp = 4 completed successfully NOTE: membership refresh pending for group 4/0xb08c40b (XIFENFEI) GMON querying group 4 at 20 for pid 18, osid 39912680 NOTE: cache opening disk 19 of grp 4: XIFENFEI_0019 path:/dev/rhdisk10 NOTE: cache opening disk 20 of grp 4: XIFENFEI_0020 path:/dev/rhdisk11 NOTE: cache opening disk 21 of grp 4: XIFENFEI_0021 path:/dev/rhdisk8 NOTE: cache opening disk 22 of grp 4: XIFENFEI_0022 path:/dev/rhdisk9 NOTE: Attempting voting file refresh on diskgroup XIFENFEI NOTE: Refresh completed on diskgroup XIFENFEI. No voting file found. GMON querying group 4 at 21 for pid 18, osid 39912680 SUCCESS: refreshed membership for 4/0xb08c40b (XIFENFEI) SUCCESS: ALTER DISKGROUP XIFENFEI ADD DISK '/dev/rhdisk10' SIZE 491520M , '/dev/rhdisk11' SIZE 491520M , '/dev/rhdisk8' SIZE 491520M , '/dev/rhdisk9' SIZE 491520M /* ASMCA */ NOTE: starting rebalance of group 4/0xb08c40b (XIFENFEI) at power 1 Starting background process ARB0
asm在做着reblance的过程中遭遇到坏块,直接导致磁盘组dismount
Sun Nov 24 04:42:27 2019
NOTE: group 4 PST updated.
WARNING: cache read a corrupt block: group=4(XIFENFEI) dsk=15 blk=258 disk=15
(XIFENFEI_0015) incarn=1717056824 au=113792 blk=2 count=254
Errors in file /u01/app/oracle/diag/asm/+asm/+ASM2/trace/+ASM2_x000_28639240.trc:
ORA-15196: invalid ASM block header [kfc.c:26368] [endian_kfbh] [2147483663] [258] [56 != 0]
NOTE: a corrupted block from group XIFENFEI was dumped to
/u01/app/oracle/diag/asm/+asm/+ASM2/trace/+ASM2_x000_28639240.trc
WARNING: cache read (retry) a corrupt block: group=4(XIFENFEI)
dsk=15 blk=258 disk=15 (XIFENFEI_0015) incarn=1717056824 au=113792 blk=2 count=1
Errors in file /u01/app/oracle/diag/asm/+asm/+ASM2/trace/+ASM2_x000_28639240.trc:
ORA-15196: invalid ASM block header [kfc.c:26368] [endian_kfbh] [2147483663] [258] [56 != 0]
ORA-15196: invalid ASM block header [kfc.c:26368] [endian_kfbh] [2147483663] [258] [56 != 0]
ERROR: cache failed to read group=4(XIFENFEI) dsk=15 blk=258 from disk(s): 15(XIFENFEI_0015)
ORA-15196: invalid ASM block header [kfc.c:26368] [endian_kfbh] [2147483663] [258] [56 != 0]
ORA-15196: invalid ASM block header [kfc.c:26368] [endian_kfbh] [2147483663] [258] [56 != 0]
NOTE: cache initiating offline of disk 15 group XIFENFEI
NOTE: process _x000_+asm2 (28639240) initiating offline of disk
15.1717056824 (XIFENFEI_0015) with mask 0x7e in group 4
NOTE: initiating PST update: grp = 4, dsk = 15/0x66583538, mask = 0x6a, op = clear
GMON updating disk modes for group 4 at 23 for pid 28, osid 28639240
ERROR: Disk 15 cannot be offlined, since diskgroup has external redundancy.
ERROR: too many offline disks in PST (grp 4)
Sun Nov 24 04:42:27 2019
NOTE: cache dismounting (not clean) group 4/0x0B08C40B (XIFENFEI)
WARNING: Offline for disk XIFENFEI_0015 in mode 0x7f failed.
Sun Nov 24 04:42:27 2019
NOTE: halting all I/Os to diskgroup 4 (XIFENFEI)
NOTE: messaging CKPT to quiesce pins Unix process pid: 59441780, image: oracle@xifenfei2 (B000)
Sun Nov 24 04:42:27 2019
ERROR: ORA-15130 thrown in ARB0 for group number 4
Errors in file /u01/app/oracle/diag/asm/+asm/+ASM2/trace/+ASM2_arb0_50856926.trc:
ORA-15130: diskgroup "XIFENFEI" is being dismounted
至此两个节点的该磁盘组就陷入了不停的mount，然后dismount的轮流循环中.这里我们可以大概的分析出来,由于vg的磁盘组被写入了数据或者强制剔除的时候导致asm写入该文件的数据被破坏,导致后续的asm reblance遭遇坏块,然后直接dismount.对于该问题的解决方案,通过对对该磁盘组的acd和cod进行patch,让其不进行reblance,保持该磁盘组现在,稳定的mount状态,然后对其数据进行备份和重建该磁盘组.这个客户运气不错,vg中的asm disk磁盘写入较少,数据库运行正常.
对于这种情况,如果发生极端损坏,比如asm磁盘组无法mount,可以参考:找回ASM中数据文件
如果是asm的元数据大量损坏,无法通过asm字典级别恢复,可以通过参考:asm disk header 彻底损坏恢复