首页 > 数据库 > Oracle > 一次ORA-03113引起的思考
一次ORA-03113引起的思考
近期客户报表系统频繁发生ORA-03113错误,收到消息后,远程支持。
由于是突发性的,所以询问了用户在事发前,系统有没有什么改动,用户表示没有。
通过分析应用日志,发现引发该错误的99%都和a表查询相关,另外1%是和b表相关的查询,对照17613.1-ORA-03113 on Unix - What Information to Collect,这属于突发性特定查询引起的,于是自然的想到,可能是该表的索引可能出了问题,根据现有信息,确认该表不是分区表。于是让客户手工在SQL*PLUS里测试这两个表的查询,测试语句是直接从应用日志摘出的引发错误的语句,但结果却出乎意料-全部正常。
于是让用户手工启动报表输出,成功了。
看来数据库是正常的,还是跟当时的系统状况有关。于是问事发之时,系统资源是否正常,网络是否正常-已告知客户该错误属于网络通信问题。客户表示,事发时没有监控系统资源,网络经过ping,没有问题-没有丢包,反应也很快。
于是于是让用户提供数据库日志alert listener sqlnet udump下日志信息,没有获得有效信息。
陷入迷茫。。。,由于远程支持,很多事情没法做。
晚上,用户还要跑报表,到时跟下吧,希望能过去。
然而,结果比想象的还要糟糕-控制台直接报报表服务器响应失败,接收反应失败。
于是让客户查网络,客户告知网络OK。也被告知这步已经被跳过去了,待会手工做。
真的晕了。。。
晚些时候,收到用户消息,发现这个问题跟新上的交换机有关。
我晕。。。
但回过头看这个问题,其实有很多线索可查的。
1、问系统有没有什么改动的时候,在问题可能与网络有关的时候,应该附带一些提示:比方有没有换过网卡网线交换机路由器之类的,有没有插拔过相关的网线。这时,应该可以得到更换交换机这个重要线索了。
2、分析应用日志时,没有进一步分析相关查询之间的共性,这两个查询返回的数据量都应该很大,而且报表是批量出的,这时交换机流量也应该很大的。这时如果用大包去ping对应主机,可能会发现网络其实并不是那么好。
3、用户反应网络OK的时候,如果自己对网络关注更多的情况下,应该会问怎么测的,然后让用户用大包去测,也可能发现问题。
4、自己水平有限,想不到的线索,,
思考整个处理过程,
1、沟通的能力,这里可能说是些技巧跟确切,怎么样诱导对方,充分调动对方的思维,以便对方提供更多跟有效的信息,是很重要的。
2、信息处理能力,加工原始信息,从大量原始信息中,抽取挖掘信息的能力,信息时代、、、
3、专业知识,不说了,能力再强,在真正面对问题的时候,也很难弥补专业知识和经验不足的问题,所以专业知识的学习和实践锻炼,没有任何接口去推掉他们。
4、处理问题的时候,靠的综合能力,综合能力不是句空话,他是真真切切存在的,木桶效应其实也有另一面的,当整个桶都很浅的时候,可能更多的是看他的负面效应,可是反过来看,木桶的“成长”总是要些部分先长长的,我们也要看到先变长部分的积极效应。处理问题的时候,充分发挥自己的优势,从自己比较擅长的角度出发,事情往往更容易解决。
5、但到达一定高度的时候,世界的各个角落看起来都是一样的。。。别把自己的思维禁锢在一个层面上,其实对其他层面的理解愈多,也会增加对自己所处的层面的理解的。这里的层面既包含水面层面,也包括纵向分割。大家都知道,马克思在是个哲学家,其实他在数学,物理,天文,经济等等很多方面都很不错的,所以,套用以前老师的一句话,真正的强者其实在各个方面都很强,干什么事情都能干好。或许我们不能变的强到那种地步,但是我们应该看到这点,至少也要有个自己的领域吧,在这个领域相关的方面,任何问题都能处理,当然这里的领域不是说广袤的科学领域,只是一个小小自己的“空间”。
很多人喜欢侦探故事吧,我们处理数据库问题其实不也是在侦查在破案吧,down机不就是命案吗,对于这种案件,想想警察是怎么处理的,保护现场,调查现场,取证,寻找目击者,口供,当事人的各种关系,近期状况,综合信息,判断案件性质,嫌疑犯,审讯,处理。。。
对于slow不就是伤害事件吗,这时,怎么做。。。
当然相通的是只是方法,其实花就是花,水就是水,事物原本就是那样,不同的只是我们的“心”,从更高层看,我们的“心”本来就是这样的,,世界本来就是世界的样子,我们看到的世界,是我们的世界,也只是我们的世界,这不是唯心论,而是客观存在,因为本来就是这样子的。。。
扯远了。。。
方法不是万能的,因为方法只是方法,不能代替别的存在,如果存在上帝的话,可能对他而已,方法根本就不存在,因为他根本不需要,不受任何限制的创造者,但真的能摆脱任何限制吗,其实自身的存在就是最大的限制啊,哎让人抓头的问题。。。
方法是要需要一块基石的,,这个基石既是它存在的基础,也是它发展的基础。有可能一个方法发展到最后,轰然倒塌。。。
回到数据库吧,3113,这个最常见的问题,却是最麻烦的问题,因为源头太多,路太多,,而最麻烦的问题,其实解决起来往往是最简单的,因为有迹可循,,真正的问题是“莫名其妙”问题,问题都不明白的,怎么去消灭呢,消灭问题最大的问题是找到问题,
尽管事务循着辩证法的轨迹发展--在我们的“心情”中--是那么的繁杂,前进,跳跃,轮回,消失,重生。。。,然而横向切割的话,其实却是那么的简单--其实它就是那样子的,它本来就是那样的。。。
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/7591490/viewspace-1008696/ ,如需转载,请注明出处,否则将追究法律责任。