如同我们每年都要进行健康检查，防患于未然一样，数据库系统也一直处于动态变化之中，也应该定期进行健康检查。
数据库健康检查应该包括哪些内容？其宗旨和策略是什么？客户、Oracle自身技术人员对数据库健康检查如何看待？Oracle有哪些健康检查新工具？这些就是本章将要展开的话题。
生活在现代社会尤其生活在大都市快节奏下的人们，越来越关爱自己的身体，不太令人放心的食品安全，更有严重恶化的环境等因素，都对我们的身体带来负面影响。于是，每年的例行常规体检成了很多人生活中的一个重要内容。尽管每年的体检报告内容大同小异，但大家仍然还是不敢掉以轻心，尽可能地防患于未然。
于是与常规体检类似，定期进行数据库健康检查（DatabaseHealthCheck），成了保障IT系统平稳运行的一个重要任务，也成了Oracle服务的一项常规内容。
由于该工作成了例行工作，客户也由最初的新鲜感到产生一定的审美疲劳了，于是要求Oracle公司一天检查好几套，甚至上十套系统，工程师真成了整天都在Ctrl+C、Ctrl+V了，甚至难免会出现张冠李戴的情况。“我们银行业务系统的检查报告怎么出现了电信计费系统？”“你们工程师能不能更敬业点？”这是我亲耳听到的客户抱怨。
目录
可见，检查内容涵盖例程（Instance）、方案（Schema）、安全性、存储等多个方面。例如以下是数据库和例程检查项目的详细信息：
如果通过OEM工具直接生成检查报告，一天真能生成十几个报告。数年前，我就是通过该工具，为某银行客户的数据库系统，辗转好几个城市，进行数据库巡检工作。为配合这次巡检，该银行还专门派了一位技术人员与我同行，一方面让他负责进行一些协调工作，另一方面也让他了解Oracle公司进行健康检查的套路。刚开始，他也是充满好奇和新鲜，连眼睛都不眨地仔细观察我的检查过程，特别是脚本，并详细阅读我写的报告。但到了最后一个城市，我的报告也快变成党八股了，他也觉得索然无味，也不奉陪我了，最后只数数报告数量了。呵呵。
限于篇幅，在本书无法展开检查报告的整个内容，下面将就报告中几个重要问题展开叙述。
就在这次检查工作中，我们通过Oracle产生的报告发现了该系统备份没有成功的问题，更发现了可能导致生产系统宕机和挂起的重大隐患。以下就是详细过程：
检查结果：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：Errorreceivedfrommediamanagerlayer,errortext:
ANS1352E(RC52)Sessionrejected:Passwordhasexpired
磁带库没有mount的错误信息如下：
ORA-19511:Errorreceivedfrommediamanagerlayer,errortext:
ANS1312E(RC12)Servermediamountnotpossible
RMAN>listbackup;
记得在这次检查工作中，主管领导得知系统可能宕机的重大风险后，被吓得脸色惨白，呵呵。当时他说：“我们这个系统虽然交易量不大，但交易金额一天就几十个亿啊，如果宕机，损失不敢想像。”幸亏我们通过健康检查提前一周发现并排除了该风险，同时提出了改进和防范措施。
问题描述：系统中有多个无效的Package包。该系统将使用到DBMS_STATS和DBMS_JOB包。
问题原因：经分析，原因是在安装时将9.2.0.1升级到9.2.0.2之后，没有运行utlrp.sql。
解决办法：这些包对目前的生产系统没有影响，但建议还是将上述包重新编译，以防未来使用到这些package时，系统报错。解决办法有两种：
运行utlrp.sql。具体步骤如下：
$cd$ORACLE_HOME/rdbms/admin
$sqlplus“/assysdba”
SQL>@utlrp.sql
或直接重新编译上述包。命令如下：
SQL>alterpackage
SQL>alterpackage
问题描述：数据库服务器上的agent程序主要为OEM提供有关操作系统级的性能数据，以及执行OEM的有关作业操作等。目前agent程序无法启动，出现如下错误：
exec():0509-036Cannotloadprogramagentctlbecauseofthefollowingerrors:
0509-150Dependentmodule/oracle/app/oracle/product/9.2.0/lib/libvppdc.socouldnotbeloaded.
0509-103Themodulehasaninvalidmagicnumber.
问题原因：Oracle9i中的agentctl为32位程序，而环境变量没有设置32位的lib库路径。
解决办法：在.profile中将LIBPATH进行如下修改：
LIBPATH=$ORACLE_HOME/lib32:$ORACLE_HOME/lib:$ORACLE_HOME/ctx/lib:/usr/lib
整个检查报告略，以下仅摘要该报告汇总的问题和建议：
以下就是我罗列的该系统问题：
该系统现有配置为IBM5703C/18GB，而且运行了两个数据库事例，而数据容量已经达到3TB。
作为典型的数据仓库系统，该系统的大部份应用都是大批量数据处理，特别是夜间的ETL批处理，资源消耗非常大。因此，我们首先建议，在条件许可的情况下，先进行硬件资源扩容，将极大地满足大批量数据处理的需求，而且为并行处理等技术的运用奠定基础。这也是简单、快捷而有一定成效的方法。
该系统目前数据库版本为10.2.0.4，并且没有安装PSU和其它推荐小补丁，使得Oracle数据库系统本身运行存在一定风险。建议升级到10gR2最后一个版本10.2.0.5，并且安装相应的PSU和其它推荐小补丁。
经分析，该系统最消耗资源语句基本为数据仓库大批量数据处理语句，其中大部分应用设计质量较高，但部分语句存在一定的质量问题。例如若干表缺乏合理的索引策略，导致全表扫描，以及索引效率不高等问题。
该系统运行在非归档模式下，主要数据存储在RIDSDAT、RIDSTMP、RIDSIDX等少数表空间上，导致目前的备份方案主要为全库冷备份方案，达到10余个小时之上。
因此，如何根据应用情况，进行表空间的细粒度设计，合理设计备份方案，也是该系统需要改进的重要方面。
由于数据量太大，该系统的自动统计信息采集功能被关闭。但目前缺乏全面、定制化的统计信息采集方案，导致部分SQL语句由于统计信息不准确，使得Oracle优化器没有产生最佳的执行计划。
根据分析，该系统虽然进行了部分分区，但分区方法比较简单，也没有实施索引分区技术。因此，可以结合SQL应用优化进行全面的分区方案完善和实施工作。
该系统存在大量DML操作，导致空间碎片问题严重。空间碎片问题不仅导致空间浪费，而且也导致访问效率的低下。
该系统目前采用了普通文件系统技术，底层存储进行了条带化处理。但由于存储不断扩容，而没有进行I/O重新条带化，导致I/O负载不均衡。如果采用Oracle自动存储管理（ASM）技术，将有效解决这种问题。
下面结合上述最近一次我和同事的健康检查工作，对健康检查特别是Oracle公司现有的检查内容、方法等进行一番点评和建议。
首先，我和同事都英雄所见略同地发现了一些相似问题，并提出了相同建议。例如，发现系统硬件资源不够，需要扩容；数据库版本需要安装补丁集；应用存在一定问题；数据库运行在非归档模式；等等。
其次，实事求是而言，我的分析内容和角度比我的同事，也就是Oracle公司现有的检查模板内容更丰富和更全面一些，也更有效地分析出了该系统更具体、更深层次的问题。
下面针对数据库健康检查工作进行进一步点评：
现有规范化检查报告应从更多角度和层次，涵盖更多检查和分析内容。例如，数据库分区技术是Oracle最能体现海量数据库处理能力的关键技术，健康检查应包括客户应用系统分区技术的实施分析。再则，采集和及时更新统计信息，是确保Oracle采用CBO优化器，进而在整体上保证应用性能最佳的重要手段，健康检查应包括统计信息采集方案实施情况的分析。另外，数据库碎片是数据库系统不可避免的问题，健康检查应在碎片指标分析、碎片整理技术方案等方面给客户数据库以专题分析和建议。
Oracle公司提交的报告往往都是一个系统数十页，但大部分内容都是天下太平、一切正常的检查结果。虽然也在报告前面部分进行了问题总结，但一方面这些所谓问题分析其实并不全面、深刻，另一方面客户更是为后面大量罗列的数据弄得昏昏欲睡，更如白开水一般。即便报告里的确藏有真知灼见，但也被这些信息“垃圾”所淹没了。难怪乎客户会将Oracle检查报告束之高阁，视为鸡肋了。
这与某庸医在诊断书上大笔一挥：“该病人高烧不退，原因不明，请病人加强自我调养”，有何差异？
客户要求的是你不仅给我找出这些最消耗资源语句，更应该通过与开发人员沟通，共同给出具体解决建议，例如增加索引、调整语句编写方式、收集统计信息、使用SQLProfile、增加或调整分区方案等等，甚至进行优化前后的对比测试，以及最终实施建议。
这么多年来，数据库健康检查工作已经成为客户不满意、工程师厌倦，人见人烦的鸡肋。如何走出这种困境和怪圈，其实需要客户和Oracle公司共同努力，特别是Oracle公司应主动、积极地加以改进，并求得客户的理解和支持，更应在高度、态度和角度方面去下功夫。
首先，Oracle数据库健康检查不应局限于硬件、操作系统、数据库配置这么低层次的东西，而应在整个系统架构、业务和应用分析的高度去把握和展开分析工作。
其次，Oracle技术人员的确应有更积极、主动的态度。健康检查应该有模板，但客户系统千变万化，就象一千人读《红楼梦》有一千种解读一样，我们应不拘泥于模板，而是真正以客户系统为中心，以高度负责任的态度，特别是主动加强与客户架构设计、应用开发、测试、运行维护管理人员的沟通，全面细致地开展这项工作。
第三，在具体实施工作中，应从更多角度，运用更多方法和工具，以科学严谨、求真务实的精神去开展工作。真正深入进去一件事情了，你就一定会喜欢上它。请允许我用如下警句与同事们共勉：
做我所爱，爱我所做。
采用新的技术去不断丰富健康检查内容和检查手段，是提高健康检查工作质量的重要方面。下面将介绍11g健康检查新特性：HealthMonitor的基本原理、使用方式、报告内容等。
HealthMonitor是Oracle11g之后推出的进行数据库健康检查的新工具。该工具可检查数据文件坏块（包括逻辑和物理坏块）、UNDO和REDO文件坏块、数据字典坏块等。
该工具可运行在被动（Reactive）和手工（Manual）两种模式，前者是系统在发生重大故障时自动进行检查的模式。后者则是DBA通过DBMS_HM包或OEM图形界面两种方式手工运行该工具，并产生报告的工作模式。
该工具可在数据库打开或NOMOUNT状态下运行，前者称之为DB-online方式，后者称之为DB-offline方式。
HealthMonitor可检查如下方面内容：
该检查将对数据库文件完整性进行检查，并在报告中描述可能存在的不可访问文件、坏块和不一致性。在DB-online方式下，Oracle检查控制文件中罗列的所有数据文件和日志文件。在DB-offline方式下，Oracle只检查控制文件。
该检查将在数据块级检查坏块问题，例如checksum问题、head/tail不匹配问题、逻辑不一致性问题等。坏块信息将被记录在V$DATABASE_BLOCK_CORRUPTION中。该检查不包括数据块之间和段之间的问题。
该检查将对联机日志和归档日志文件进行完整性检查，包括能否访问、是否有坏块等，并在报告中汇总这些问题。
该检查将对UNDO表空间进行回退段完整性检查，例如可能存在的UNDO逻辑坏块。一旦发现UNDO坏块，Oracle将通过PMON和SMON进程去恢复被损坏的事务。如果恢复失败，Oracle将UNDO坏块信息保存在v$corrupt_xid_list视图之中。通过强制commit操作，大多数UNDO坏块可以得到恢复。
该检查与回退段完整性检查相似，区别在于事务完整性检查只对指定的事务进行检查。
该检查将对核心数据字典进行完整性检查。例如：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$,andecol$.
Oracle可通过DBMS_HM包或OEM图形界面两种方式手工运行HealthMonitor工具，限于篇幅，本书只介绍DBMS_HM包使用方式：
通过DBMS_HM.RUN_CHECK，可进行指定项目的检查，例如：
上述语句对数据库结构完整性（DBStructureIntegrity）进行检查，检查结果保存在名称为check1的报告中。
执行如下语句，可查询所有可检查的项目，例如：
NAME
DBStructureIntegrityCheck
CFBlockIntegrityCheck
DataBlockIntegrityCheck
RedoIntegrityCheck
TransactionIntegrityCheck
UndoSegmentIntegrityCheck
DictionaryIntegrityCheck
ASMAllocationCheck
有些检查项需要输入参数，以下语句可了解输入参数含义：
SELECTc.namecheck_name,p.nameparameter_name,p.type,p.default_value,p.description
FROMv$hm_check_paramp,v$hm_checkc
ORDERBYc.name;
查询结果如下：
通过以下命令可生成纯文本格式的HealthMonitor报告：
SQL>SETLONG100000
SQL>SETLONGCHUNKSIZE1000
SQL>SETPAGESIZE1000
SQL>SETLINESIZE512
BasicRunInformation
RunName:check1
RunId:61
CheckName:DictionaryIntegrityCheck
Mode:MANUAL
Status:COMPLETED
StartTime:2012-11-2917:00:58.551000+08:00
EndTime:2012-11-2917:01:00.908000+08:00
ErrorEncountered:0
SourceIncidentId:0
NumberofIncidentsCreated:0
InputParamtersfortheRun
TABLE_NAME=ALL_CORE_TABLES
CHECK_MASK=ALL
RunFindingsAndRecommendations
除了HealthMonitor生成的检查报告之外，通过查询如下一些HealthMonitor视图，也能得到更多检查信息。
如下查询可了解曾经进行的各种HealthMonitor检查历史情况：
SELECTrun_id,name,check_name,run_mode,src_incidentFROMv$hm_run;