故障处理：redo损坏利用隐藏参数强制open报错ORA-07445

我们的文章会在微信公众号IT民工的龙马人生和博客网站( www.htz.pw )同步更新 ，欢迎关注收藏，也欢迎大家转载，但是请在文章开始地方标注文章出处，谢谢！
由于博客中有大量代码，通过页面浏览效果更佳。

本文转自朋友的真实案例分享。

案例：redo损坏利用隐藏参数强制open报错ORA-07445

本案例来自西区某客户，数据库版本为11.2.0.1，由于redo损坏需要通过隐藏参数“_allow_resetlogs_corruption”=true来强制open数据库，但是在启动过程中，报错ORA-07445。具体报错为：

SMON: enabling cache recovery
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x41CE1224] [PC:0x2297750, kgegpa()+40] [flags: 0x0, count: 1]
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x41CE1224] [PC:0x229597B, kgebse()+279] [flags: 0x2, count: 2]
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x41CE1224] [PC:0x229597B, kgebse()+279] [flags: 0x2, count: 2]
Fri Aug 05 23:16:29 2022
PMON (ospid: 23557): terminating the instance due to error 397
Instance terminated by PMON, pid = 23557

通过10046跟踪open过程：

PARSING IN CURSOR #4 len=148 dep=1 uid=0 oct=6 lid=0 tim=1659715679553876 hv=3540833987 ad='7f91db10' 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 #4:c=10998,e=10789,p=7,cr=53,cu=0,mis=1,r=0,dep=1,og=4,plh=0,tim=1659715679553875
BINDS #4:
 Bind#0
  oacdty=01 mxl=32(19) mxlc=00 mal=00 scl=00 pre=00
  oacflg=18 fl2=0001 frm=01 csi=873 siz=32 off=0
  kxsbbbfp=7f91e56a  bln=32  avl=19  flg=09
  value="_SYSSMU1_547241589$"
 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=7fb700badea0  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=7fb700bade70  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=7fb700bade40  bln=24  avl=02  flg=05
  value=2
 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=7fb700bade10  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=7fb700badde0  bln=24  avl=03  flg=05
  value=4571
 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=7fb700baddb0  bln=24  avl=05  flg=05
  value=1849380
 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=7fb700badd80  bln=24  avl=06  flg=05
  value=2782784391
 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=7fb700badd50  bln=24  avl=03  flg=05
  value=3980
 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=7fb700badd20  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=7fb700bc5fe8  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=7fb700bc5fb8  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=7fb700baded0  bln=22  avl=02  flg=05
  value=1
WAIT #4: nam='db file sequential read' ela= 18 file#=1 block#=541 blocks=1 obj#=0 tim=1659715679555587
 
*** 2022-08-06 00:07:59.555
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x41CE1224] [PC:0x2297750, kgegpa()+40] [flags: 0x0, count: 1]
DDE previous invocation failed before phase II
DDE was called in a 'No Invocation Mode'
----- Start Diag Diagnostic Dump -----
Diag diagnostic dump is performed due to an error in the diagfw code during error handling.
DDE is switched to protected mode during the diagnostic dump to prevent recursive errors in the error hadnling code.
Dump error and call stack for the diagnostic dump:
 
*** 2022-08-06 00:07:59.563
dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x0, level=1, mask=0x0)
----- Error Stack Dump -----
 
*** 2022-08-06 00:07:59.563
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x41CE1224] [PC:0x229597B, kgebse()+279] [flags: 0x2, count: 2]
Not recording an ORA-7445 (previous attmpet failed)
Warning! DDE is invoked in protected mode. DDE call is aborted.
Warning! DDE is invoked in protected mode. DDE call is aborted.
 
*** 2022-08-06 00:07:59.565
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x41CE1224] [PC:0x229597B, kgebse()+279] [flags: 0x2, count: 2]
Not recording an ORA-7445 (previous attmpet failed)
ssexhd: crashing the process...
Shadow_Core_Dump = partial

发现报错的sql为update undo$，在读取1号文件541号文件之后开始报错。

BBED> set block 541
        BLOCK#          541
 
BBED> map /v
 File: /data/oracle/VOC/VOC/system01.dbf (0)
 Block: 541                                   Dba:0x00000000
------------------------------------------------------------
 Undo Data
 
 struct kcbh, 20 bytes                      @0
    ub1 type_kcbh                           @0
    ub1 frmt_kcbh                           @1
    ub1 spare1_kcbh                         @2
    ub1 spare2_kcbh                         @3
    ub4 rdba_kcbh                           @4
    ub4 bas_kcbh                            @8
    ub2 wrp_kcbh                            @12
    ub1 seq_kcbh                            @14
    ub1 flg_kcbh                            @15
    ub2 chkval_kcbh                         @16
    ub2 spare3_kcbh                         @18
 
 struct ktubh, 74 bytes                     @20
    struct ktubhxid, 8 bytes                @20
    ub2 ktubhseq                            @28
    ub1 ktubhcnt                            @30
    ub1 ktubhirb                            @31
    ub1 ktubhicl                            @32
    ub1 ktubhflg                            @33
    ub2 ktubhidx[30]                        @34
 
 ub1 freespace[174]                         @94
 
 ub1 undodata[7920]                         @268
 
 ub4 tailchk                                @8188

