Exception [type: SIGSEGV, Address not mapped to object] [] [ kgegpa()+36]

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞 标题:Exception [type: SIGSEGV, Address not mapped to object] [] [ kgegpa()+36] 作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]
有朋友找我,由于客户硬件故障,导致控制文件损坏,重建控制文件的时候,由于失误依赖了100多个数据文件,并且进行了resetlogs操作,然后通过bbed修改文件头,再进行恢复,数据库在open过程中报ORA-03113错误
SQL> recover database;
Media recovery complete.
SQL> alter database Open ;
ERROR:
ORA-03113: end-of-file on communication channel
Process ID: 11207284
Session ID: 4537 Serial number: 1
对应的alert日志信息
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Sat Dec 04 23:17:02 2021
SMON: enabling cache recovery
ARC3: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
Sat Dec 04 23:17:03 2021
Exception [type: SIGSEGV, Address not mapped to object][ADDR:0x1604971A0][PC:0x1000E1764,kgegpa()+36][flags:0x0,count:1]
Exception [type: SIGSEGV, Address not mapped to object][ADDR:0x1604971A0][PC:0x1000E1764,kgegpa()+36][flags:0x2,count:2]
Exception [type: SIGSEGV, Address not mapped to object][ADDR:0x1604971A0][PC:0x1000E1764,kgegpa()+36][flags:0x2,count:2]
Sat Dec 04 23:17:07 2021
PMON (ospid: 10879866): terminating the instance due to error 397
Sat Dec 04 23:17:08 2021
System state dump requested by (instance=1, osid=10879866 (PMON)), summary=[abnormal instance termination].
System State dumped to trace file /oracle/app/oracle/diag/rdbms/xff/xff1/trace/xff1_diag_11076320.trc
Dumping diagnostic data in directory=[cdmp_20211204231708], requested by (instance=1, osid=10879866 (PMON)), 
summary=[abnormal instance termination].
Sat Dec 04 23:17:09 2021
ORA-1092 : opitsk aborting process
通过对其启动过程进行跟踪确认在update undo$ 语句中异常
PARSING IN CURSOR #11529215044940435280 len=148 dep=1 uid=0 oct=6 lid=0 tim=223080942765 
hv=3540833987 ad='c000000d67a42778' sqlid='5ansr7r9htpq3'
update undo$ set name=:2,file#=:3,block#=:4,status$=:5,user#=:6,undosqn=:7,xactsqn=:8,
scnbas=:9,scnwrp=:10,inst#=:11,ts#=:12,spare1=:13 where us#=:1
END OF STMT
PARSE #11529215044940435280:c=10000,e=8182,p=6,cr=55,cu=0,mis=1,r=0,dep=1,og=4,plh=0,tim=223080942764
BINDS #11529215044940435280:
 Bind#0
  oacdty=01 mxl=32(20) mxlc=00 mal=00 scl=00 pre=00
  oacflg=18 fl2=0001 frm=01 csi=873 siz=32 off=0
  kxsbbbfp=c000000d5fd299aa  bln=32  avl=20  flg=09
  value="_SYSSMU29_3935275865

