« 成功恢复案例:打开断电崩溃数据库 | Blog首页 | 一个工作机会PDM/DBA/上海 »
成功恢复案例:解决字典表误Truncate故障
作者：eygle |【转载时请以超链接形式标明文章出处和作者信息及本声明】链接：http://www.eygle.com/archives/2008/01/truncate_dict_recovery.html
昨天，成功帮助客户恢复了一个故障数据库。
故障的原因是技术人员将数据库中的几个数据字典表Truncate掉，这直接导致了数据库不可用。
数据库环境为Oracle 9.2.0.7 RAC环境。由于数据库的事务量巨大，所以数据库没有备份。
现场检查确认，主要被截断的表有这样一些：
SQL> select object_name,object_type from dba_objects where object_name like 'IDL%';
OBJECT_NAME OBJECT_TYPE
------------------------------ ------------------
IDL_CHAR$ TABLE
IDL_SB4$ TABLE
IDL_UB1$ TABLE
IDL_UB2$ TABLE
关于IDL_UB1$表，我以前讨论过，这是非常重要的字典表，一旦出现故障，数据库会出现大量的ORA-00600错误，所有事务不能进行：
ORA-00600: internal error code, arguments: [17069], [0xC0000000DDDFA690], [], [], [], [], [], []
ORA-600 17069错误是最头疼的，客户当时数据库的一个跟踪日志已经暴涨到5G左右。
IDL系列字典表是记录数据库对象编译信息的，丢失了其中的数据，所有过程、Package等都将无法执行。
摘引一点关于这几个字典表作用的说明：
IDL_UB1$ is one of four tables that hold compiled PL/SQL code:
IDL_UB1$
IDL_CHAR$
IDL_UB2$
IDL_SB4$
"PL/SQL is based on the programming language Ada. As a result, PL/SQL uses a
variant of Descriptive Intermediate Attributed Notation for Ada (DIANA), which
is a tree-structured intermediate language. It is defined using a meta-notation
called Interface Definition Language (IDL). DIANA provides for communication
internal to compilers and other tools.
"At compile time, PL/SQL source code is translated into machine-readable
m-code.Both the DIANA and m-code for a procedure or package are stored in the
database.At run time, they are loaded into the shared (memory) pool. The DIANA is
used to compile dependent procedures; the m-code is simply executed."
These four tables hold the DIANA and the so-code m-code. I think "m-code" is
short for machine-dependent byte code but there is a sizable machine-indenpendent part as well. If you have a look at sql.bsq, you can see
that Oracle documents the "type" column of these tables as follows:
part number not null,
/* part: 0 = diana, 1 = portable pcode, 2 = machine-dependentpcode */
更严重的情况可能会导致大量系统DBMS包失效，其重新编译将更加复杂。
恢复进行了6个小时，成功帮助用户恢复了数据库，消除了所有ORA-600错误。
恢复最主要的是通过运行相关的脚本，重建和重新编译所有Procedure/Trigger/Package等对象，重新生成这些对象的DIANA和so-code m-code，这些主要的脚本包括catlog.sql,catproc.sql等。
当然最重要的是，一些ORA-00600错误需要解决，这可能会花费大量的时间。
这一案例的恢复过程并不重要，重要的是DBA应该学会永远不要让我们的数据库置于这样的危险境地。
DBA四大守则之一：备份重于一切。
DBA的基本素质之一：严谨。
-The End-
历史上的今天...
>> 2007-01-22文章:
>> 2006-01-22文章:
>> 2005-01-22文章:
------
这篇 【成功恢复案例:解决字典表误Truncate故障】来自 www.eygle.com | CSDN技术网摘| del.icio.us|365Key
By eygle on 2008-01-22 09:59 | Comments (19) | Posted to Backup&Recovery | Case | Edit |Pageviews:
留言 (19)
备份都没有，怎么恢复的啊？
可否介绍一下？
Posted by: Trevor at January 22, 2008 10:55 AM
大师，介绍介绍一下啊?
Posted by: qsxing at January 22, 2008 11:03 AM
没有备份 也可以做 ，而且是6个小时
这样也可以说 恢复过程并不重要 ？？
这是个开发库？？
Posted by: carcase at January 22, 2008 11:38 AM
补充了一些相关的说明，这是非常重要的生产数据库。其他不便说。
恢复的概要说明了一下，我但愿不再有人遇到这类问题。
Posted by: eygle at January 22, 2008 11:41 AM
妙手回春哇Maomi
Posted by: Julia at January 22, 2008 12:31 PM
呵呵，^_^julia大叫 Maomi好棒！
大师确实很厉害！
Posted by: bosonmaster at January 22, 2008 4:08 PM
真正的高手杀人于无形
不用备份也可以恢复，:)
Posted by: ricky at January 22, 2008 8:29 PM
以后eygle的活就越来越难了，不知道解决和不能解决的百分比是多少，不会是100%能解决的吧 :)
Posted by: mustapha at January 22, 2008 10:41 PM
由于数据库的事务量巨大，所以数据库没有备份。
呵呵，这个理由倒是古怪的可以。。。
Posted by: kamus at January 22, 2008 11:42 PM
佩服！
圆梦之旅
Posted by: fwei_fengwei at January 23, 2008 10:36 AM
我觉得这个主要不涉及数据丢失,所有没有备份也行,主要是在数据字典中重建各个package的信息
请问是不是这样,谢谢
Posted by: xiaomao2006 at January 23, 2008 4:17 PM
是的，数据没有丢失。
Posted by: eygle at January 23, 2008 10:02 PM
强的！
不过这几张字典表数据没了，数据库还是可以启来的吧？
只是会报600错误， 是不是这样的？
ps:
其实目前社会上好多重要的数据库都没有备份，也没什么特别的理由。而且好多用户在数据库出问题后，又不知道向谁求救。同时一些稍微大一点的咨询公司又不愿意把市场的触角伸向那些小公司(对这块市场来说).这样就使的eygle.com有很大的空间。^_^
Posted by: logzgh at January 24, 2008 1:55 PM
估计是不方便做恢复。不过在国内生产环境不做备份的例子有很多。
Posted by: fire9 at January 24, 2008 10:50 PM
to logzgh ;
是的，客户重构这个环境会非常复杂，所以他们仍然倾向于恢复这个损坏的数据库。
Posted by: eygle at January 25, 2008 2:17 PM
很想知道具体恢复的步骤!
Posted by: mengzhaoliang at January 25, 2008 5:56 PM
大師並沒有說沒有備份怎麼恢復啊
Posted by: javen at July 28, 2008 9:02 AM
看到你的文档,真的很好,看了你的书也是那么的好!
Posted by: NickLiu at September 10, 2008 4:27 PM
谢谢NickLiu!
Posted by: eygle at September 10, 2008 11:01 PM
