上周五，客户发信息说在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和他的创造者：非常感谢老胡– 让我的周五有相对较短的工作时间！
Leave a Reply