关闭

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

标签: 数据库技术人oracle测试存储出版
1291人阅读 评论(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

0
0
查看评论
发表评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场

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

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

一次oracle数据库断电受损后的恢复过程

(一)说明:   由于客户大厦突然断电,导致保系统服务器宕机,系统无法正常使用。 (二)系统恢复过程:   1、来电后,   手工重启一台tomcat后信息管理系统恢复正常。 2,同样重启档...
  • jiayitians
  • jiayitians
  • 2016-01-19 14:44
  • 2991

联想拯救者笔记本安装Win10、Ubuntu16.04双系统

UEFI+Win10+Ubuntu16.04+Nvidia双显卡原来的老爷机一直使用debian系统,最近挂了,换了个联想拯救者游戏本,性能还不错。新电脑装了正版的win10,可是对于我这种喜欢折腾l...
  • wuhuancheng
  • wuhuancheng
  • 2016-10-02 01:03
  • 6029

ORA-600 [4000] 错误解决一例

今天晚上,有个项目非归档数据库10.2版本
  • jarry_gao
  • jarry_gao
  • 2014-10-29 20:34
  • 446

ora-600 4000恢复一例

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

Oracle数据恢复:解决ORA-00600:[4000] ORA-00704: bootstrap process failure错误一例

今天刚好遇到这个问题,不过没有这么严重,我的仅仅是在没有备份的情况下数据文件丢失,数据块还没有坏,呵呵幸运啊!我用的这是通过alter database create datafile as ‘丢失数...
  • xionglang7
  • xionglang7
  • 2011-12-12 20:34
  • 4154

Oracle 通过ADR工具 收集ORA-600错误信息

ORA-00600
  • xuzhenxiang
  • xuzhenxiang
  • 2014-06-12 10:30
  • 1613

断电与ORA-600错误处理

目 录断电与ORA-600错误处理集合....................................................................................
  • zftang
  • zftang
  • 2011-05-26 21:55
  • 2103

ora-600汇总Ora-00600 错误的代码含义及常用查询

http://www.eygle.com/digest/2010/08/ora_00600_code_explain.html   数字类型的Ora-600 Ora-600 Base Funct...
  • wll_1017
  • wll_1017
  • 2012-05-22 10:20
  • 1803

记一则数据库恢复出现ora-600的案…

近期在给某网省业务系统做OGG数据库容灾的项目中,我们使用Oracle RMAN方式对数据进行在线初始化,在执行数据恢复的过程中遇到了恢复报错的情况,并且出现ORA-600的错误。本文记录了整个数据库...
  • stoperp
  • stoperp
  • 2014-07-22 15:19
  • 176
    个人资料
    • 访问:3853826次
    • 积分:55806
    • 等级:
    • 排名:第58名
    • 原创:1458篇
    • 转载:83篇
    • 译文:1篇
    • 评论:3784条
    博客专栏
    文章存档
    最新评论