以拯救之因 强制恢复导致ORA-600 4000错误案例

来源:互联网 发布:php fsockopen post 编辑:程序博客网 时间:2024/04/30 07:10

以拯救之因  强制恢复导致ORA-600 4000错误案例

 

我曾在一本书上写道:

一知半解比无知更可怕。

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

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

灾难描述

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

整个过程是这样的。

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.csdn.net/broadview2006/article/details/7744623

原创粉丝点击