quot;  Bind#1   oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00   oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0   kxsbbbfp=9fffffffbcc6e078  bln=24  avl=02  flg=05   value=3  Bind#2   oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00   oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0   kxsbbbfp=9fffffffbcc6e048  bln=24  avl=03  flg=05   value=128  Bind#3   oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00   oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0   kxsbbbfp=9fffffffbcc6e010  bln=24  avl=02  flg=05   value=5  Bind#4   oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00   oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0   kxsbbbfp=9fffffffbcc6dfe0  bln=24  avl=02  flg=05   value=1  Bind#5   oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00   oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0   kxsbbbfp=9fffffffbcc6dfb0  bln=24  avl=04  flg=05   value=28921  Bind#6   oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00   oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0   kxsbbbfp=9fffffffbcc6df80  bln=24  avl=05  flg=05   value=1245262  Bind#7   oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00   oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0   kxsbbbfp=9fffffffbcc6df48  bln=24  avl=06  flg=05   value=1217986655  Bind#8   oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00   oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0   kxsbbbfp=9fffffffbcc6dc90  bln=24  avl=03  flg=05   value=3621  Bind#9   oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00   oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0   kxsbbbfp=9fffffffbcc6dc60  bln=24  avl=01  flg=05   value=0  Bind#10   oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00   oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0   kxsbbbfp=9fffffffbcc6dc30  bln=24  avl=02  flg=05   value=2  Bind#11   oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00   oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0   kxsbbbfp=9fffffffbcc6dc00  bln=24  avl=02  flg=05   value=2  Bind#12   oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00   oacflg=08 fl2=0001 frm=00 csi=00 siz=24 off=0   kxsbbbfp=9fffffffbcc6e0a8  bln=22  avl=02  flg=05   value=1 WAIT #4574659112: nam='db file sequential read' ela= 6835 file#=1 block#=842169 blocks=1 obj#=0 tim=90821816220340
通过分析,确认是由于undo事务异常,通过一系列处理之后,数据库启动报
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00600: internal error code, arguments: [4193], [], [], [], [], [], [], [], [], [], [], []
Process ID: 11206912
Session ID: 4537 Serial number: 1
对应alert日志报错
Successful open of redo thread 1
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Sun Dec 05 02:42:02 2021
SMON: enabling cache recovery
SUCCESS: diskgroup FRA was mounted
Archived Log entry 1 added for thread 1 sequence 1 ID 0x14ba19ad dest 1:
Sun Dec 05 02:42:03 2021
NOTE: dependency between database xff and diskgroup resource ora.FRA.dg is established
Errors in file /oracle/app/oracle/diag/rdbms/xff/xff1/trace/xff1_ora_11206912.trc  (incident=5681243):
ORA-00600: internal error code, arguments: [4193], [], [], [], [], [], [], [], [], [], [], []
Incident details in: /oracle/app/oracle/diag/rdbms/xff/xff1/incident/incdir_5681243/xff1_ora_11206912_i5681243.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
ARC3: Archival started
ARC0: STARTING ARCH PROCESSES COMPLETE
Sun Dec 05 02:42:05 2021
Dumping diagnostic data in directory=[cdmp_20211205024205], requested by (instance=1, osid=11206912), 
summary=[incident=5681243].
Sun Dec 05 02:42:05 2021
Block recovery from logseq 2, block 3 to scn 13867049493730
Recovery of Online Redo Log: Thread 1 Group 2 Seq 2 Reading mem 0
  Mem# 0: +DATA/xff/onlinelog/group_2.log
Block recovery stopped at EOT rba 2.5.16
Block recovery completed at rba 2.5.16, scn 3228.2895062240
Block recovery from logseq 2, block 3 to scn 13867049493727
Recovery of Online Redo Log: Thread 1 Group 2 Seq 2 Reading mem 0
  Mem# 0: +DATA/xff/onlinelog/group_2.log
Block recovery completed at rba 2.5.16, scn 3228.2895062240
Errors in file /oracle/app/oracle/diag/rdbms/xff/xff1/trace/xff1_ora_11206912.trc:
ORA-00600: internal error code, arguments: [4193], [], [], [], [], [], [], [], [], [], [], []
Errors in file /oracle/app/oracle/diag/rdbms/xff/xff1/trace/xff1_ora_11206912.trc:
ORA-00600: internal error code, arguments: [4193], [], [], [], [], [], [], [], [], [], [], []
Error 600 happened during db open, shutting down database
USER (ospid: 11206912): terminating the instance due to error 600
Instance terminated by USER, pid = 11206912
ORA-1092 signalled during: alter database open...
opiodr aborting process unknown ospid (11206912) as a result of ORA-1092
Sun Dec 05 02:42:07 2021
ORA-1092 : opitsk aborting process
trace中关键信息和bbed对看到结果对应,通过bbed处理,数据库启动正常
    uba: 0x004cd9b9.02fb.0c ext: 0x19 spc: 0x1462
    uba: 0x00000000.02fb.02 ext: 0x19 spc: 0x1f06
    uba: 0x00000000.02fb.0d ext: 0x19 spc: 0x1970
    uba: 0x00000000.02fa.03 ext: 0x18 spc: 0x1e34
    uba: 0x00000000.02fa.03 ext: 0x18 spc: 0x1e34

   struct ktuxcfbp[0], 12 bytes             @4192    
      struct ktufbuba, 8 bytes              @4192    
         ub4 kubadba                        @4192     0x004cd9b9
         ub2 kubaseq                        @4196     0x02fb
         ub1 kubarec                        @4198     0x0c
      sb2 ktufbext                          @4200     25
      sb2 ktufbspc                          @4202     5218
以前有过类似恢复硬件恢复之后,数据库无法open故障恢复

校验代码为 6054 坏块故障修复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:校验代码为 6054 坏块故障修复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

有客户反馈数据库操作报错,希望我们给予处理,报错信息如下:
20211204223138


通过对system01.dbf数据文件分析

