집 >데이터 베이스 >MySQL 튜토리얼 >Oracle元数据对象Invalid修复过程
在Oracle的运行过程中,由于操作失误可能会造成内部元数据的损坏,进而影响到系统的一些基础功能和正常处理。一旦发生这种故障,
在Oracle的运行过程中,由于操作失误可能会造成内部元数据的损坏,进而影响到系统的一些基础功能和正常处理。一旦发生这种故障,对内部数据字典的重建就是我们需要进行的处理。
本篇从一个损坏故障为入手点,介绍了如何进行Oracle元数据对象的重建。
1、故障场景
一个朋友的测试库最近出现很多“古怪”的错误,比如exp/imp操作异常中断、pl/sql中元数据信息无法展现和异常报错。这种情况下,笔者向朋友索要的对应的alert_log日志文件。结果发现很多错误信息。
Sat Jun 23 06:36:37 2012
Errors in file /u01/diag/rdbms/wilson/wilson/trace/wilson_m001_3667.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-04063: package body "SYS.PRVT_HDM" has errors
ORA-06508: PL/SQL: could not find program unit being called: "SYS.PRVT_HDM"
ORA-06512: at line 1
(篇幅原因,有省略…..)
Sat Jun 23 06:53:39 2012
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x34] [PC:0x92C0E13, kzpchkc()+4425] [flags: 0x0, count: 1]
Errors in file /u01/diag/rdbms/wilson/wilson/trace/wilson_ora_3619.trc (incident=12215):
ORA-07445: °é”è: è¨ [kzpchkc()+4425] [SIGSEGV] [ADDR:0x34] [PC:0x92C0E13] [Address not mapped to object] []
Incident details in: /u01/diag/rdbms/wilson/wilson/incident/incdir_12215/wilson_ora_3619_i12215.trc
Sat Jun 23 06:53:40 2012
Trace dumping is performing id=[cdmp_20120623065340]
Sat Jun 23 06:53:45 2012
Sweep [inc][12215]: completed
Sweep [inc2][12215]: completed
Sat Jun 23 06:55:23 2012
ORA-942 encountered when generating server alert SMG-4120
ORA-942 encountered when generating server alert SMG-4121
如此类型的错误信息,遍布在近几天错误日志中。但执行一些失败的命令时(如desc),还会有异常错误信息在日志中展现。
在上面的错误日志中,,还有是关于MMON进程异常中断之后,反复重新启动。
MMON进程是AWR报告库收集进程,定期(每小时)收集系统状态保存在数据库字典中。MMON异常中断后反复重启,似乎意味着AWR收集受到影响。
和朋友联系,获取进一步信息。
当日的AWR snapshot只有两条,看来真正出现了问题。同时,发现自动作业中的sys.standard包失效(invalid),合并的还有很多包和方法失效。
经过朋友回忆,应该是执行了exp/imp的重置脚本catexp.sql。看来是该脚本在执行中,破坏了内部的字典信息和数据,导致了一系列问题。
2、问题解决准备
发现了问题的根源,我们就可以有解决问题的基本思路:重新创建数据字典视图和程序对象。我们在Oracle程序安装目录中,均有保存建库脚本和程序,所以可以调用对应脚本,来更新数据字典和程序对象。
由于处理信息比较敏感,所以在处理之前,要进行一次完全备份。笔者选择停机冷备的方法。
首先,定位控制文件和数据文件位置信息,准备拷贝。
[root@ /]# chown -R oracle:oinstall backup
[root@ /]# ls -l | grep backup
drwxr-xr-x 2 oracle oinstall 4096 Jun 25 20:23 backup
--控制文件
SQL> select 'cp '||name||' /backup' from v$controlfile;
'CP'||NAME||'/BACKUP'
--------------------------------------------------------------------------------
cp /u01/app/oradata/ORA11G/controlfile/o1_mf_7vpyvypo_.ctl /backup
cp /u01/app/flash_recovery_area/ORA11G/controlfile/o1_mf_7vpyw16z_.ctl /backup
--数据文件
SQL> select 'cp '||file_name||' /backup' from dba_data_files;
'CP'||FILE_NAME||'/BACKUP'
--------------------------------------------------------------------------------
cp /u01/app/oradata/ORA11G/datafile/o1_mf_users_7vpyc2xd_.dbf /backup
cp /u01/app/oradata/ORA11G/datafile/o1_mf_undotbs1_7vpyc2py_.dbf /backup
cp /u01/app/oradata/ORA11G/datafile/o1_mf_sysaux_7vpyc2hb_.dbf /backup
cp /u01/app/oradata/ORA11G/datafile/o1_mf_system_7vpyc1x7_.dbf /backup
之后,关机将文件拷贝到备份目录上。
[oracle@bsplinux ~]$ sqlplus /nolog
SQL*Plus: Release 11.2.0.1.0 Production on Mon Jun 25 20:42:06 2012
Copyright (c) 1982, 2009, Oracle. All rights reserved.
SQL> conn / as sysdba
Connected.
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL>
使用生成脚本语句,实现拷贝。
[oracle@bsplinux backup]$ ls -l
total 1720628
-rw-r----- 1 oracle oinstall 9748480 Jun 25 20:44 o1_mf_7vpyvypo_.ctl
-rw-r----- 1 oracle oinstall 9748480 Jun 25 20:44 o1_mf_7vpyw16z_.ctl
-rw-r----- 1 oracle oinstall 723525632 Jun 25 20:55 o1_mf_sysaux_7vpyc2hb_.dbf
-rw-r----- 1 oracle oinstall 744497152 Jun 25 21:08 o1_mf_system_7vpyc1x7_.dbf
-rw-r----- 1 oracle oinstall 267395072 Jun 25 20:47 o1_mf_undotbs1_7vpyc2py_.dbf
-rw-r----- 1 oracle oinstall 5251072 Jun 25 20:45 o1_mf_users_7vpyc2xd_.dbf
冷备份完成。
注意:在进行所有的修复操作前,如果有可能,一定要进行数据现场保留备份!这样起码可以做到不会将情况恶化。