DBA日记 第二部 （27） 爱刨根问底的用户 8月17日 继续优化（2）
又宕了。
我想了一下，数据库已经正常打开了，目前达到了一致，只是有部分数据可能会丢失，也有可能会产生一些逻辑坏块，但是没理由数据库打开后几分钟又宕机了，难道是还有什么其他的问题没有解决？我正在思考着，小毕已经把错误日志通过QQ发了过来。
Errors in file /oracle/app/oracle/admin/serv/bdump/serv_smon_6224.trc:
ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [kddummy_blkchk], [2], [40673], [38508], [], [], [], []
Mon May4 14:37:35 2009
Errors in file /oracle/app/oracle/admin/serv/bdump/serv_smon_6224.trc:
ORA-00600: internal error code, arguments: [kddummy_blkchk], [2], [40673], [38508], [], [], [], []
Mon May4 14:37:38 2009
Errors in file /oracle/app/oracle/admin/serv/bdump/serv_pmon_6212.trc:
ORA-00474: SMON process terminated with error
Mon May4 14:37:38 2009
PMON: terminating instance due to error 474
Instance terminated by PMON, pid = 6212
从错误日志上看，是ORA-600 [kddummy_blkchk]导致了SMON进程出现故障后退出，PMON发现SMON异常终止后把实例终止了。我查了一下手头的知识库，发现NOTE 300581.1里介绍了这个ORA-600错误。这份文档上对错误的描述是DUMMY FILE FOR BLOCK CHECKING ERROR，看样子Ora-600 [kddummy_blkchk]是访问某个数据文件的时候出现故障导致的，这份文档中介绍了几个导致这个问题的BUG，我简单看了看，好像都没有和我们这个案例相似的。我们这个数据库是通过强制手段打开的，可能会产生部分逻辑坏块。DUMP出2号文件的40673号数据块应该能够找到问题的根源。不过由于客户在边上焦急的等待我们搞定后继续测试，所以我建议小毕不要在这个问题上过多纠缠。从日志上看，紧跟在后面的第一个参数是文件的绝对文件号（AFNO），第二个参数是BLOCK#，第三个参数是错误码。从第一个参数来看，10.2数据库的2号文件一般来说是UNDO，SMON访问UNDO表空间的时候出现故障，应该是UNDO出了什么问题。于是我问小毕，刚才数据库打开后有没有打扫房间？
打扫房间是我们公司同事之间的常用语，意思是故障处理后的善后处理。实际上处理和UNDO有关的问题，在打开数据库后还需要创建新的UNDO表空间，并把系统的UNDO表空间切换到新的表空间上去，然后删除被设置为CORRUPTED的回滚段，最后删除老的表空间。一听我说打扫房间，小毕就恍然大悟：“哦对了，老白，刚才忙忘了，他们的UNDO管理还是手工管理模式，而且没有创建新的回滚段，我马上处理一下。”
小毕是刚刚进入DBA行业不到两年的小伙子，进公司也不过1年半的时间。不过小毕很勤快，学东西也快，来公司后不到半年就独立出去给客户提供服务了，这段时间更是因为公司人手不足，已经开始独立挑大梁了。这是他第一次处理类似的案例，居然经过如此复杂的处理过程后成功的打开了数据库，因此他也比较兴奋。打开数据库后的后续操作在我们的故障处理预案中其实是些的很清楚了，小毕也是在我的指导下按照我们的预案一步一步在实施。不过打开数据库的时候，这个小伙子过于激动了，犯了一个小小的错误。这种情况下，他需要的是信任和鼓励，我想经过这样一次实战操作，下回他再遇到类似的问题应该会处理的更好。
看看手机上的时间，已经快到中午的12点了，这个故障整整处理了1个半小时，已经到了午饭时间了。这个时候秦工打电话过来说他在楼下开发那里还有点事，让我再等10分钟一起去食堂吃饭。于是我在QQ上问小毕是不是已经搞定了。小毕说数据库已经稳定了，不过还有一个小问题等待解决，他们的JOB无法执行，一直在报错。我一看错误信息
ORA-12012: error on auto execute of job 1
ORA-08102: index key not found, obj# 239, file 1, block 1674 (2)
Mon May4 15:22:46 2009
Errors in file /oracle/app/oracle/admin/serv/bdump/serv_j000_7443.trc:
ORA-12012: error on auto execute of job 1
ORA-08102: index key not found, obj# 239, file 1, block 1674 (2)
小毕查过，这个Obj#为239的对象就是job$上的索引SYS.I_JOB_NEXT。访问这个索引的时候报ORA-8102，就是说I_JOB_NEXT或者JOB$出现了逻辑不一致，索引上的同一条记录的键值和表里的数据不一致，导致访问数据失败。I_JOB_NEXT不是一个BOOTSTRAP$对象，因此这种情况一般来说重建一下索引就可以解决问题了。于是我建议小毕REBUILD 一下索引，小毕说他已经对这个索引做过REBUILD不过这个问题还是没有解决。
我说那就怪了，难道还要重启数据库才能解决？小毕听了后说索引REBUILD了应该就解决了这个问题了，重启不重启关系不大吧。不过还是先重启一下试试。我说那你就试试吧。
刚说完这话，我突然想到，REBUILD索引可能会通过索引进行，这样的话有可能错误不会被纠正，我们可以做个试验，干脆删除这个索引，然后再重建索引，这样就应该能解决问题了。我刚把这个意思和小毕说了一下，小毕就说：“老白，你太牛了。我在METALINK上也找到了一篇文章NOTE 1036858.6，里面也有这样的建议：
connect sys/
drop index i_job_next;
create index i_job_next on job$ (next_date)
Note: alter index I_JOB_NEXT rebuild;
Will not fix the problem.
小毕重建了索引后，果然ALERT LOG中看不到JOB的报错了。这时候秦工又打电话过来，他在楼下的事情还没处理完，可能还需要等一会，他和我说好12点45在食堂门口见。我看了一下时间，现在正好是12点半，还有十来分钟时间。于是我就和小毕总结了一下这个案例处理的过程。首先肯定了他在处理这个案例的时候没有盲动，首先确认了数据备份的问题，而且第一时间通知了更有经验的人。第二是在客户焦急等待的情况下能够从容不迫的进行操作，在整个操作过程中没有任何失误，这样才保证了数据库能够被打开。不过在处理这个故障的时候小毕还是出现了小错误，没有及时打扫房间，又浪费了近半小时的时间。我建议小毕今天晚上抽出点时间认真整理一下故障报告，因为整理报告是强化记忆的一个很好的办法，通过整理报告，可以把从老储的故障处理预案中的所有知识都吸收进来，并且加上你这回处理的独有的知识点，最终变成你自己的知识。
小毕说，是的，这回我肯定要好好总结一下，不过可能需要点时间，处理过程中碰到的好几个ORA-600错误都是第一次碰到的，我手头也没有资料，老白你能不能把手头的资料发一些给我。
我想想也是，这次碰到的几个ORA-600错误是以往处理类似案例中没有见到过的，当时为了赶紧解决问题，也没有细去研究，都是用临时方案解决的。于是我建议小毕通过这个案例更新一下老储去年的供电局的那个故障处理报告内容，把预案写的更完善一些。我最后强调，这份新的报告的篇幅不能少于20页。
公司的不少的年轻人干活都很不错，工作态度也挺好，不过写报告的能力和对待文档的态度都不太让我满意。以前也经常出现他们写的报告被我打回去重写5、6次的情况。实际上写报告是提高技术水平的一个很好的方法，报告写得越详细，你考虑的问题也越多，学到的技术也越多。写出一份逻辑性和可读性都很强的报告，对报告的编写者要求也是挺高的，需要些报告的人花费大量的时间去思考，甚至考虑一些谋篇布局的问题。
我正在和小毕讲着如何整理报告，开发商的老李打电话过来了。老李已经有大半年没和我联系过了，这个时候打电话过来，肯定是表扬小毕。一接电话果然如此。原来老李他们的系统今天在做一个大数据量的测试，这个周末系统就一定要上线了。今天上午他们在做测试的时候突然存放数据库的一个文件系统满了，他们的一个工程师看到目录下有几个.log的文件，以为是普通的日志文件，就用rm *.log把文件删除了，没想到一删除这几个文件，数据库就宕了，而且再也打不开了。小毕帮他们打开了数据库，给他们争取了差不多一天的测试时间，因此他打个电话过来表示感谢。
|
