其实这篇文章，说讲述的跟DBA没有太大的关系，但是我写出来，希望对DBA有所帮助。
上个月一客户的某重要业务，出现2小时故障，事情闹得很大。故障发生在一个简单的INSERT语句上面，不幸的时执行那个SQL时总是报ORA-600[kcbget_24]这样的错误，其实导致事务一直失败。不过幸运的是，那个INSERT语句所要完成的业务功能只是整个业务环节中的可选功能，开发商也有开关来控制是否启动这个可选功能。虽然这个ORA-600错误，不能很快查到原因，但是却可以通过设置那个业务功能的开关来绕过这个问题。当时是我在现场处理的这个问题，从接到问题报告到解决问题，只花了很短的时间。那为什么整个故障历时了2小时。其主要原因在于，这个客户没有有效的监控手段，来监控错误，完全靠业务人员的反映，而业务人员又不能很快地发现问题。
事后检查错误出现的原因，发现是INSERT语句时，维护一个索引出现了索引，在做索引节点块分裂时报了ORA-600[kcbget_24]错误。ORA-600错误基本上是由BUG或数据损坏引起的，但BUG引起的可能性更大。那为什么之前好好的，怎么突然就出现错误了，再进一步追查发现出现问题的索引是新建的索引，而建这个索引的，是开发商的一个开发人员，未经过流程，就直接在表上建了。结果索引一建好，就出现问题了。
这里我想说的是，做DBA工作，不能有任何侥幸心理。这次发生的事故，是ORACLE的BUG引起，但是如果之前有过充分的测试，按流程来操作，很可能就分避免了这个问题的产生。对一个复杂的系统的维护，技术或许比较重要，但是我认为，流程和测试更重要。
这件事也让我想起2年前，我还在上一家单位(相对目前的工作性质来说是甲方)时，一个非常重要的业务系统，在一个非常重要的时间，崩溃了，完全不能用。这套系统本来还有一个月就功成身退，被新的业务系统所代替，结果最后一班岗也没站好，潜伏的一个致命的BUG爆发了(不是数据库软件的BUG,是业务软件的BUG)。头一天晚上系统的配置数据做了改动，按正常的流程是需要测试的，或许业务人员认为，配置的改动是常有的事，不需要测试，结果忽略了测试，结果第二天…..
工作中的某些环节，比如测试，是枯燥的，但是实在是不可或缺的