以拯救之因

ORA-600 4000错误案例

我曾在一本书上写道：

一知半解比无知更可怕。

一知半解的草率行事可能使数据库遭受意想不到的灾难，所以在接触一个数据库时，如果没有相当的把握，请谨慎操作，不要让自己和数据库陷入未知的危险境地。最基本的是，如果不可避免地要进行某些危险的维护性操作，应当在之前做好备份。

在面对数据时，无知者不能无畏。

2011年12月30日，一个运营商客户的核心数据库发生故障，无法启动。随后在工程师的草率介入后，数据库遭遇无法启动的灾难。

整个过程是这样的。

1.         客户误操作删除了一个数据文件，数据库报错。

2.         第三方服务商介入，试图清除该缺失文件。

3.         工程师选择重建控制文件，在当前数据库下执行不完全恢复。

4.         通过内部隐含参数强制重置日志打开数据库。

5.         数据库出现一系列600内部错误，无法启动。

6.         检查备份，发现近期未进行备份，无从备份恢复。

7.         灾难形成。

这则案例原本并不复杂，丢失了一个数据文件，如果没有备份，可以进行下列操作。

1.         在关闭数据库之前，类似前一章的情况，从文件描述符中进行恢复。

2.         如果数据库关闭不可恢复，并且可以接受损失，则离线抛弃该文件即可。

3.         如果该文件非常重要，可以通过存储级别的恢复，找回该文件。

具体选择何种措施，取决于数据的重要程度，但是贸然采取行动则会消灭一些可能性。比如，关闭数据库，措施1就无效了；如果在存储级别又执行了文件复制，覆盖了存储内容，则措施3也就无效了。

所以，针对不同的数据灾难，做出正确的判断，找到合适的技术支持尤为重要。而对于这个案例，以上三种可能性都被掩盖，数据库走向了一个错误的方向，并且在错误的方向上走得很远。

分析这个案例的整个过程，我们总结出了如下教训。

1.    一知半解比无知更可怕

在这个案例中，技术人员显然对Oracle的技术认知不足，草率地采取了错误的手段和步骤，最终导致数据库状况和用户初衷相差了十万八千里。

前面提到的三种可能性在一系列的误操作面前变得无效，数据库必须接受不一致的灾难性考验。

通过这个案例，技术人员需要铭记，在着手处理故障之前，要遵循这样一个重要的守则：保护现场，至少不要使情况变得更坏。

在保护好现场之后，再进行破坏性或者把握性不大的恢复尝试；对于某些海量数据的情况，如果无法进行及时的备份，不得不在当前环境下进行恢复，那么就必须要求工程师具有极高的素质和精准的判断，明确知道每一个命令和步骤可能带来的后果和后续的处理方式。

每个工程师都要想一想：如果一个恢复尝试之后，数据库彻底无法启动，我们还能如何做？多思多想是对用户和自己负责，无知无畏不应当在生产环境中尝试。

2.   不要超越自己的能力范围

在技术领域，如果你采用的技术手段和方法超越了自己的能力范围，可能出现不可预知的后果，那么最好不要做这样的冒险，冒险意味着对用户的不负责任，同时也是对自己的折磨。如果决定冒险，那么至少在自己的测试环境中进行同类测试，明确可能会出现的种种情况，这样的测试并不会耗费太多的时间。

在这个案例中，Oracle数据库的内部参数使用是不恰当的，导致了问题变得更加糟糕。实际上，内部参数的使用要求非常清晰地了解其含义，以及可能引致的后果，并且对随之而来的后果有应对方案。

对于用户，应当能够对第三方服务商进行适当的监督、确认，确保不可预期的后果不被贸然引入到数据库中。

3.   在不可逆操作之前执行备份

在需要执行不可逆操作之前，执行备份，要确保可以回退到之前的状态，以便尝试恢复失败之后，别人还有机会从头开始，这也是保护现场的概念。

除了对数据库的备份，实际上还应当在一些修改操作之前执行备份。比如对于特定数据块、文件头、ASM磁盘组信息、日志文件等的备份，这些备份可以在关键时候帮助我们。

这里必须着重提一下日志文件，因为在强制Resetlogs时，日志文件会被清空刷新，如果不进行备份，其中的内容将永远丢失，而我们知道，有时候通过日志解析可以最大限度地找回数据，所以日志文件的备份也非常重要。

4.   管理者需要参与决策

对于重要的数据环境，在执行重要的操作之前，管理者即便不了解详细的技术细节，也应当和技术人员进行沟通，听取技术方案、操作计划、实施步骤、现场保全、回退方案等。

管理者虽然可能不了解技术细节，但是其大局观和缜密思考应当为技术决策提供保障。管理者也应当在交流中感知技术人员是否了解详细情况，是否对方案有清晰把握、对执行自信无误。交流、提问和质疑也是对技术人员完善方案、认真思考的一种促进。

有了这样一个环节，就可以规避很多风险，因而管理者的判断和决策也应当成为数据管理中重要的组成部分。

 

保护数据，保护现场，在处理故障时认真思考，谨慎决策，是用户和工程师们共同的职责。只有大家共同努力才能保障数据环境的持久安全。

 

本文节选自《Oracle DBA手记4：数据安全警示录》一书

盖国强 著

电子工业出版社出版

图书详细信息:http://blog.chinaunix.net/space.php?uid=13164110&do=blog&id=3273441