undo offline，一个不大不小的故障

周末，夜，放松了一天，周末的夜晚无所事事，本打算吃完了看看片，看完了睡睡觉，晃晃悠悠过周末。时近晚上10点，突然接到一个客户电话，一看号码，心说这可不好，肯定出问题了，希望不是大事。。。
电话里，客户看样子还挺着急，原来是数据库起不来了，不过听上去问题不算太严重。客户下午本来要换UPS，结果正在备份呢，突然停电，这还没换掉的UPS再加上停电，结果服务器带存储一起就咔嚓了，等来电了把服务器都起来，结果发现，服务器上的三个库，其中有一个起不来了，故障呢，是open数据库的时候出现了SQL递归调用失败，访问undo表空间的文件有问题了。客户环境是9i rac，文件存储在raw上，有备份、有归档（一听这个就放心了，哈哈）。
开始远程电话指导，首先mount数据库，查询v$recover_file，发现2号文件和12号文件在里面出现，并且这两个文件状态都为offline,而且error字段为空。然后查询v$datafile和v$tablespace，发现这两个文件分别是undo表空间和另一个用户数据表空间的。既然刚才看到error字段为空，那应该是介质还在，但文件不一致拉，所以让客户直接recover datafile，再查询v$recover_file，发现里面已经没有任何信息了，这就说明文件的介质恢复已经完成了，那就打开数据库吧。
本以为接下来用户打开数据库，然后在电话里向我表达一下谢意，俺就可以挂了电话睡觉去了，结果没想到，用户open数据库的时候还是出了同样的错误，数据库仍然没有打开！ 奇怪了。。。难道存储有问题了？ 跟客户确认了一下，emc的存储厂商说存储没有问题，操作系统也没有做任何改动。。。奇怪，算了，先不想那么多，反正有备份嘛。于是我让客户把主机整个重起，然后用备份再作一次恢复。。。半小时后，电话再次响起，客户的声音有点颤抖，说道，还是出现了刚才的错误。。。晕
我心里也有点紧张了，这可奇怪了，不会半夜把我搞过去给他们现场解决吧，而且从现象上看，也跟正常恢复的情况有些不一样啊，问题出在哪儿了呢。。。。。。抓了抓头皮，点了一下鼠标，让手中正在打的游戏暂停。。。突然，一个想法出现在脑子里，靠，一个基本的常识性问题忘了，其实根本就不需要恢复！
什么问题呢，很简单，在讲表空间状态的时候，我们一般都会强调有些表空间是不能offline的，其中就包含了在用undo表空间，那么刚才已经在v$recover_file查看到了2号（undo表空间的文件）文件的状态正好是offline的，虽然随着日志的应用，2号和12号文件已经不出现在v$recover_file里了，但他们offline的状态并没有改阿！ 赶紧让用户再查询一下v$datafile，发现果然状态都是offline的，出了口大气，原来是这么个小问题在作怪，让客户把2号和12号文件都online了，然后直接open数据库，ok了。。。果然听到客户接下来一连串的感谢之声，呵呵，问题搞定。
现实中很多问题看似复杂，其实就是我们最基础的知识，对这些知识的消化吸收和灵活运用，才能够在出现问题的时候在最短的时间内确定清晰可行的解决方法，所以，基础真是很重要。

[@more@]

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/20034375/viewspace-1007218/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/20034375/viewspace-1007218/