Oracle 11g Health Monitor(原创)

Health Monitor
Oracle Database 11g includes a new framework called the Health Monitor, which runs diagnostic checks in the database. The data base automatically runs Health Monitor checks in response to critical errors. The checks examine database components such as memory, process usage, and transaction integrity. You can also run your own health checks by using either Enterprise Manager or the new DBMS_HM package. Each time a health check runs, it generates a report of its execution, which includes information such as the health check’s findings graded accorded to priority (high, critical, or low) and execution statistics.
You can run the Health Monitor checks in two ways:.

• Reactive—The fault diagnosability infrastructure can run health checks automatically in response to a critical error.
• Manual—As a DBA, you can manually run health checks using either the DBMS_HM PL/SQL package or the Enterprise Manager interface. You can run checkers on a regular basis if desired, or Oracle Support may ask you to run a checker while working with you on a service request.

You can query the V$HM_CHECK view to get a list of the possible health checks that can be run, as shown here:
SQL> select name, description from v$hm_check;
NAME                                    DESCRIPTION
---------------------                ---------------------------
HM Test Check                         Check for HM Functionality
DB Structure Integrity Check          Checks integrity of all Database files
Data Block Integrity Check            Checks integrity of a datafile block
Redo Integrity Check                  Checks integrity of redo log content
...............................................
Txn Revalidation Check                Revalidate corrupted txn
Failure Simulation Check              Creates dummy failures
Dictionary Integrity Check            Checks dictionary integrity
21 rows selected.
At any given time, the database may be running only some of the checks listed in the V$HM_CHECK view. The V$HM_RUN view shows details about the actual checks performed by the Health Monitor, both automatic as well as the ones that were run by the DBA.
There are two types of health checks: DB-online and DB-offline. The online checks can be run when the database is in the open or mount mode. The offline checks can also be run in the nomount mode. All checks are online except the Redo Check and Data Crosscheck, which are offline checks.The offline_capable field represent the check type.

Types of Health Checks
Health monitor runs the following checks:

• DB Structure Integrity Check—This check verifies the integrity of database files and reports failures if these files are inaccessible, corrupt or inconsistent. If the database is in mount or open mode, this check examines the log files and data files listed in the control file. If the database is in NOMOUNT mode, only the control file is checked.
• Data Block Integrity Check—This check detects disk image block corruptions such as checksum failures, head/tail mismatch, and logical inconsistencies within the block. Most corruptions can be repaired using Block Media Recovery. Corrupted block information is also captured in the V$DATABASE_BLOCK_CORRUPTION view. This check does not detect inter-block or inter-segment corruption.
• Redo Integrity Check—This check scans the contents of the redo log for accessibility and corruption, as well as the archive logs, if available. The Redo Integrity Check reports failures such as archive log or redo corruption.
• Undo Segment Integrity Check—This check finds logical undo corruptions. After locating an undo corruption, this check uses PMON and SMON to try to recover the corrupted transaction. If this recovery fails, then Health Monitor stores information about the corruption in V$CORRUPT_XID_LIST. Most undo corruptions can be resolved by forcing a commit.
• Transaction Integrity Check—This check is identical to the Undo Segment Integrity Check except that it checks only one specific transaction.
• Dictionary Integrity Check—This check examines the integrity of core dictionary objects, such as tab$ and col$. It performs the following operations:
  
  • Verifies the contents of dictionary entries for each dictionary object.
  • Performs a cross-row level check, which verifies that logical constraints on rows in the dictionary are enforced.
  • Performs an object relationship check, which verifies that parent-child relationships between dictionary objects are enforced.
  • The Dictionary Integrity Check operates on the following dictionary objects:
    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$.

Running a Health Check
You can run a health check from Enterprise Manager’s Health Monitor interface or by using the DBMS_HM package. You can access the Health Monitor interface in Enterprise Manager by clicking the Checkers tab on the Advisor Central page. From this page, you can run checks (also called checkers) and view the findings of those checks.
You can use the RUN_CHECK procedure of the DBMS_HM package to run any check that’s listed in the V$HM_CHECK view. The RUN_CHECK procedure can take the following four parameters:
check_name：Provides the name of the check you want to invoke. Use the following query to get the list of checks that you can manually run:
SQL> select name from v$hm_check where internal_check='N';

• run_name：A user-generated name for identifying a check’s run. If you pass a NULL value, the Health Monitor creates a unique name for the check run.
• timeout：Provides a time limit for the checker run. If you pass a NULL value for this parameter, there won’t be a time limit for the checker run.
• input_params：Lets you specify name/value pairs de-limited by a special character (;), as shown in the following example in the case of a Data Block Integrity Check.
  BLC_DF_NUM=1;BLC_BL_NUM=23456