C:\Users\XFF>dbv file=H:\BAIDUNETDISK\GS6.0BAK20211202\SYSTEM01.DBF

DBVERIFY: Release 11.2.0.4.0 - Production on 星期六 12月 4 20:45:23 2021

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

DBVERIFY - 开始验证: FILE = H:\BAIDUNETDISK\GS6.0BAK20211202\SYSTEM01.DBF

DBV-00200: 块 DBA 4330012 已标记为损坏
csc(0x0000.1686df22) higher than block scn(0x0000.00000000)
页 135708 失败, 校验代码为 6054


DBVERIFY - 验证完成

检查的页总数: 184320
处理的页总数 (数据): 93105
失败的页总数 (数据): 0
处理的页总数 (索引): 31365
失败的页总数 (索引): 1
处理的页总数 (其他): 43622
处理的总页数 (段)  : 1
失败的总页数 (段)  : 0
空的页总数: 16228
标记为损坏的总页数: 1
流入的页总数: 0
加密的总页数        : 0
最高块 SCN            : 378591519 (0.378591519)

确认block 135708 有问题,确认起对象为I_OBJ5

SQL> SELECT OWNER, SEGMENT_NAME, SEGMENT_TYPE, TABLESPACE_NAME, A.PARTITION_NAME
  2    FROM DBA_EXTENTS A
  3   WHERE FILE_ID = &FILE_ID
  4     AND &BLOCK_ID BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1;
输入 file_id 的值:  1
原值    3:  WHERE FILE_ID = &FILE_ID
新值    3:  WHERE FILE_ID = 1
输入 block_id 的值:  135708
原值    4:    AND &BLOCK_ID BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1
新值    4:    AND 135708 BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1

OWNER                          SEGMENT_NAME    SEGMENT_TYPE       TABLESPACE_NAME                PARTITION_NAME
------------------------------ --------------- ------------------ ------------------------------ -----------------
SYS                            I_OBJ5          INDEX
                    SYSTEM

