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

标签: 数据库 技术人 oracle 测试 存储 出版
1350人阅读 评论(0) 收藏 举报
分类:

以拯救之因  强制恢复导致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

查看评论

ora-600 4000恢复一例

原文链接 个人博客 http://www.killdb.com/?p=225 下午一个同事遇到经典的ora-600 4000错误,我远程帮忙处理了一下,关于该错误的处理, 网上已经有不少的例子了,...
  • lovewifelovelife
  • lovewifelovelife
  • 2011-08-30 20:28:10
  • 851

ORA-600(4000)

oracle 11gR2 启动报错: Database mounted. ORA-01092: ORACLE instance terminated. Disconnection forced ...
  • u012450009
  • u012450009
  • 2013-12-27 15:50:06
  • 1091

联想拯救者恢复系统 最好用的系统恢复工具

  • 2009年09月30日 19:45
  • 949KB
  • 下载

控制文件(control)被误删恢复方法(ORA-00283/ORA-01610的问题)

方法一: 首先是利用老的控制文件alter database backup controlfile to trace; 利用生成的trace 文件编辑sql脚本恢复的过程: 1>创建pfile,制定...
  • qq942477618
  • qq942477618
  • 2013-11-12 16:42:48
  • 2811

Oracle ORA-600 [2662] 错误

Oracle ORA-600 [2662] 错误   数据库版本:10.2.0 背景: 客户那边数据库突然出现一个current日志文件坏了,导致数据库crash了,然后现场工程师使用_ALL...
  • lqx0405
  • lqx0405
  • 2015-03-31 11:52:24
  • 361

记一次断电恢复ORA-01033错误

客户的电脑因为频繁断电,造成orcle无法连接,报ORA-01033:oracle初始化或者关闭错误. 按照传统方法 进入cmd sqlplus sys/password@user as sysdb...
  • u011609113
  • u011609113
  • 2017-01-04 16:39:13
  • 1187

因 URL 意外地以“/LoginSystem”结束,请求格式无法识别。

  • qq285679784
  • qq285679784
  • 2017-05-25 14:35:53
  • 431

iOS小技巧:强制系统不锁屏

强制系统不锁屏,使用UIApplication 的 idleTimerDisabled属性 idleTimerDisabled 这个是控制空闲计时器(idle timer)是否对app起作用的属性 ...
  • longhappyingly
  • longhappyingly
  • 2013-11-30 11:06:46
  • 1381

联想一键恢复系统4.0

  • 2008年06月09日 09:33
  • 3.45MB
  • 下载

【急】连接服务器出现错误

RSocketServ socksev; TInt res=socksev.Connect();//success if(res!=KErrNone) { console->Write(K...
  • zuitamin2508
  • zuitamin2508
  • 2017-04-20 11:28:29
  • 182
    个人资料
    持之以恒
    等级:
    访问量: 399万+
    积分: 5万+
    排名: 56
    博客专栏
    文章存档
    最新评论