我进行测试的数据库环境是自己在虚拟机上安装的，由于希望进行快速测试和一些问题的验证，所以起初并没有在这个数据库上打任何补丁，该数据库是完全裸奔的，而这也可能是造成我遇到这个bug的一个原因。
发现该bug的过程和解决方案如下：
1.dump回滚段头
alter system dump undo header ‘_SYSSMU7_831131319$’;
2.查看dump出的trc文件
可以发现，在trc文件中，提示存在坏块，且也无法dump出回滚段头事务表等信息。
当时，我以为是我的数据库undo除了问题，为了方便我也没有去找坏块，直接对undo进行重建，但重建后dump出来还是存在问题。在多次重建后，我选择重新安装一次数据库，安装数据库后发现，该问题依然存在。
那看来，该问题可能就不是数据库本身的坏块问题了（而且在使用过程中，数据库日志也没有报任何坏块等错误信息）。
于是，在mos上搜索相关的问题，最后发现在Doc ID 26440142.8中对该问题有所描述：
这次，问题就比较明显了，就是因为这个bug，导致dump出的文件中，显示有坏块。
而解决这个问题的方法就是安装补丁26440142。
该补丁在20c中，才被包含到数据库中，被修复。而在这之前，则必须安装Patch 26440142才可以。
Patch 26440142是一个小补丁，但是成功安装该补丁需要有两个条件：
1.该补丁基于Patch 30593149,我们必须首先安装30593149补丁，否则直接安装26440142的时候会报错。
2.安装26440142补丁的时候，务必记得把数据库实例停下来（readme中有说，但我看的比较急，直接打补丁，最后出了奇怪的问题。重新回退，打补丁等一系列恢复操作后，才恢复正常）。
在完成安装这个补丁后，重新对回滚段头进行dump操作，此时可以发现，已经没有报出信息存在坏块了，而是正常dump出了该块：
此外，我们一直想要找的回滚段头事务表信息也被成功dump出来：
通过这个错误，想要提醒大家两点：
1.打补丁的时候一定要仔细阅读readme信息，跟着步骤一步一步做，一般不会有问题；
2.在生产环境下，部署完数据库后，一定要打最新（或者次新）的补丁集，否则多次打补丁不仅风险大、比较麻烦。同时，多次造成的多次停机，也会对业务等造成影响和损失。
评论
0 点赞
