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潜在引起的问题，是不能通过这种途径进行解决的。