Email: service@parnassusdata.com 7 x 24 online support!
解决Oracle在SYSTEM 回滚段中出现ORA-600 [4193] ORA-600 [4194]
如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!
诗檀软件专业数据库修复团队
服务热线 ： 13764045638 QQ号:47079569 邮箱：service@parnassusdata.com
1.适用范围
版本8.1.7.4到10.2.3[release 8.1.7 to 10.2]
2.目标
这个文档主要提供一个修补方案，当SYSTEM 回滚段出项ORA-600[4139]/ORA-600[4194]，这个情况会阻止数据库开启。
支持当SYSTEM回滚段被影响时，让恢复的时间点在逻辑不一致之前。
ORA-600[4193]和ORA-[4104经常由新事务并且发生在undo的段头（TRN CTL / FREE BLOCK POOL的信息）和undo 段块中。如果这个情况发生在非SYSTEM的undo段上，可以直接删除这些回滚段。这是在涉及到SYSTEM回滚段时，一个手动处理的方法。
3.修复
在进行操作之前，首先进行备份
在SYSTEM 回滚段头中使用BBED 设置ktuxc.ktuxcnfb 和 ktuxc.ktuxcfbp[0..x].ktufbuba 为0。这样做的话，Oracle在新的事务的时候会使用空的块，不会对undo块头和undo块进行比较。
例如：
如下是一个回滚段头的dump
|
TRN CTL:: seq: 0x00af chd: 0x0036 ctl: 0x002a inc: 0x00000000 nfb: 0x0001 mgc: 0x8002 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe) uba: 0x00400006.00af.0f scn: 0x07be.a0bae152 Version: 0x01 FREE BLOCK POOL:: uba: 0x00400006.00af.0f ext: 0x0 spc: 0x13b4 uba: 0x00000000.00a8.0d ext: 0x7 spc: 0x1a2c uba: 0x00000000.009b.0b ext: 0x3 spc: 0x1c08 uba: 0x00000000.0092.27 ext: 0x3 spc: 0x12d0 uba: 0x00000000.0000.00 ext: 0x0 spc: 0x0 |
1.设置bbed合适的偏移量，修改 ktuxc.ktuxcnfb 为0X0000。在这个例子：0X0001
2.设置合适的偏移量，将所有非零的ktuxcfbp[0..x].ktufbuba设置为0X00000000.在这个例子中，只有ktuxc.ktuxcfbp[0].ktufbuba是非零的值0X00400006
3.在块已经被修改好后设置块的校验码为一个新的值，或者禁用块中的checksum。
部分块在修改后的dump如下：
|
The partial block dump after the modification is: TRN CTL:: seq: 0x00af chd: 0x0036 ctl: 0x002a inc: 0x00000000 nfb: 0x0000 mgc: 0x8002 xts: 0x0068 flg: 0x0001 opt: 2147483646 (0x7ffffffe) uba: 0x00400006.00af.0f scn: 0x07be.a0bae152 Version: 0x01 FREE BLOCK POOL:: uba: 0x00000000.00af.0f ext: 0x0 spc: 0x13b4 uba: 0x00000000.00a8.0d ext: 0x7 spc: 0x1a2c uba: 0x00000000.009b.0b ext: 0x3 spc: 0x1c08 uba: 0x00000000.0092.27 ext: 0x3 spc: 0x12d0 uba: 0x00000000.0000.00 ext: 0x0 spc: 0x0
|
nfb=ktuxc.ktuxcnfb --在空块池中非空槽位的数目
ktuxc.ktuxcfbp=空闲块池条目
4.打开数据库并且收缩system 回滚段。这个只是为了从“擦伤”处释放段中空闲的extent：
alter rollback segment SYSTEM shrink;