1号文件的block 541是undo block，我们知道system表空间只有一个undo段为system。该block属于system undo段的一个undo块，那么update undo$为什么会去访问这个undo块呢？

第一种可能性是需要undo块构造一致性读，但是用bbed读取了几个块，发现在推进了scn的情况下并不需要undo块来构造一致性读，那么这很可能与为事务分配undo块有关，当事务绑定undo段之后，会从undo段头块的free block pool中去获取undo块。

BBED> set block 128
        BLOCK#          128
 
BBED> map /v
 File: /data/oracle/VOC/VOC/system01.dbf (0)
 Block: 128                                   Dba:0x00000000
------------------------------------------------------------
 Unlimited Undo Segment Header
 
 struct kcbh, 20 bytes                      @0
    ub1 type_kcbh                           @0
    ub1 frmt_kcbh                           @1
    ub1 spare1_kcbh                         @2
    ub1 spare2_kcbh                         @3
    ub4 rdba_kcbh                           @4
    ub4 bas_kcbh                            @8
    ub2 wrp_kcbh                            @12
    ub1 seq_kcbh                            @14
    ub1 flg_kcbh                            @15
    ub2 chkval_kcbh                         @16
    ub2 spare3_kcbh                         @18
 
 struct ktech, 72 bytes                     @20
    ub4 spare1_ktech                        @20
    sword tsn_ktech                         @24
    ub4 lastmap_ktech                       @28
    ub4 mapcount_ktech                      @32
    ub4 extents_ktech                       @36
    ub4 blocks_ktech                        @40
    ub2 mapend_ktech                        @44
    struct hwmark_ktech, 32 bytes           @48
    struct locker_ktech, 8 bytes            @80
    ub4 flag_ktech                          @88
 
 struct ktemh, 16 bytes                     @92
    ub4 count_ktemh                         @92
    ub4 next_ktemh                          @96
    ub4 obj_ktemh                           @100
    ub4 flag_ktemh                          @104
 
 struct ktetb[6], 48 bytes                  @108
    ub4 ktetbdba                            @108
    ub4 ktetbnbk                            @112
 
 struct ktuxc, 104 bytes                    @4148
    struct ktuxcscn, 8 bytes                @4148
    struct ktuxcuba, 8 bytes                @4156
    sb2 ktuxcflg                            @4164
    ub2 ktuxcseq                            @4166
    sb2 ktuxcnfb                            @4168
    ub4 ktuxcinc                            @4172
    sb2 ktuxcchd                            @4176
    sb2 ktuxcctl                            @4178
    ub2 ktuxcmgc                            @4180
    ub4 ktuxcopt                            @4188
    struct ktuxcfbp[5], 60 bytes            @4192
 
 struct ktuxe[255], 10200 bytes             @4252
    ub4 ktuxexid                            @4252
    ub4 ktuxebrb                            @4256
    struct ktuxescn, 8 bytes                @4260
    sb4 ktuxesta                            @4268
    ub1 ktuxecfl                            @4269
    sb2 ktuxeuel                            @4270
 
 ub4 tailchk                                @8188
 
BBED> p ktuxcfbp
struct ktuxcfbp[0], 12 bytes                @4192
   struct ktufbuba, 8 bytes                 @4192
      ub4 kubadba                           @4192     0x0040021d
      ub2 kubaseq                           @4196     0x0069
      ub1 kubarec                           @4198     0x10
   sb2 ktufbext                             @4200     3
   sb2 ktufbspc                             @4202     3734
struct ktuxcfbp[1], 12 bytes                @4204
   struct ktufbuba, 8 bytes                 @4204
      ub4 kubadba                           @4204     0x00000000
      ub2 kubaseq                           @4208     0x0032
      ub1 kubarec                           @4210     0x07
   sb2 ktufbext                             @4212     2
   sb2 ktufbspc                             @4214     7124
struct ktuxcfbp[2], 12 bytes                @4216
   struct ktufbuba, 8 bytes                 @4216
      ub4 kubadba                           @4216     0x00000000
      ub2 kubaseq                           @4220     0x0032
      ub1 kubarec                           @4222     0x22
   sb2 ktufbext                             @4224     2
   sb2 ktufbspc                             @4226     2418
struct ktuxcfbp[3], 12 bytes                @4228
   struct ktufbuba, 8 bytes                 @4228
      ub4 kubadba                           @4228     0x00000000
      ub2 kubaseq                           @4232     0x0029
      ub1 kubarec                           @4234     0x0b
   sb2 ktufbext                             @4236     5
   sb2 ktufbspc                             @4238     6944
