上周五,客户发信息说在RAID崩溃后,他们无法打开一个Oracle 9i 数据库。在继续这个故事之前,我要声明这个数据库不在我们team的管理范畴内,我的团队根本不知道它的存在 – 有些客户让我们来管理他的一切,有些相对平衡。不过这都是他们的选择。离题了。
原来,这个数据库在NOARCHIVELOG模式,而且没有一个冷备份。他们甚至连一个数据库导出都没有。这样的事情总发生在周五!
首先,使用损坏的联机重做日志进行初始的崩溃恢复失败。然后客户尝试手动恢复,并没有帮助。更糟的是,在崩溃后他们没有立即创建冷备份,所以我也无法确定这些尝试是否有造成损害。
我试图通过缓慢递增SCN进行恢复,尝试不同的重做日志成员和其他一些技巧。但是恢复还是卡住,出现ORA-600 [3020],又名“错过写”。
用 _allow_resetlogs_corruption OPEN RESETLOGS 成功重置了日志文件,但数据库仍无法打开,返回错误信息 – 某些对象没有找到,ORA-600等
简而言之,似乎SYSTEM表空间不够完整导致无法打开数据库。
我还有几个想法,不过也想到了使用Oracle PRM-DUL 工具。PRM-DUL 代表通过Data Extraction进行Database Unloading。它所做的是从无法打开(包括数据库损坏的情况)的数据库中提取数据。当然,这取决于您的数据库的损坏程度,但说真的,它在我们的例子中的运作很神奇。
更多详细信息,请参阅白皮书 PRM-DUL 入门。
如果你或你的客户不幸遇到这种情况并需要这个工具,你可以在www.parnassusdata.com 获得更多详情。简单地说,你可以获得一个特别版本在数据库上运作七天,或者使用数据提取服务。因为我已经知道如何使用PRM-DUL,我们就用第一种方法。
我只花了几个小时收集一些数据,老胡据此产生一个演示版本。在购买它之前,我们的客户首先希望确保这个工具能工作,尽管这个工具的价格相比较Oracle的咨询会更便宜。
通过演示版本,我能够提取所有表的前10行数据。在最终确认一切正常后,客户得到获得了七天许可证。我仅用了几分钟重新运行提取命令,然后PRM-DUL奇迹般地生成了所有表的转储文件。之后我只需要将它们复制到另一台机器,打包小的shell脚本来导入它们。
补充一下,PRM-DUL也产生了所有的序列和PL / SQL对象。通过转储几个SYS对象,我大概能提取索引和约束,但由于客户有另一个相同数据模型(但不同数据)的数据库,从那里提取定义会更容易。
客户对我们能够从这样的致命情况下进行恢复感到惊讶,这可能要归功于PRM-DUL和他的创造者:非常感谢老胡– 让我的周五有相对较短的工作时间!
Comment