Oracle元数据重构实验
元数据是几乎所有数据库都具有的基础数据，其中包括基础数据字典、系统功能视图和函数结构等内容。越是功能强大成熟的数据库产品，其元数据信息越是众多复杂。在Oracle世界中，我们经常使用的性能工具AWR、作业Scheduler和RMAN工具，甚至Data Pump工具，都是建立在数据字典的基础上。
大部分数据字典是在sys和system用户schema下，普通用户只是通过同义词调用和访问对象，删除破坏的风险的是比较低的。在实践工作中，主要有两种情况会破坏元数据：管理员帐号误操作和系统内部运行数据损坏。无论是哪一种情况，元数据损坏的故障通常是很麻烦的，越是基础的元数据损坏，故障现象就越是紧急复杂和多变。
数据库组件之间，存在严格的依赖关系。一个基础元数据损坏，可能导致若干依赖的组件不能成功编译使用。如果是一些单纯的组件，如XDB、Data Pump的损坏，可以调用特定的创建脚本重建对象。但是如果是一些基础的组件错误，连带骨牌效应，就需要重建数据字典了。
重建数据字典是需要终止暂停数据库服务的，而且存在一定的风险，所以一定要慎重行事，选择适当的时间窗口进行操作。本篇主要介绍11gR2环境下如何进行元数据恢复。
1、环境说明
笔者使用Oracle 11gR2进行测试，版本编号为11.2.0.4。
[oracle@localhost ~]$ sqlplus /nolog
SQL*Plus: Release 11.2.0.4.0 Production on Sun Sep 27 11:18:12 2015
Copyright (c) 1982, 2013, Oracle. All rights reserved.
在进行回复之前，要继续完善的备份操作，确保一旦操作失败，起码可以恢复到操作之前的情况，不会让问题变得更糟。
备份手段很多，笔者使用冷备份手段。注意：如果我们可以实现shutdown immediate完全关闭，只需要关闭后备份数据文件、控制文件就可以了。
首先自动生成备份语句。
SQL> select 'cp '||name||' /backup' from v$controlfile;
'CP'||NAME||'/BACKUP'
--------------------------------------------------------------------------------
cp /u01/app/oradata/SICSDB/controlfile/o1_mf_b0m00wf1_.ctl /backup
cp /u01/app/fast_recovery_area/SICSDB/controlfile/o1_mf_b0m00wfq_.ctl /backup
SQL> select 'cp '||file_name||' /backup' from dba_data_files;
'CP'||FILE_NAME||'/BACKUP'
--------------------------------------------------------------------------------
cp /u01/app/oradata/SICSDB/datafile/o1_mf_users_b0lzzg2m_.dbf /backup
（篇幅原因，有省略……）
cp /u01/app/oradata/SICSDB/datafile/o1_mf_uattestt_byr5560d_.dbf /backup
16 rows selected
关闭数据库，最好是完全关闭。
[oracle@localhost ~]$ sqlplus /nolog
SQL*Plus: Release 11.2.0.4.0 Production on Sun Sep 27 11:08:58 2015
Copyright (c) 1982, 2013, Oracle. All rights reserved.
SQL> conn / as sysdba
Connected.
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
在操作系统层面执行语句。
[oracle@localhost ~]$ cp /u01/app/oradata/SICSDB/datafile/o1_mf_users_b0lzzg2m_.dbf /backup
（篇幅原因，有省略……）
[oracle@localhost ~]$ cd /backup/
[oracle@localhost backup]$ ls -l
total 33586456
-rw-r-----. 1 oracle oinstall 9748480 Sep 27 11:09 o1_mf_b0m00wf1_.ctl
-rw-r-----. 1 oracle oinstall 9748480 Sep 27 11:10 o1_mf_b0m00wfq_.ctl
（篇幅原因，有省略……）
-rw-r-----. 1 oracle oinstall 406331392 Sep 27 11:10 o1_mf_users_b0lzzg2m_.dbf
完成了备份，就可以开始进行修复。
2、修复元数据
首先启动数据库，进入upgrade模式。
[oracle@localhost ~]$ sqlplus /nolog
SQL*Plus: Release 11.2.0.4.0 Production on Sun Sep 27 11:18:12 2015
Copyright (c) 1982, 2013, Oracle. All rights reserved.
SQL> conn / as sysdba
Connected to an idle instance.
SQL> startup upgrade
ORACLE instance started.
Total System Global Area 5344731136 bytes
Fixed Size 2262656 bytes
Variable Size 1207961984 bytes
Database Buffers 4127195136 bytes
Redo Buffers 7311360 bytes
Database mounted.
Database opened.
系列执行脚本一共有三个，分别进行不同的数据创建。执行脚本一定要在Server端进行，确保版本的一致性。首先执行catalog.sql脚本。
SQL> spool test.log
SQL> @?/rdbms/admin/catalog.sql
Grant succeeded.
PL/SQL procedure successfully completed.
TIMESTAMP
--------------------------------------------------------------------------------
COMP_TIMESTAMP CATALOG 2015-09-27 11:20:34
第二步执行catproc.sql脚本。
SQL> @?/rdbms/admin/catproc.sql
PL/SQL procedure successfully completed.
SQL>
SQL> SELECT dbms_registry_sys.time_stamp('CATPROC') AS timestamp FROM DUAL;
TIMESTAMP
--------------------------------------------------------------------------------
COMP_TIMESTAMP CATPROC 2015-09-27 11:29:12
1 row selected.
最后，重新编译compile所有的对象。
SQL> SET SERVEROUTPUT OFF
SQL> @?/rdbms/admin/utlrp.sql
DOC>
DOC> 1. Query showing jobs created by UTL_RECOMP
DOC> SELECT job_name FROM dba_scheduler_jobs
DOC> WHERE job_name like 'UTL_RECOMP_SLAVE_%';
DOC>
DOC> 2. Query showing UTL_RECOMP jobs that are running
DOC> SELECT job_name FROM dba_scheduler_running_jobs
DOC> WHERE job_name like 'UTL_RECOMP_SLAVE_%';
DOC>#
SQL>
SQL> DECLARE
2 threads pls_integer := &&1;
3 BEGIN
4 utl_recomp.recomp_parallel(threads);
5 END;
6 /
在三个脚本中，笔者认为第三个脚本最重要。如果有组件在重构之后还存在问题，就体现在这个环节中。因为这个过程会将所有的元数据对象依次并行进行编译，如果组件有问题，是会有编译故障的。我们从输出的结果，可以看出是否是成功的。
如果有问题，通常第三个脚本会有明确的错误列表。
SQL> EXECUTE dbms_registry_sys.validate_components;
FAILED CHECK FOR PACKAGE BODY CTX_ADM
Warning: XDB now invalid, invalid objects found:
object_name object_type
-------------------------------------------------------
DBMS_XDBZ0 PACKAGE BODY
DBMS_XDBZ PACKAGE BODY
DBMS_XDB PACKAGE BODY
DBMS_XDBUTIL_INT PACKAGE BODY
XDB$PATCHUPSCHEMA PROCEDURE
XDB$ACL_PKG_INT PACKAGE BODY
ORDIM INVALID OBJECTS: ORDIMAGE - INVALID - TYPE BODY
ORDIM INVALID OBJECTS: SI_STILLIMAGE - INVALID - TYPE BODY
ORDIM INVALID OBJECTS: ORDDICOM - INVALID - TYPE BODY
ORDIM INVALID OBJECTS: ORDPLSGWYUTIL - INVALID - PACKAGE BODY
ORDIM INVALID OBJECTS: ORDIMGSI_PKG - INVALID - PACKAGE BODY
ORDIM INVALID OBJECTS: ORD_DICOM_PKG - INVALID - PACKAGE BODY
ORDIM INVALID OBJECTS: ORD_DICOM_CT - INVALID - PACKAGE BODY
ORDIM INVALID OBJECTS: ORD_DICOM_ADMIN_PRV - INVALID - PACKAGE BODY
ORDIM INVALID OBJECTS: ORD_DICOM_ADMIN - INVALID - PACKAGE BODY
FAILED CHECK FOR FUNCTION APEX_APPLICATION_GET_PG_TNAME
PL/SQL procedure successfully completed.
完成了编译之后，就可以重新启动数据库。如果没有进一步的问题，就可以恢复使用。
[oracle@localhost backup]$ sqlplus /nolog
SQL*Plus: Release 11.2.0.4.0 Production on Sun Sep 27 11:42:52 2015
Copyright (c) 1982, 2013, Oracle. All rights reserved.
SQL> conn / as sysdba
Connected.
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.
Total System Global Area 5344731136 bytes
Fixed Size 2262656 bytes
Variable Size 1207961984 bytes
Database Buffers 4127195136 bytes
Redo Buffers 7311360 bytes
Database mounted.
Database opened.
3、结论
重构数据库元数据，是我们修复一些数据库故障的方法之一。但是，这种方法并不能完全解决所有元数据问题。一些由于Oracle Bug潜在引起的问题，是不能通过这种途径进行解决的。