struct ktuxcfbp[4], 12 bytes                @4240
   struct ktufbuba, 8 bytes                 @4240
      ub4 kubadba                           @4240     0x00000000
      ub2 kubaseq                           @4244     0x0000
      ub1 kubarec                           @4246     0x00
   sb2 ktufbext                             @4248     0
   sb2 ktufbspc                             @4250     0

可以看到system undo段的free block pool中存在1个块，rdba为0x0040021d，正好就是1号文件541号块，那么处理该问题就非常简单了，清空free block pool，让system undo段重新分配undo块即可。

BBED> m /x 00000000 offset 4192
 File: /data/oracle/VOC/VOC/system01.dbf (0)
 Block: 128              Offsets: 4192 to 4703           Dba:0x00000000
------------------------------------------------------------------------
 00000000 69001000 0300960e 00000000 32000700 0200d41b 00000000 32002200
 02007209 00000000 29000b00 0500201b 00000000 00000000 00000000 ce000000
 1b024000 a76139cf 8c0f0000 09000800 00000000 00000000 00000000 01000000
 00000000 ce000000 1b024000 da654acf 8c0f0000 09000c00 00000000 00000000
 00000000 01000000 00000000 ce000000 1b024000 da2138cf 8c0f0000 09001100
 00000000 00000000 00000000 01000000 00000000 ce000000 1b024000 4ea45acf
 8c0f0000 09001200 00000000 00000000 00000000 01000000 00000000 ce000000
 1b024000 d93038cf 8c0f0000 09000d00 00000000 00000000 00000000 01000000
 00000000 ce000000 1b024000 1a2c4dcf 8c0f0000 09000300 00000000 00000000
 00000000 01000000 00000000 ce000000 1b024000 288e2bcf 8c0f0000 09000900
 00000000 00000000 00000000 01000000 00000000 ce000000 1c024000 d61e5bcf
 8c0f0000 09001b00 00000000 00000000 00000000 01000000 00000000 ce000000
 1b024000 a86139cf 8c0f0000 09001800 00000000 00000000 00000000 01000000
 00000000 ce000000 1b024000 2a8e2bcf 8c0f0000 09000200 00000000 00000000
 00000000 01000000 00000000 ce000000 1b024000 8e9f27cf 8c0f0000 09006000
 00000000 00000000 00000000 01000000 00000000 ce000000 1c024000 031b5ccf
 
 <32 bytes per line>
 
BBED> sum apply
Check value for File 0, Block 128:
current = 0x80f2, required = 0x80f2
 
BBED> p ktuxcnfb
sb2 ktuxcnfb                                @4168     1
 
BBED> m /x 00 offset 4168
 File: /data/oracle/VOC/VOC/system01.dbf (0)
 Block: 128              Offsets: 4168 to 4679           Dba:0x00000000
------------------------------------------------------------------------
 00000000 00000000 3d003600 02800100 68000000 feffff7f 00000000 69001000
 0300960e 00000000 32000700 0200d41b 00000000 32002200 02007209 00000000
 29000b00 0500201b 00000000 00000000 00000000 ce000000 1b024000 a76139cf
 8c0f0000 09000800 00000000 00000000 00000000 01000000 00000000 ce000000
 1b024000 da654acf 8c0f0000 09000c00 00000000 00000000 00000000 01000000
 00000000 ce000000 1b024000 da2138cf 8c0f0000 09001100 00000000 00000000
 00000000 01000000 00000000 ce000000 1b024000 4ea45acf 8c0f0000 09001200
 00000000 00000000 00000000 01000000 00000000 ce000000 1b024000 d93038cf
 8c0f0000 09000d00 00000000 00000000 00000000 01000000 00000000 ce000000
 1b024000 1a2c4dcf 8c0f0000 09000300 00000000 00000000 00000000 01000000
 00000000 ce000000 1b024000 288e2bcf 8c0f0000 09000900 00000000 00000000
 00000000 01000000 00000000 ce000000 1c024000 d61e5bcf 8c0f0000 09001b00
 00000000 00000000 00000000 01000000 00000000 ce000000 1b024000 a86139cf
 8c0f0000 09001800 00000000 00000000 00000000 01000000 00000000 ce000000
 1b024000 2a8e2bcf 8c0f0000 09000200 00000000 00000000 00000000 01000000
 00000000 ce000000 1b024000 8e9f27cf 8c0f0000 09006000 00000000 00000000
 
 <32 bytes per line>
 
BBED> sum apply
Check value for File 0, Block 128:
current = 0x80f3, required = 0x80f3

修改之后重新启动数据库成功。

------------------作者介绍-----------------------
姓名：黄廷忠
现就职：Oracle中国高级服务团队
曾就职：OceanBase、云和恩墨、东方龙马等
电话、微信、QQ：18081072613
个人博客: (http://www.htz.pw)
CSDN地址: (https://blog.csdn.net/wwwhtzpw)
博客园地址: (https://www.cnblogs.com/www-htz-pw)