有客户oracle数据库文件被加密,后缀名为:.z33m8rvi,txt文件内容如下
加密的数据文件为:
通过分析文件,我们判断这种加密情况,数据文件中所有数据均可恢复,通过对文件进行恢复之后,数据库直接打开,数据正常导出
如果您遇到此类加密情况,无法解决请联系我们,提供专业ORACLE数据库恢复技术支持
Phone:17813235971 Q Q:107644445 E-Mail:dba@xifenfei.com
有客户oracle数据库文件被加密,后缀名为:.z33m8rvi,txt文件内容如下
有客户和我们反馈,由于运维人员操作错误,对一个磁盘组的asm disk进行了dd操作,导致部分数据丢失(客户数据文件存放在两个磁盘组中,其中一个被dd掉[误以为只是存放归档,其实由于第一个磁盘组空间不足,把部分数据文件放进该磁盘组])
Sun Mar 14 05:25:40 CST 2020 NOTE: F1X0 found on disk 0 fcn 0.60289025 NOTE: cache opening disk 0 of grp 2: HIS_FLASH00 label:HIS_FLASH00 NOTE: cache opening disk 1 of grp 2: HIS_FLASH01 label:HIS_FLASH01 NOTE: cache opening disk 2 of grp 2: HIS_FLASH02 label:HIS_FLASH02 NOTE: cache opening disk 3 of grp 2: HIS_DATA03 label:HIS_DATA03 NOTE: cache mounting (first) group 2/0xCCD84BCB (HIS_FLASH) * allocate domain 2, invalid = TRUE kjbdomatt send to node 0 Sun Mar 14 05:25:40 CST 2020 NOTE: attached to recovery domain 2 Sun Mar 14 05:25:40 CST 2020 NOTE: starting recovery of thread=1 ckpt=405.816 group=2 NOTE: advancing ckpt for thread=1 ckpt=405.819 NOTE: cache recovered group 2 to fcn 0.65493064 Sun Mar 14 05:25:40 CST 2020 NOTE: LGWR attempting to mount thread 1 for disk group 2 NOTE: LGWR mounted thread 1 for disk group 2 NOTE: opening chunk 1 at fcn 0.65493064 ABA NOTE: seq=406 blk=820 Sun Mar 14 05:25:40 CST 2020 NOTE: cache mounting group 2/0xCCD84BCB (HIS_FLASH) succeeded SUCCESS: diskgroup HIS_FLASH was mounted Sun Mar 14 05:25:42 CST 2020 NOTE: recovering COD for group 2/0xccd84bcb (HIS_FLASH) SUCCESS: completed COD recovery for group 2/0xccd84bcb (HIS_FLASH) Sun Mar 14 05:25:47 CST 2020 Starting background process ASMB ASMB started with pid=17, OS id=14599
初步可以定位,很可能是由于在3月份对该磁盘组进行了扩容,从而发生了数据文件的rebalance操作,从而出现了某些block有重复现象,对于这类情况,通过结合asm字典信息进行分析可以完全规避该问题,对数据文件进行恢复,dbv进行检查,一切正常
有一个客户找到我们,说他们是数据库启动之时报的错误和数据库不能open 报ORA-7445 lmebucp错类似,让我们对其进行恢复支持,通过分析确定客户数据库版本为12.2.0.1
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Productio PL/SQL Release 12.2.0.1.0 - Production CORE 12.2.0.1.0 Production TNS for Linux: Version 12.2.0.1.0 - Production NLSRTL Version 12.2.0.1.0 - Production
alert日志报错
--最初报错 2020-05-11T03:43:06.787164+08:00 Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_m004_3253.trc (incident=639048): ORA-00600: 内部错误代码, 参数: [kkpo_rcinfo_defstg:delseg], [72280], [], [], [], [], [], [], [], [], [], [] Incident details in: /u01/app/oracle/diag/rdbms/orcl/orcl/incident/incdir_639048/orcl_m004_3253_i639048.trc Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. 2020-05-11T03:43:14.250993+08:00 Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_m004_3253.trc (incident=639049): ORA-00600: 内部错误代码, 参数: [kkpo_rcinfo_defstg:delseg], [72280], [], [], [], [], [], [], [], [], [], [] Incident details in: /u01/app/oracle/diag/rdbms/orcl/orcl/incident/incdir_639049/orcl_m004_3253_i639049.trc 2020-05-11T03:43:21.286310+08:00 Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_m004_3253.trc (incident=639050): ORA-00600: 内部错误代码, 参数: [kkpo_rcinfo_defstg:delseg], [72280], [], [], [], [], [], [], [], [], [], [] ORA-06512: 在 line 2 Incident details in: /u01/app/oracle/diag/rdbms/orcl/orcl/incident/incdir_639050/orcl_m004_3253_i639050.trc 2020-05-11T03:43:28.059048+08:00 Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. 2020-05-11T03:43:28.074681+08:00 Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_m004_3253.trc: ORA-00600: 内部错误代码, 参数: [kkpo_rcinfo_defstg:delseg], [72280], [], [], [], [], [], [], [], [], [], [] ORA-06512: 在 line 2 2020-05-11T08:31:22.416087+08:00 Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_j000_16511.trc: ORA-12012: 自动执行作业 141 出错 ORA-30732: 表中不包含用户可见的列 ORA-06512: 在 line 1 ---关闭数据库之后重启报错 2020-05-11T09:42:43.234769+08:00 ALTER DATABASE OPEN 2020-05-11T09:42:44.353085+08:00 Ping without log force is disabled: instance mounted in exclusive mode. Endian type of dictionary set to little 2020-05-11T09:42:44.660388+08:00 TT00: Gap Manager starting (PID:31134) 2020-05-11T09:42:45.180876+08:00 Thread 1 opened at log sequence 78596 Current log# 2 seq# 78596 mem# 0: /u01/app/oracle/oradata/orcl/redo02.log Successful open of redo thread 1 2020-05-11T09:42:45.181357+08:00 MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set Exception [type: SIGSEGV, Address not mapped to object][ADDR:0x0][PC:0x10F4C112, lmebucp()+34][flags: 0x0, count: 1] Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_31125.trc (incident=646445): ORA-07445: exception encountered:core dump[lmebucp()+34][SIGSEGV][ADDR:0x0][PC:0x10F4C112][Address not mapped to object] Incident details in: /u01/app/oracle/diag/rdbms/orcl/orcl/incident/incdir_646445/orcl_ora_31125_i646445.trc Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. 2020-05-11T09:42:46.070049+08:00 ***************************************************************** An internal routine has requested a dump of selected redo. This usually happens following a specific internal error, when analysis of the redo logs will help Oracle Support with the diagnosis. It is recommended that you retain all the redo logs generated (by all the instances) during the past 12 hours, in case additional redo dumps are required to help with the diagnosis. ***************************************************************** 2020-05-11T09:42:53.344955+08:00 Instance Critical Process (pid: 41, ospid: 31125) died unexpectedly PMON (ospid: 31026): terminating the instance due to error 12752 2020-05-11T09:42:53.377209+08:00 System state dump requested by (instance=1, osid=31026 (PMON)), summary=[abnormal instance termination]. System State dumped to trace file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_diag_31046_20200511094253.trc 2020-05-11T09:42:56.690224+08:00 Instance terminated by PMON, pid = 31026
对启动过程做10046跟踪
PARSING IN CURSOR #139821999713040 len=65 dep=1 uid=0 oct=3 lid=0 tim=2200910467 hv=1762642493 ad='1bfd79130'sqlid='aps3qh1nhzkjx' select line#, sql_text from bootstrap$ where obj# not in (:1, :2) END OF STMT PARSE #139821999713040:c=378,e=378,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,plh=0,tim=2200910467 BINDS #139821999713040: Bind#0 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=08 fl2=1000001 frm=00 csi=00 siz=24 off=0 kxsbbbfp=7f2ad89fe6c8 bln=22 avl=02 flg=05 value=59 Bind#1 oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00 oacflg=08 fl2=1000001 frm=00 csi=00 siz=24 off=0 kxsbbbfp=7f2ad89fe698 bln=24 avl=06 flg=05 value=4294967295 EXEC #139821999713040:c=219,e=658,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,plh=867914364,tim=2200911218 WAIT #139821999713040: nam='db file sequential read' ela= 9 file#=1 block#=520 blocks=1 obj#=59 tim=2200911300 WAIT #139821999713040: nam='db file scattered read' ela= 19 file#=1 block#=521 blocks=3 obj#=59 tim=2200911559 FETCH #139821999713040:c=404,e=404,p=4,cr=5,cu=0,mis=0,r=0,dep=1,og=4,plh=867914364,tim=2200911646 STAT #139821999713040 id=1 cnt=0 pid=0 pos=1 obj=59 op='TABLE ACCESS FULL BOOTSTRAP$ (cr=5 pr=4 pw=0 str=1 time=406 us)' *** 2020-05-11T12:25:30.977832+08:00 Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x0] [PC:0x10F4C112, lmebucp()+34] [flags: 0x0, count: 1] 2020-05-11T12:25:31.026914+08:00 Incident 718445 created, dump file:/u01/app/oracle/diag/rdbms/orcl/orcl/incident/incdir_718445/orcl_ora_14324_i718445.trc ORA-07445: exception encountered:core dump [lmebucp()+34][SIGSEGV][ADDR:0x0][PC:0x10F4C112][Address not mapped to object]
根据该报错,可以大概定位数据库重启之后报ORA-07445 lmebucp()+34错误不能正常启动是由于bootstrap$表异常导致.
BBED> p kcvfhrdb ub4 kcvfhrdb @96 0x00400208 BBED> set block 523 BLOCK# 523 BBED> map File: F:\temp\12.2\1\system01.dbf (0) Block: 523 Dba:0x00000000 ------------------------------------------------------------ KTB Data Block (Table/Cluster) struct kcbh, 20 bytes @0 struct ktbbh, 48 bytes @20 struct kdbh, 14 bytes @68 struct kdbt[1], 4 bytes @82 sb2 kdbr[20] @86 ub1 freespace[1015] @126 ub1 rowdata[7047] @1141 ub4 tailchk @8188 BBED> p *kdbr[1] rowdata[6431] ------------- ub1 rowdata[6431] @7572 0x3c BBED> x /rnnc rowdata[6431] @7572 ------------- flag@7572: 0x3c (KDRHFL, KDRHFF, KDRHFD, KDRHFH) lock@7573: 0x01 cols@7574: 0
通过bbed定位rootdba,然后dump相关block,随机找一条记录,确认bootstrap表无后效记录.但是该数据库在重启之前已经报了ORA-600 kkpo_rcinfo_defstg:delseg和ORA-30732错误,很可能还有其他的基表异常.通过先修复bootstrap$记录,然后根据该表中记录分析其他相关表记录,最终确定tab$中记录也异常,通过bbed 批量循环修复方法,对其进行恢复,open数据库,可以验证数据没有问题.至此该问题解决,但是没有找出来故障原因(是人为破坏【直接人工删除】,还是某种工具带入恶意脚本导致,类似:plsql dev引起的数据库被黑勒索比特币实现原理分析和解决方案,亦或者是数据库安装介质带有恶意程序,类似:警告:互联网中有oracle介质被注入恶意程序导致—ORA-600 16703)
17813235971 |
QQ 咨询 |