SHOUG成员 – ORACLE ACS高级顾问罗敏
本文永久地址：https://www.askmac.cn/?p=16585
如同我们每年都要进行健康检查，防患于未然一样，数据库系统也一直处于动态变化之中，也应该定期进行健康检查。
数据库健康检查应该包括哪些内容？其宗旨和策略是什么？客户、Oracle自身技术人员对数据库健康检查如何看待？Oracle有哪些健康检查新工具？这些就是本章将要展开的话题。
什么是数据库健康检查？
数据库健康检查 = 常规体检
生活在现代社会尤其生活在大都市快节奏下的人们，越来越关爱自己的身体，不太令人放心的食品安全，更有严重恶化的环境等因素，都对我们的身体带来负面影响。于是，每年的例行常规体检成了很多人生活中的一个重要内容。尽管每年的体检报告内容大同小异，但大家仍然还是不敢掉以轻心，尽可能地防患于未然。
数据库系统也运行在一个不断变化的世界里，硬件方面可能出现各种服务器、存储、网络故障，数据量、访问量也在不断变化，应用更是在不断地推陈出新，以满足业务不断发展的需求。数据库系统的生存环境、运行状况到底如何？是否有问题和隐患？这是广大客户，特别是DBA们非常关注和担忧的事情。
于是与常规体检类似，定期进行数据库健康检查（Database Health Check），成了保障IT系统平稳运行的一个重要任务，也成了Oracle服务的一项常规内容。
“数据库健康检查就是Ctrl+C、Ctrl+V”？
数年前与一位当时在Oracle服务部门从事实施工作的女同事聊天。在谈到数据库健康检查时，她一脸的无奈：“数据库健康检查就是Ctrl+C、Ctrl+V，一天检查好几个系统，烦死了”。的确，Oracle服务部门已经将数据库健康检查服务做得非常规范化、程式化了，通过RDA、AWR等工具抓取相关系统大量信息之后，然后就是在检查报告模版里开始拷贝、粘贴的工作。
由于该工作成了例行工作，客户也由最初的新鲜感到产生一定的审美疲劳了，于是要求Oracle公司一天检查好几套，甚至上十套系统，工程师真成了整天都在Ctrl+C、Ctrl+V了，甚至难免会出现张冠李戴的情况。“我们银行业务系统的检查报告怎么出现了电信计费系统？”“你们工程师能不能更敬业点？”这是我亲耳听到的客户抱怨。
虽然的确有少数工程师不够职业，但也不能完全责备工程师。客户一天要求我们检查10几套库，我们只能拷贝、粘贴了，哪有时间和精力去做更深层次、更个性化的分析工作？更无暇与架构设计、应用开发等更多人员进行沟通，出点错也在所难免。关键是客户自己也将该工作视为例行公事了，一个季度检查一次，客户往往将报告束之高阁，只数报告数量，并不仔细阅读。检查报告本身也被工程师做成了党八股，数据库健康检查工作真成了弃之可惜、食之无味的鸡肋了，呵呵。
13.2 多年前一次健康检查
基于Oracle工具的数据库健康检查
针对数据库常规健康检查工作，Oracle公司早就提出了规范化的检查项目，甚至嵌入到了相关产品中。例如，当年在9i OEM里面就有一个菜单项“Health Check”，通过该工具可进行规范化的常规检查，包括数据库配置和运行状况检查，并能生成图文并茂的HTML报告，甚至支持中文。以下就是该报告的目录：
目录
可见，检查内容涵盖例程（Instance）、方案（Schema）、安全性、存储等多个方面。例如以下是数据库和例程检查项目的详细信息：
| DB 名称 | CDCCPC |
| 全局名 | CDCCPC |
| DB 版本 | Oracle9i Enterprise Edition Release 9.2.0.2.0 – 64bit Production |
| 主机名 | CCPCA |
| 例程名 | CDCCPC |
| 例程启动时间 | 18-六月 -2003 |
| 限制模式 | NO |
| 归档日志模式 | ARCHIVELOG |
| 只读模式 | NO |
如果通过OEM工具直接生成检查报告，一天真能生成十几个报告。数年前，我就是通过该工具，为某银行客户的数据库系统，辗转好几个城市，进行数据库巡检工作。为配合这次巡检，该银行还专门派了一位技术人员与我同行，一方面让他负责进行一些协调工作，另一方面也让他了解Oracle公司进行健康检查的套路。刚开始，他也是充满好奇和新鲜，连眼睛都不眨地仔细观察我的检查过程，特别是脚本，并详细阅读我写的报告。但到了最后一个城市，我的报告也快变成党八股了，他也觉得索然无味，也不奉陪我了，最后只数数报告数量了。呵呵。
毕竟Oracle工具只能针对一个系统的通用状况进行检查，若想发现具体问题，特别是发现与应用相关的问题，需要更多的细心分析，以及与客户、应用开发商和其它厂商的沟通。以下就是这次检查中，我基于Oracle工具产生的HTML标准格式的健康检查报告，在更多方面进行强化之后形成的检查报告文档目录：
限于篇幅，在本书无法展开检查报告的整个内容，下面将就报告中几个重要问题展开叙述。
发现了重大隐患
就在这次检查工作中，我们通过Oracle产生的报告发现了该系统备份没有成功的问题，更发现了可能导致生产系统宕机和挂起的重大隐患。以下就是详细过程：
- 备份集检查
| 备份碎片名称 | 完成时间 | 备份类型 | 设备类型 | 备份集时间戳 | 备份集计数 |
| c-2151840866-20030713-00 | 13-七月 –2003 | Full Backup | SBT_TAPE | 499226687 | 496 |
| CDCCPC_499226683_ffes361r_1_1 | 13-七月 -2003 | Archivelog Backup | SBT_TAPE | 499226683 | 495 |
| CDCCPC_499226416_fees35pg_1_1 | 13-七月 -2003 | Full Backup | SBT_TAPE | 499226416 | 494 |
检查结果：7月13日备份集正常。但数据库自7月13日以来，由于磁带库管理软件TSM客户端的口令过期，导致RMAN物理备份没有成功。
- 问题原因和后果
该问题如果不及时解决，会最终导致生产系统停机。事件的因果关系如下：
TSM客户端的口令过期 –>导致RMAN无法备份到磁带库 -> 导致归档日志文件无法清除 -> 导致归档日志满 -> 导致Oracle数据库被挂起 -> 导致CICS宕机。
该系统自7月13日以来，TSM客户端的口令已经过期，目前归档日志文件已达到68%。如果不及时处理，预计再过一周左右，会导致Oracle数据库被挂起和CICS宕机。
- 解决途径
请IBM或集成商提供修改TSM客户端口令和期限的命令。同时，保障磁带库的状态正常。
- 数据库物理备份的检查
方法1：在数据库服务器中，查看/oracle/sql/rman/full_backup.log文件，可检查前一天数据库的物理备份是否正常。
例如，TSM客户端的口令过期的错误信息如下：
ORA-19511：Error received from media manager layer, error text:
ANS1352E(RC52) Session rejected : Password has expired
磁带库没有mount的错误信息如下：
ORA-19511: Error received from media manager layer, error text:
ANS1312E (RC12) Server media mount not possible
方法2：在RMAN中检查最新备份集的时间，命令如下：
$ rman catalog rman/rman@rcv target /
RMAN> list backup;
请检查数据文件、归档日志和SPFILE的备份集时间。
记得在这次检查工作中，主管领导得知系统可能宕机的重大风险后，被吓得脸色惨白，呵呵。当时他说：“我们这个系统虽然交易量不大，但交易金额一天就几十个亿啊，如果宕机，损失不敢想像。”幸亏我们通过健康检查提前一周发现并排除了该风险，同时提出了改进和防范措施。
其它几个典型问题
问题描述：系统中有多个无效的Package包。该系统将使用到DBMS_STATS和DBMS_JOB包。
问题原因：经分析，原因是在安装时将9.2.0.1升级到9.2.0.2之后，没有运行utlrp.sql。
解决办法：这些包对目前的生产系统没有影响，但建议还是将上述包重新编译，以防未来使用到这些package时，系统报错。解决办法有两种：
运行utlrp.sql。具体步骤如下：
$ cd $ORACLE_HOME/rdbms/admin
$ sqlplus “/as sysdba”
SQL> @utlrp.sql
或直接重新编译上述包。命令如下：
$ sqlplus “/as sysdba”
SQL> alter package <package名称> compile;
SQL> alter package <package名称> compile body;
问题描述：数据库服务器上的agent程序主要为OEM提供有关操作系统级的性能数据，以及执行OEM的有关作业操作等。目前agent程序无法启动，出现如下错误：
exec():0509-036 Cannot load program agentctl because of the following errors:
0509-150 Dependent module /oracle/app/oracle/product/9.2.0/lib/libvppdc.so could not be loaded.
0509-103 The module has an invalid magic number.
问题原因：Oracle 9i中的agentctl为32位程序，而环境变量没有设置32位的lib库路径。
解决办法：在.profile中将LIBPATH进行如下修改：
LIBPATH=$ORACLE_HOME/lib32:$ORACLE_HOME/lib:$ORACLE_HOME/ctx/lib:/usr/lib
即LIBPATH环境变量增加32位的lib库路径（本文永久地址：https://www.askmac.cn/?p=16585）。
13.3最近一次健康检查
Oracle公司的数据库健康检查
- 检查内容
通常而言，Oracle服务部门对一套数据库进行全面检查需要3个工作日，但很多情况下，客户会要求我们在更短的时间检查更多的系统，于是有了标准版本和简化版本之分。以下就是两个版本的检查项目区别：
| 检查内容 | 标准版本 | 简化版本 |
| 硬件配置 | Yes | No |
| 主机配置 | Yes | No |
| 内存参数 | Yes | No |
| 信号量 | Yes | No |
| 系统配置 | Yes | No |
| 操作系统补丁 | Yes | No |
| 硬盘可用空间 | Yes | No |
| 数据库配置 | Yes | No |
| 数据库版本 | Yes | No |
| 数据库产品选项 | Yes | No |
| 数据库参数 | Yes | No |
| 运行日志和跟踪文件 | Yes | No |
| 控制文件 | Yes | No |
| Redo log 文件 | Yes | No |
| 归档Redo log 文件 | Yes | No |
| 数据文件 | Yes | No |
| 表空间 | Yes | No |
| 回滚段管理 | Yes | No |
| 数据库对象 | Yes | No |
| 安全性管理 | Yes | No |
| SQL*Net | Yes | No |
| 监听器的设置 | Yes | No |
| TNSNAMES | Yes | No |
| 数据库备份和恢复概况 | Yes | No |
| 备份 | Yes | No |
| 恢复 | Yes | No |
| 操作系统性能 | Yes | Yes |
| 网络性能 | Yes | No |
| 数据库索引及行链 | Yes | No |
| 数据库性能 | Yes | Yes |
| 建议 | Yes | Yes |
| 主要关注 | Yes | Yes |
| 附录 A: ‘init.ora’ parameter files | Yes | No |
- 检查方法
典型的数据库健康检查
最近，针对某银行数据仓库系统，我的一位同事就是基于上述Oracle标准模板，并通过RDA、AWR、SQL*Plus等工具，开展了一次典型的健康检查。由于时间有限，他只对如下内容进行了检查：
- 主机配置
- 操作系统性能
- 数据库配置
- 数据库性能
整个检查报告略，以下仅摘要该报告汇总的问题和建议：
| No. | 问题描述 | 参考章节 | 建议解决时间 |
| 1 | 夜间4：00-9:30CPU和内存资源不足。建议议适当增加CPU和内存资源，或者优化CPU资源使用。 | 5 | 立即 |
| 2 | 当前数据库的最后一个版本是10.2.0.5建议升级到最后一个补丁集。 | 6 | 近期 |
| 3 | 数据库处于非归档模式，产品数据库通常建议运行于归档模式。 | 6 | 立即 |
| 4 | 2:30-4:30有部份语句，消耗系统大量的IO和CPU资源，建议请应用对语句进行优化。而且在该时间点CPU和IO资源都表现不足。相关语句优化详见相关章节 | 7 | 立即 |
我的“数据库健康检查”
针对相同系统，作为服务解决方案顾问，我在一天时间内，也对该系统进行了一次调研工作，旨在分析该系统存在的问题，为客户提出系统改进和优化服务方案。需要说明的是，我是在完全不知晓我的同事刚刚已经进行了一次健康检查工作情况下，开展我的调研工作的。
以下就是我罗列的该系统问题：
- 硬件需要扩容
该系统现有配置为IBM 570 3C/18GB，而且运行了两个数据库事例，而数据容量已经达到3TB。
作为典型的数据仓库系统，该系统的大部份应用都是大批量数据处理，特别是夜间的ETL批处理，资源消耗非常大。因此，我们首先建议，在条件许可的情况下，先进行硬件资源扩容，将极大地满足大批量数据处理的需求，而且为并行处理等技术的运用奠定基础。这也是简单、快捷而有一定成效的方法。
- 参数配置问题
该系统目前分配给最主要实例ridspd的SGA和PGA分别只有4GB和2GB，各项指标表明：内存资源明显不够。因此，建议结合上述硬件扩容建议，对相关参数进行调整。
- 数据库版本和补丁问题
该系统目前数据库版本为10.2.0.4，并且没有安装PSU和其它推荐小补丁，使得Oracle数据库系统本身运行存在一定风险。建议升级到10g R2最后一个版本10.2.0.5，并且安装相应的PSU和其它推荐小补丁。
- SQL应用问题
经分析，该系统最消耗资源语句基本为数据仓库大批量数据处理语句，其中大部分应用设计质量较高，但部分语句存在一定的质量问题。例如若干表缺乏合理的索引策略，导致全表扫描，以及索引效率不高等问题。
- 表空间设计和备份时间问题
该系统运行在非归档模式下，主要数据存储在RIDSDAT、RIDSTMP、RIDSIDX等少数表空间上，导致目前的备份方案主要为全库冷备份方案，达到10余个小时之上。
因此，如何根据应用情况，进行表空间的细粒度设计，合理设计备份方案，也是该系统需要改进的重要方面。
- 统计信息采集问题
由于数据量太大，该系统的自动统计信息采集功能被关闭。但目前缺乏全面、定制化的统计信息采集方案，导致部分SQL语句由于统计信息不准确，使得Oracle优化器没有产生最佳的执行计划。
- 分区状况不合理
根据分析，该系统虽然进行了部分分区，但分区方法比较简单，也没有实施索引分区技术。因此，可以结合SQL应用优化进行全面的分区方案完善和实施工作。
- 空间碎片严重
该系统存在大量DML操作，导致空间碎片问题严重。空间碎片问题不仅导致空间浪费，而且也导致访问效率的低下。
- I/O 负载不均衡
该系统目前采用了普通文件系统技术，底层存储进行了条带化处理。但由于存储不断扩容，而没有进行I/O重新条带化，导致I/O 负载不均衡。如果采用Oracle自动存储管理（ASM）技术，将有效解决这种问题。
13.4 关于健康检查的点评
下面结合上述最近一次我和同事的健康检查工作，对健康检查特别是Oracle公司现有的检查内容、方法等进行一番点评和建议。
首先，我和同事都英雄所见略同地发现了一些相似问题，并提出了相同建议。例如，发现系统硬件资源不够，需要扩容；数据库版本需要安装补丁集；应用存在一定问题；数据库运行在非归档模式；等等。
其次，实事求是而言，我的分析内容和角度比我的同事，也就是Oracle公司现有的检查模板内容更丰富和更全面一些，也更有效地分析出了该系统更具体、更深层次的问题。
下面针对数据库健康检查工作进行进一步点评：
- 应增加更多检查和分析内容
现有规范化检查报告应从更多角度和层次，涵盖更多检查和分析内容。例如，数据库分区技术是Oracle最能体现海量数据库处理能力的关键技术，健康检查应包括客户应用系统分区技术的实施分析。再则，采集和及时更新统计信息，是确保Oracle采用CBO优化器，进而在整体上保证应用性能最佳的重要手段，健康检查应包括统计信息采集方案实施情况的分析。另外，数据库碎片是数据库系统不可避免的问题，健康检查应在碎片指标分析、碎片整理技术方案等方面给客户数据库以专题分析和建议。
- 应突出问题，不要罗列数据
Oracle公司提交的报告往往都是一个系统数十页，但大部分内容都是天下太平、一切正常的检查结果。虽然也在报告前面部分进行了问题总结，但一方面这些所谓问题分析其实并不全面、深刻，另一方面客户更是为后面大量罗列的数据弄得昏昏欲睡，更如白开水一般。即便报告里的确藏有真知灼见，但也被这些信息“垃圾”所淹没了。难怪乎客户会将Oracle检查报告束之高阁，视为鸡肋了。
- 深入应用、贴近客户
由于时间有限，沟通不够，Oracle提交的报告经常对应用分析缺乏深度，甚至仅仅是罗列若干Top-SQL语句，然后扔下一句：“上述SQL语句资源消耗非常高，请应用开发团队进行深入分析，并给出优化建议。”
这与某庸医在诊断书上大笔一挥：“该病人高烧不退，原因不明，请病人加强自我调养”，有何差异？
客户要求的是你不仅给我找出这些最消耗资源语句，更应该通过与开发人员沟通，共同给出具体解决建议，例如增加索引、调整语句编写方式、收集统计信息、使用SQL Profile、增加或调整分区方案等等，甚至进行优化前后的对比测试，以及最终实施建议。
- 高度、态度和角度
这么多年来，数据库健康检查工作已经成为客户不满意、工程师厌倦，人见人烦的鸡肋。如何走出这种困境和怪圈，其实需要客户和Oracle公司共同努力，特别是Oracle公司应主动、积极地加以改进，并求得客户的理解和支持，更应在高度、态度和角度方面去下功夫。
首先，Oracle数据库健康检查不应局限于硬件、操作系统、数据库配置这么低层次的东西，而应在整个系统架构、业务和应用分析的高度去把握和展开分析工作。
其次，Oracle技术人员的确应有更积极、主动的态度。健康检查应该有模板，但客户系统千变万化，就象一千人读《红楼梦》有一千种解读一样，我们应不拘泥于模板，而是真正以客户系统为中心，以高度负责任的态度，特别是主动加强与客户架构设计、应用开发、测试、运行维护管理人员的沟通，全面细致地开展这项工作。
第三，在具体实施工作中，应从更多角度，运用更多方法和工具，以科学严谨、求真务实的精神去开展工作。真正深入进去一件事情了，你就一定会喜欢上它。请允许我用如下警句与同事们共勉：
做我所爱，爱我所做。
13.5 11g健康检查新特性：Health Monitor
采用新的技术去不断丰富健康检查内容和检查手段，是提高健康检查工作质量的重要方面。下面将介绍11g健康检查新特性：Health Monitor的基本原理、使用方式、报告内容等。
Health Monitor概述
Health Monitor是 Oracle 11g之后推出的进行数据库健康检查的新工具。该工具可检查数据文件坏块（包括逻辑和物理坏块）、UNDO和REDO文件坏块、数据字典坏块等。
该工具可运行在被动（Reactive）和手工（Manual）两种模式，前者是系统在发生重大故障时自动进行检查的模式。后者则是DBA通过DBMS_HM包或 OEM图形界面两种方式手工运行该工具，并产生报告的工作模式。
该工具可在数据库打开或NOMOUNT状态下运行，前者称之为DB-online方式，后者称之为DB-offline方式。
Health Monitor检查内容
Health Monitor可检查如下方面内容：
- DB Structure Integrity Check（数据库结构完整性检查）
该检查将对数据库文件完整性进行检查，并在报告中描述可能存在的不可访问文件、坏块和不一致性。在DB-online方式下，Oracle检查控制文件中罗列的所有数据文件和日志文件。在DB-offline方式下，Oracle只检查控制文件。
- Data Block Integrity Check（数据块完整性检查）
该检查将在数据块级检查坏块问题，例如checksum问题、head/tail不匹配问题、逻辑不一致性问题等。坏块信息将被记录在V$DATABASE_BLOCK_CORRUPTION中。该检查不包括数据块之间和段之间的问题。
- Redo Integrity Check（日志完整性检查）
该检查将对联机日志和归档日志文件进行完整性检查，包括能否访问、是否有坏块等，并在报告中汇总这些问题。
- Undo Segment Integrity Check（回退段完整性检查）
该检查将对UNDO表空间进行回退段完整性检查，例如可能存在的UNDO逻辑坏块。一旦发现UNDO坏块，Oracle将通过PMON和SMON进程去恢复被损坏的事务。如果恢复失败，Oracle将UNDO坏块信息保存在v$corrupt_xid_list视图之中。通过强制commit操作，大多数UNDO坏块可以得到恢复。
- Transaction Integrity Check（事务完整性检查）
该检查与回退段完整性检查相似，区别在于事务完整性检查只对指定的事务进行检查。
- Dictionary Integrity Check（数据字典完整性检查）
该检查将对核心数据字典进行完整性检查。例如：tab$, clu$, fet$, uet$, seg$, undo$, ts$, file$, obj$, ind$, icol$, col$, user$, con$, cdef$, ccol$, bootstrap$, objauth$, ugroup$, tsq$, syn$, view$, typed_view$, superobj$, seq$, lob$, coltype$, subcoltype$, ntab$, refcon$, opqtype$, dependency$, access$, viewcon$, icoldep$, dual$, sysauth$, objpriv$, defrole$, and ecol$.
Health Monitor的使用
Oracle可通过DBMS_HM包或 OEM图形界面两种方式手工运行Health Monitor工具，限于篇幅，本书只介绍DBMS_HM包使用方式：
- 使用举例
通过DBMS_HM.RUN_CHECK，可进行指定项目的检查，例如：
exec DBMS_HM.RUN_CHECK(‘DB Structure Integrity Check’, ‘check1’);
上述语句对数据库结构完整性（DB Structure Integrity）进行检查，检查结果保存在名称为check1的报告中。
- 查询检查项
执行如下语句，可查询所有可检查的项目，例如：
SQL> SELECT name FROM v$hm_check WHERE internal_check=’N’;
NAME
—————————————————————
DB Structure Integrity Check
CF Block Integrity Check
Data Block Integrity Check
Redo Integrity Check
Transaction Integrity Check
Undo Segment Integrity Check
Dictionary Integrity Check
ASM Allocation Check
- 查询输入参数
有些检查项需要输入参数，以下语句可了解输入参数含义：
SELECT c.name check_name, p.name parameter_name, p.type,p.default_value, p.description
FROM v$hm_check_param p, v$hm_check c
WHERE p.check_id = c.id and c.internal_check = ‘N’
ORDER BY c.name;
查询结果如下：
| CHECK_NAME | PARAMETER_NAME | TYPE | DEFAULT_VALUE | DESCRIPTION | |
| 1 | ASM Allocation Check | ASM_DISK_GRP_NAME | DBKH_PARAM_TEXT | ASM 组名 | |
| 2 | CF Block Integrity Check | CF_BL_NUM | DBKH_PARAM_UB4 | 控制文件块号 | |
| 3 | Data Block Integrity Check | BLC_DF_NUM | DBKH_PARAM_UB4 | 文件号 | |
| 4 | Data Block Integrity Check | BLC_BL_NUM | DBKH_PARAM_UB4 | 块号 | |
| 5 | Dictionary Integrity Check | CHECK_MASK | DBKH_PARAM_TEXT | ALL | 检查掩码 |
| 6 | Dictionary Integrity Check | TABLE_NAME | DBKH_PARAM_TEXT | ALL_CORE_TABLES | 表名 |
| 7 | Redo Integrity Check | SCN_TEXT | DBKH_PARAM_TEXT | 0 | 最新良好重做的 SCN (如果已知) |
| 8 | Transaction Integrity Check | TXN_ID | DBKH_PARAM_TEXT | 事务处理 ID | |
| 9 | Undo Segment Integrity Check | USN_NUMBER | DBKH_PARAM_TEXT | 还原段号 |
Health Monitor报告的生成
Oracle可通过DBMS_HM包、OEM和ADRCI工具三种方式生成Health Monitor报告，并可支持纯文本、HTML、 XML等格式。以下仅介绍通过DBMS_HM包生成纯文本格式的Health Monitor报告（本文永久地址：https://www.askmac.cn/?p=16585）。
通过以下命令可生成纯文本格式的Health Monitor报告：
SQL> SET LONG 100000
SQL> SET LONGCHUNKSIZE 1000
SQL> SET PAGESIZE 1000
SQL> SET LINESIZE 512
SQL> SELECT DBMS_HM.GET_RUN_REPORT(‘CHECK1’) FROM DUAL;
DBMS_HM.GET_RUN_REPORT(‘CHECK1’)
—————————————————————
Basic Run Information
Run Name : check1
Run Id : 61
Check Name : Dictionary Integrity Check
Mode : MANUAL
Status : COMPLETED
Start Time : 2012-11-29 17:00:58.551000 +08:00
End Time : 2012-11-29 17:01:00.908000 +08:00
Error Encountered : 0
Source Incident Id : 0
Number of Incidents Created : 0
Input Paramters for the Run
TABLE_NAME=ALL_CORE_TABLES
CHECK_MASK=ALL
Run Findings And Recommendations
Health Monitor相关视图
除了Health Monitor生成的检查报告之外，通过查询如下一些Health Monitor视图，也能得到更多检查信息。
如下查询可了解曾经进行的各种Health Monitor检查历史情况：
SELECT run_id, name, check_name, run_mode, src_incident FROM v$hm_run;
查询结果如下：
| RUN_ID | NAME | CHECK_NAME | RUN_MODE | SRC_INCIDENT | |
| 1 | 21 | my_run | Dictionary Integrity Check | MANUAL | 0 |
| 2 | 61 | check1 | Dictionary Integrity Check | MANUAL | 0 |
| 3 | 81 | check2 | DB Structure Integrity Check | MANUAL | 0 |
| 4 | 101 | check3 | Data Block Integrity Check | MANUAL | 0 |
| 5 | 141 | check4 | Redo Integrity Check | MANUAL | 0 |
| 6 | 161 | check5 | Transaction Integrity Check | MANUAL | 0 |
| 7 | 1 | HM_RUN_1 | DB Structure Integrity Check | REACTIVE | 0 |
如下查询可了解某次检查中发现的问题：
SELECT type, description FROM v$hm_finding WHERE run_id = 1;
查询结果如下：
| TYPE | DESCRIPTION | |
| 1 | FAILURE | 控制文件需要介质恢复 |
| 2 | FAILURE | 系统数据文件 1: ‘C:\11.2.0.1\ORADATA\LYJ\SYSTEM01.DBF’ 需要介质恢复 |
| 3 | FAILURE | 一个或多个非系统数据文件需要介质恢复 |
| 4 | FAILURE | 数据文件 2: ‘C:\11.2.0.1\ORADATA\LYJ\SYSAUX01.DBF’ 需要介质恢复 |
| 5 | FAILURE | 数据文件 3: ‘C:\11.2.0.1\ORADATA\LYJ\UNDOTBS01.DBF’ 需要介质恢复 |
13.6本章参考资料及进一步读物
本章参考资料及进一步读物：
| 序号 | 资料类别 | 资料名称 | 资料概述 |
| 1. | My Oracle Support | 《How to Perform a Health Check on the Database [ID 122669.1]》 | 如何进行数据库健康检查？检查的方法、内容？这篇文档给出了一个官方建议。 |
| 2. | My Oracle Support | 《RACcheck – RAC Configuration Audit Tool (Doc ID 1268927.1)》 | 一个被新工具替换的工具。新工具叫做：ORAchk |
| 3. | My Oracle Support | 《”hcheck.sql” script to check for known problems in Oracle8i, Oracle9i, Oracle10g and Oracle 11g (Doc ID 136697.1)》 | 一个主动检查数据字典问题的Oracle官方详细脚本。 |
| 4. | My Oracle Support | 《Identify Data Dictionary Inconsistency (Doc ID 456468.1)》 | 如何检查Oracle数据库数据字典的一致性？请看这篇文章吧。 |
| 5. | My Oracle Support | 《Script to Install the “hOut” Helper Package (“hout.sql”) (Doc ID 101468.1)》 | 又一个用于健康检查的Oracle官方详细脚本。 |
| 6. | Oracle联机文档 | 《Oracle Administrator’s Guide》第九章之“Running Health Checks with Health Monitor”小节 | 该小节详细介绍了11g新特性：Health Monitor。 |
| 7. | My Oracle Support | 《11g New Feature: Health monitor (Doc ID 466920.1)》 | Metalink中介绍11g新特性：Health Monitor的官方文档。 |
Comment