这个对象为核心对象obj$的index,无法直接rebuild,当然可以通过参考以前blog文档进行重建:bootstrap$核心index(I_OBJ1,I_USER1,I_FILE#_BLOCK#,I_IND1,I_TS#,I_CDEF1等)异常恢复—ORA-00701错误解决,直接对该坏块进行修复.

BBED> p kcbh
struct kcbh, 20 bytes                       @0
   ub1 type_kcbh                            @0        0x06
   ub1 frmt_kcbh                            @1        0xa2
   ub1 spare1_kcbh                          @2        0x00
   ub1 spare2_kcbh                          @3        0x00
   ub4 rdba_kcbh                            @4        0x0042121c
   ub4 bas_kcbh                             @8        0x00000000
   ub2 wrp_kcbh                             @12       0x0000
   ub1 seq_kcbh                             @14       0xff
   ub1 flg_kcbh                             @15       0x04 (KCBHFCKV)
   ub2 chkval_kcbh                          @16       0xe8c4
   ub2 spare3_kcbh                          @18       0x0000

BBED> m /x 23df8616
 File: H:\BAIDUNETDISK\GS6.0BAK20211202\SYSTEM01.DBF (0)
 Block: 135709           Offsets:    8 to  519           Dba:0x00000000
------------------------------------------------------------------------
 23df8616 00000104 44fe0000 02000000 28000000 22df8616 00000000 02000200
 00000000 0a001800 f7dc1b00 8002c000 bdd80100 00e00000 f331b114 0a001f00
 14081e00 4505c000 2c103b00 01200000 2adf8616 00008009 01000000 3f00a200
 35074010 00000000 e1b24100 56694100 06000000 641f0000 57119211 cd11d208
 97080812 43127e12 b912f412 2f130d09 e013bd09 1b14cc14 0715ab07 5c087d15
 b715f215 a3167007 3507de16 19175417 21088f17 ca170518 4018330a 1f0b7b18
 2c196719 a219dd19 181a531a 8e1a4709 031be607 f809791b b41bef1b 2a1c651c
 db1ce20d 8c1d310d c71d021e 3d1e781e b31e8209 291f291f 291f291f 291f291f
 291f291f 291f0000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

 <32 bytes per line>

然后dbv报以下错误

C:\Users\XFF>dbv file=H:\BAIDUNETDISK\GS6.0BAK20211202\SYSTEM01.DBF

DBVERIFY: Release 11.2.0.4.0 - Production on 星期六 12月 4 22:06:49 2021

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

DBVERIFY - 开始验证: FILE = H:\BAIDUNETDISK\GS6.0BAK20211202\SYSTEM01.DBF
itl[2] has higher commit scn(0x0000.1686df2a) than block scn (0x0000.1686df23)
页 135708 失败, 校验代码为 6056


DBVERIFY - 验证完成

检查的页总数: 184320
处理的页总数 (数据): 95152
失败的页总数 (数据): 0
处理的页总数 (索引): 34569
失败的页总数 (索引): 1
处理的页总数 (其他): 38386
处理的总页数 (段)  : 1
失败的总页数 (段)  : 0
空的页总数: 16213
标记为损坏的总页数: 0
流入的页总数: 0
加密的总页数        : 0
最高块 SCN            : 378683101 (0.378683101)

再次对其进行修复

BBED> m /x 22df8616
 File: H:\BAIDUNETDISK\GS6.0BAK20211202\SYSTEM01.DBF (0)
 Block: 135709           Offsets:   88 to  599           Dba:0x00000000
------------------------------------------------------------------------
 22df8616 00008009 01000000 3f00a200 35074010 00000000 e1b24100 56694100
 06000000 641f0000 57119211 cd11d208 97080812 43127e12 b912f412 2f130d09
 e013bd09 1b14cc14 0715ab07 5c087d15 b715f215 a3167007 3507de16 19175417
 21088f17 ca170518 4018330a 1f0b7b18 2c196719 a219dd19 181a531a 8e1a4709
 031be607 f809791b b41bef1b 2a1c651c db1ce20d 8c1d310d c71d021e 3d1e781e
 b31e8209 291f291f 291f291f 291f291f 291f291f 291f0000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000

 <32 bytes per line>

再次dbv检查修复成功

C:\Users\XFF>dbv file=H:\BAIDUNETDISK\GS6.0BAK20211202\SYSTEM01.DBF

DBVERIFY: Release 11.2.0.4.0 - Production on 星期六 12月 4 22:30:14 2021

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

DBVERIFY - 开始验证: FILE = H:\BAIDUNETDISK\GS6.0BAK20211202\SYSTEM01.DBF


DBVERIFY - 验证完成

检查的页总数: 184320
处理的页总数 (数据): 95152
失败的页总数 (数据): 0
处理的页总数 (索引): 34569
失败的页总数 (索引): 0
处理的页总数 (其他): 38386
处理的总页数 (段)  : 1
失败的总页数 (段)  : 0
空的页总数: 16213
标记为损坏的总页数: 0
流入的页总数: 0
加密的总页数        : 0
最高块 SCN            : 378683101 (0.378683101)

对于这类的坏块,也可以通过我们的Oracle recovery tools进行快速恢复
20211204225050


数据库文件被勒索改名数据库恢复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:数据库文件被勒索改名数据库恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

做一个oracle数据库被加密,所有数据文件名称全部被重命名,类似
20211126142645


分析文件破坏情况
20211126144109

通过分析文件头1278个block被加密破坏,在没有文件名正确文件名,而且文件头大量损坏的情况下,一般的恢复工具都无法正常进行恢复,基于这种情况,使用自己开发的小工具进行分析修复恢复
20211126143741

然后快速恢复客户要的相关核心表数据
20211126144547

对于这种加密破坏较多,而且数据文件被勒索病毒修改名称,无法使用一般工具进行恢复的,可以联系我们进行核心数据恢复
电话/微信:17813235971    Q Q:107644445QQ咨询惜分飞    E-Mail:dba@xifenfei.com

.makop加密数据库恢复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:.makop加密数据库恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

接到一起sql server数据库被勒索病毒加密恢复请求
20211124162221


通过分析,数据库加密损坏部分较少,可以对其进行恢复
20211124163701

通过技术处理,表数据正常恢复
20211124164656
如果此类的数据库(oracle,mysql,sql server)等被加密,需要专业恢复技术支持,请联系我们:
电话/微信:17813235971    Q Q:107644445QQ咨询惜分飞    E-Mail:dba@xifenfei.com

.eking加密数据库恢复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:.eking加密数据库恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

接到一个客户的oracle数据文件被加密的恢复请求,文件被加密为扩展名为:.id[76B8C076-3009].[decrypt20@firemail.cc].eking,通过底层分析,确认该文件被加密破坏较少
20211124155338


通过自研的工具对数据文件进行恢复
20211124154524

实现数据库正常open,并使用exp进行导出
20211124161434

如果此类的数据库(oracle,mysql,sql server)等被加密,需要专业恢复技术支持,请联系我们:
电话/微信:17813235971    Q Q:107644445QQ咨询惜分飞    E-Mail:dba@xifenfei.com