Oracle元数据重构实验

元数据是几乎所有数据库都具有的基础数据，其中包括基础数据字典、系统功能视图和函数结构等内容。越是功能强大成熟的数据库产品，其元数据信息越是众多复杂。在Oracle世界中，我们经常使用的性能工具AWR、作业Scheduler和RMAN工具，甚至Data Pump工具，都是建立在数据字典的基础上。大部分数据字典是在sys和system用户schema下，普通用户只是通过同义词调用和访问对象，删除破坏的风险的是比较低的。在实践工作中，主要有两种情况会破坏元数据：管理员帐号误操作和系统内部运行数据损坏。无论是哪一种情况，元数据损坏的故障通常是很麻烦的，越是基础的元数据损坏，故障现象就越是紧急复杂和多变。数据库组件之间，存在严格的依赖关系。一个基础元数据损坏，可能导致若干依赖的组件不能成功编译使用。如果是一些单纯的组件，如XDB、Data Pump的损坏，可以调用特定的创建脚本重建对象。但是如果是一些基础的组件错误，连带骨牌效应，就需要重建数据字典了。重建数据字典是需要终止暂停数据库服务的，而且存在一定的风险，所以一定要慎重行事，选择适当的时间窗口进行操作。本篇主要介绍11gR2环境下如何进行元数据恢复。1、环境说明笔者使用Oracle 11gR2进行测试，版本编号为11.2.0.4。[oracle@localhost ~]$ sqlplus /nologSQL*Plus: Release 11.2.0.4.0 Production on Sun Sep 27 11:18:12 2015Copyright （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 /backupcp /u01/app/fast_recovery_area/SICSDB/controlfile/o1_mf_b0m00wfq_.ctl /backupSQL> 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 /backup16 rows selected关闭数据库，最好是完全关闭。[oracle@localhost ~]$ sqlplus /nologSQL*Plus: Release 11.2.0.4.0 Production on Sun Sep 27 11:08:58 2015Copyright （c） 1982, 2013, Oracle. All rights reserved.SQL> conn / as sysdbaConnected.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 -ltotal 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 /nologSQL*Plus: Release 11.2.0.4.0 Production on Sun Sep 27 11:18:12 2015Copyright （c） 1982, 2013, Oracle. All rights reserved.SQL> conn / as sysdbaConnected to an idle instance.SQL> startup upgradeORACLE instance started.Total System Global Area 5344731136 bytesFixed Size 2262656 bytesVariable Size 1207961984 bytesDatabase Buffers 4127195136 bytesRedo Buffers 7311360 bytesDatabase mounted.Database opened.系列执行脚本一共有三个，分别进行不同的数据创建。执行脚本一定要在Server端进行，确保版本的一致性。首先执行catalog.sql脚本。SQL> spool test.logSQL> @？/rdbms/admin/catalog.sqlGrant succeeded.PL/SQL procedure successfully completed.TIMESTAMP--------------------------------------------------------------------------------COMP_TIMESTAMP CATALOG 2015-09-27 11:20:34第二步执行catproc.sql脚本。SQL> @？/rdbms/admin/catproc.sqlPL/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:121 row selected.最后，重新编译compile所有的对象。SQL> SET SERVEROUTPUT OFFSQL> @？/rdbms/admin/utlrp.sqlDOC>DOC> 1. Query showing jobs created by UTL_RECOMPDOC> SELECT job_name FROM dba_scheduler_jobsDOC> WHERE job_name like "UTL_RECOMP_SLAVE_%";DOC>DOC> 2. Query showing UTL_RECOMP jobs that are runningDOC> SELECT job_name FROM dba_scheduler_running_jobsDOC> 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_ADMWarning: XDB now invalid, invalid objects found:object_name object_type-------------------------------------------------------DBMS_XDBZ0 PACKAGE BODYDBMS_XDBZ PACKAGE BODYDBMS_XDB PACKAGE BODYDBMS_XDBUTIL_INT PACKAGE BODYXDB$PATCHUPSCHEMA PROCEDUREXDB$ACL_PKG_INT PACKAGE BODYORDIM INVALID OBJECTS: ORDIMAGE - INVALID - TYPE BODYORDIM INVALID OBJECTS: SI_STILLIMAGE - INVALID - TYPE BODYORDIM INVALID OBJECTS: ORDDICOM - INVALID - TYPE BODYORDIM INVALID OBJECTS: ORDPLSGWYUTIL - INVALID - PACKAGE BODYORDIM INVALID OBJECTS: ORDIMGSI_PKG - INVALID - PACKAGE BODYORDIM INVALID OBJECTS: ORD_DICOM_PKG - INVALID - PACKAGE BODYORDIM INVALID OBJECTS: ORD_DICOM_CT - INVALID - PACKAGE BODYORDIM INVALID OBJECTS: ORD_DICOM_ADMIN_PRV - INVALID - PACKAGE BODYORDIM INVALID OBJECTS: ORD_DICOM_ADMIN - INVALID - PACKAGE BODYFAILED CHECK FOR FUNCTION APEX_APPLICATION_GET_PG_TNAMEPL/SQL procedure successfully completed.完成了编译之后，就可以重新启动数据库。如果没有进一步的问题，就可以恢复使用。[oracle@localhost backup]$ sqlplus /nologSQL*Plus: Release 11.2.0.4.0 Production on Sun Sep 27 11:42:52 2015Copyright （c） 1982, 2013, Oracle. All rights reserved.SQL> conn / as sysdbaConnected.SQL> shutdown immediate;Database closed.Database dismounted.ORACLE instance shut down.SQL> startupORACLE instance started.Total System Global Area 5344731136 bytesFixed Size 2262656 bytesVariable Size 1207961984 bytesDatabase Buffers 4127195136 bytesRedo Buffers 7311360 bytesDatabase mounted.Database opened.3、结论重构数据库元数据，是我们修复一些数据库故障的方法之一。但是，这种方法并不能完全解决所有元数据问题。一些由于Oracle Bug潜在引起的问题，是不能通过这种途径进行解决的。更多Oracle相关信息见Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx？tid=12本文永久更新链接地址