You can use input parameters for most health checks. Some of the input parameters are optional and the others are mandatory. The following exercise shows how to pass an input parameter for a transaction integrity check. First, use the following query on the V$HM_CHECK_VIEW to find out the parameter values for different health checks.
SQL> 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;
To pass input parameters to a specific health check, use the name/value pair notation, with the name and value separated by a semicolon (;). Here’s an example:
begin
dbms_hm run_check (
   check_name   => 'Transaction Integrity Check',
   run_name     => 'testrun1',
   input_params => 'TXN_ID=9.44.1');
end;
The example shows how to pass a value for the transaction id parameter, with the check name being Transaction Integrity Check.
The Health Monitor stores its reports in the ADR. You can query the V$HM_RUN, V$HM_FINDING, and V$HM_RECOMMENDATION views to get the findings and recommendations made by the check you ran. Alternatively, you can view the report of the check you just ran, with the help of the GET_RUN_REPORT
function, as shown here:
SQl> set long 100000
SQL> select dbms_hm.get_run_report('TestCheck1') from dual;
     DBMS_HM.GET_RUN_REPORT('TESTCHECK1')
------------------------------------------------------------
Basic Run Information
 Run Name               : TestCheck1
 Run Id                 : 42721
 Check Name             : Dictionary Integrity Check
 Mode                   : MANUAL
 Status                 : COMPLETED
 Start Time             : 2007-10-03 16:40:47.464989 -04:00
 End Time               : 2007-10-03 16:41:23.068746 -04:00
 Error Encountered      : 0
 Source Incident Id      : 0
 Number of Incidents Created  : 0
Input Parameters for the Run
 TABLE_NAME=ALL_CORE_TABLES
 CHECK_MASK=ALL
Run Findings And Recommendations
 Finding
 Finding Name  : Dictionary Inconsistency
 Finding ID    : 42722
 Type          :FAILURE
 Status        : OPEN
 Priority      :  CRITICAL
 Message       : SQL dictionary health check:
 dependency$.dobj# fk 126 on object DEPENDENCY$ failed
 Message       : Damaged rowid is AAAABnAABAAAOiHABI –
description: No further damage description available
The GET_RUN_REPORT procedure relies on the HM_* views listed earlier to provide you the findings and recommendations based on the check. The GET_RUN_REPORT procedure can take three values: run_name, type, and level.Of these, only the run_name parameter is mandatory. The default report type is
text and the other possible values are html and xml. The level parameter determines the details shown in the report and the possible values are basic and detail, although currently only the basic level of detail is supported.You can also use the ADRCI utility to view the reports of Health Monitor checks.After setting the homepath to point to the current database instance, issue the show hm_run command first, as shown here:
adrci> show hm_run
****************************************************************
HM RUN RECORD 2131
****************************************************************
   RUN_ID                        42721
   RUN_NAME                      TestCheck1
   CHECK_NAME                    Dictionary Integrity Check
   NAME_ID                       24
   MODE                          0
   START_TIME                    2007-10-03 16:40:47.4649 -04:00
   RESUME_TIME                   <NULL>
   END_TIME                      2007-10-03 16:41:23.0687 -04:00
   MODIFIED_TIME                 2007-10-03 16:41:59.7867 -04:00
   TIMEOUT                       0
   FLAGS                         0
   STATUS                        5
   SRC_INCIDENT_ID               0
   NUM_INCIDENTS                 0
   ERR_NUMBER                    0
   REPORT_FILE
   /u01/app/oracle/diag/rdbms/orcl2/orcl2/hm/HMREPORT_TestCheck1
2131 rows fetched
In my example, the output of the show hm_run command shows the filename of the report under the report_file column. This means the report for this particular check has already been generated. If the report_file column shows a NULL value, you must first generate the report using the create report hm_run command, as shown here:
adrci> create report hm_run TestCheck1
You can view a report by issuing the show report hm_run command, as shown here:
adrci> show report hm_run TestCheck1
Note that you pass the check name as a parameter to both the create report hm_run and the show report hm_run commands.

 

参考至:《McGraw.Hill.OCP.Oracle.Database.11g.New.Features.for.Administrators.Exam.Guide.Apr.2008》
             http://docs.oracle.com/cd/E11882_01/server.112/e25494/diag.htm#ADMIN11277

本文原创，转载请注明出处、作者

如有错误，欢迎指正 

邮箱:[e-mail]