Oracle 11g Automatic Diagnostic Repository(原创)

Automatic Diagnostic Repository
The automatic diagnostic repository tracks all problems and incidents that occur in the database. The ADR is a file-based repository that you create for storing traditional diagnostic data such as the alert log and trace file, as well as new types of diagnostic data such as the Health Monitor reports. Not only the database, but
the ASM, CRS, and other Oracle products and components store all their diagnostic data in the ADR. It’s important to understand that each instance of an Oracle product has its own separate ADR home directory within the ADR. Thus, each database instance stores its diagnostic data in a separate directory in the ADR. For example, in an environment with RAC and ASM storage, each of the database
instances and the ASM instances have their own home directory under the ADR.The interesting thing is that the ADR uses a consistent diagnostic data format across all Oracle products and all instances, thus making it easier for users and Oracle Support to correlate diagnostic data from multiple instances.
Note that the ADR replaces the traditional diagnostic directories such as the bdump and cdump directories we have been using for years. The traditional *_dump_dest initialization parameters such as bdump still exist, but the database will ignore them in the new release. You use the new initialization parameter diagnostic_dest to set the location of the ADR base directory, which is the root of the ADR structure.
The Structure of the ADR
Use the new initialization parameter diagnostic_dest to set the location of the ADR base. The diagnostic_dest parameter is optional, not mandatory, but
does let you pick your own choice for the location of the ADR. If you don’t specify a value for the diagnostic_dest parameter, the database itself will set a value
for the parameter upon database startup. Here’s how Oracle determines the default location of the ADR base:

• If you set the ORACLE_BASE environment variable, the database sets the diagnostic_dest parameter value to that of the $ORACLE_BASE environment variable.
• If you haven’t set the ORACLE_BASE environment variable, the database sets the diagnostic_dest parameter value to $ORACLE_HOME/log.

It’s important to distinguish between the ADR base, which is the common root directory for the ADR and an ADR home. The former is the location you set with the help of the diagnostic_dest parameter. An ADR home represents the path of the ADR home for the current database instance. An ADR base can contain multiple ADR homes, each of them serving as the root directory for a specific instance of a particular Oracle component or product. Each ADR home has the following path,starting from the ADR base:
diag/product_type/product_id/instance_id
For example, for a database with the identical SID and database name of orcl2 and the ADR base being /u05/app/oracle, the ADR home would be the following:

                           /u05/app/oracle/diag/rdbms/orcl2/orcl2
Diagnostic data includes alert log contents, trace files, incident- and problem-related data, and Health Monitor reports.The XML-formatted alert log is located in the ALERT directory of each ADR home. The text-formatted alert log is located in the TRACE directory.
ADR Home Subdirectories
Each database instance stores its diagnostic data in various subdirectories, the most important of which are the following:

1. alert: Oracle stores an alert log in the XML format in this directory.
2. hm：Contains the checker run reports, which are generated by the new Health Monitor facility.
3. incident：Contains incident reports for the instance.
4. trace：Contains the text-based alert log, similar to the traditional alert log file.

In an Oracle RAC environment, you can create an ADR base on each of the nodes or set a central ADR base on shared storage. Setting up a central ADR base on shared storage enables you to view aggregated diagnostics from all instances in the RAC in addition to letting you use the powerful Data Recovery Advisor to diagnose and repair data failures. You can’t use the Data Recovery Advisor if you don’t use shared storage.
Viewing the ADR Locations

The following is a list of the important ADR locations:
SQL> select  *  from v$diag_info
  INST_ID NAME                      VALUE
--------- ------------------------- ----------------------------------------
        1 Diag Enabled              TRUE
        1 ADR Base                  /u01/app
        1 ADR Home                  /u01/app/diag/rdbms/orcl/orcl
        1 Diag Trace                /u01/app/diag/rdbms/orcl/orcl/trace
        1 Diag Alert                /u01/app/diag/rdbms/orcl/orcl/alert
        1 Diag Incident             /u01/app/diag/rdbms/orcl/orcl/incident
        1 Diag Cdump                /u01/app/diag/rdbms/orcl/orcl/cdump
        1 Health Monitor            /u01/app/diag/rdbms/orcl/orcl/hm
        1 Default Trace File        /u01/app/diag/rdbms/orcl/orcl/trace/orcl_ora_11347.trc
        1 Active Problem Count      0
        1 Active Incident Count     0
11 rows selected.

Note:Default trace file  Path to the session trace files (SQL trace files).
Note that there really is no environment variable named $ADR_HOME to enable the setting of the ADR home. You set the ADR home by using the set homepath command after starting the ADRCI tool.

ADRCI
The ADR Command Interpreter (ADRCI) is a brand-new command-line tool that is a key component of the new fault diagnosability infrastructure. The ADRCI tool enables you to interact with the ADR from the command line. You can do the following with the help of the ADRCI:

• View ADR diagnostic data
• Package together incident and problem data for transmission to Oracle Support using the Incident Packaging Service (IPS)
• View Health Monitor reports

All ADRCI commands work with data in the current ADR home and you can have multiple ADR homes current at any given time. Some ADR commands work with multiple ADR homes but other commands require a single ADR home to be current in order for those commands to work. The key here is the ADR homepath, which points to the directory under the ADR base. By default, the value of the homepath is null when you start ADRCI, meaning that all ADR homes under the ADR base are current. If you want to make a single ADR home the current ADR home, you must set the homepath.
Starting ADRCI
You don’t need to log into ADRCI because the ADRCI data isn’t considered secure
data and is, therefore, merely secured by operating system permissions on the
ADR directories.
$ adrci
ADRCI: Release 11.1.0.6.0 - Beta on Thu Sep 27 16:59:27 2007
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
ADR base = "/u01/app/oracle"
To view a list of all ADRCI commands, enter help at the ADRCI prompt:
adrci> help
 HELP [topic]
   Available Topics:
        CREATE REPORT
        ECHO
.................................................................................................
        SPOOL
There are other commands intended to be used directly by Oracle, type "HELP EXTENDED" to see the list
adrci> help ips create package
  Usage:  IPS CREATE PACKAGE
             [INCIDENT <incid> | PROBLEM <prob_id> |
              PROBLEMKEY <prob_key> |
              SECONDS <seconds> |
              TIME <start_time> TO <end_time>]
             [CORRELATE BASIC | TYPICAL | ALL]
  Purpose: Create a package, and optionally select contents for the package.
........................................................................

Setting the ADR Homepath
As mentioned earlier, by default, the ADR homepath is set to null when you firststart up ADRCI. This means that all ADR homes for all the instances or components you have under the ADR base are current. Here’s an example that shows this:
adrci> show homes
ADR Homes:
diag/rdbms/orcl/orcl
diag/rdbms/orcl2/orcl2
diag/rdbms/eleven/eleven
diag/rdbms/nina/nina
The ADR homepath points to multiple ADR homes. Note that the ADR homepath is shown relative to the ADR base. This means that if the ADR base is /u01/app/oracle, the absolute homepath of the database and instance which are both named orcl2, for example, would be the following:
/u01/app/oracle/diag/rdbms/orcl2/orcl2
If I want only the single ADR home for the orcl2 instance to be current, I must set the ADR homepath in the following way, by using the set homepath command.
adrci> set homepath diag/rdbms/orcl2/orcl2
Confirm the setting of the single ADR home with the following command:
adrci> show homes
ADR Homes:
diag/rdbms/orcl2/orcl2
By setting the homepath to diag/rdbms/orcl2/orcl2, only the ADR home for the instance with the SID orcl2 would be current. This means that when you execute the various commands from ADRCI now, the ADRCI will access diagnostic data from this ADR home, which pertains to just the orl2 instance.
Using ADRCI in Batch Mode
Thus far, you’ve seen how to use the ADRCI tool by invoking it from the operating system command line. However, you can also use the ADRCI tool from the batch mode, just as you do the SQL*Loader tool, for example, thus allowing you to incorporate ADRCI commands in shell scripts and Windows batch files.
Two command line parameters—exec and script—help you perform batch operations with ADRCI commands.
For example, to run the show homes command from the command line (in batch mode), you enter the following command:
$ adrci exec="show homes"
ADR Homes:
diag/rdbms/orcl/orcl
$ adrci exec="show homes;show home"
ADR Homes:
diag/rdbms/orcl/orcl
ADR Homes:
diag/rdbms/orcl/orcl
The other command-line parameter, script, helps you run ADRCI scripts.A script file can consist of any number of ADRCI commands, each separated by a semicolon or a line break. For example, the ADRCI script adrci.txt consists of the following commands:
set homepath diag/rdbms/orcl2/orcl2
show alert
In order to run the script file adrci.txt, enter the following command at the operating system command prompt:
adrci script=adrci.txt
The script shown here will run the show homes and show incident commands.
Incidents and Problems
Oracle introduces two new diagnostic concepts in Oracle Database 11g: problems and incidents. These concepts are crucial to the understanding of the new fault diagnosability infrastructure:

• Any critical error in the database is called a problem—for example, a critical error such as the one manifested by the Oracle error ORA-4031 . A problem is identified by a problem key , which is a text string that describes the problem and includes Oracle error codes.
• A single occurrence of a problem is called an incident. Multiple occurrences of the same problem lead to multiple incidents. An incident is identified by a unique incident ID.

The ADR tracks both problems and incidents in the database. When the database encounters a critical error, it displays an incident alert in the Database Home page of the Enterprise Manager. You then use either the Enterprise Manager or the command-line utility ADRCI to view the incidents and the associated problem.
Following an incident, the database adds information about the incident to the alert log and collects diagnostic data about the incident and attaches an incident ID to this data before storing it in a subdirectory it creates for this incident in the ADR.
Each incident is tagged with a problem key that relates the incident to a problem.ADR automatically creates a problem when the first incident of that problem key occurs. It removes the problem metadata after the last incident with that problem key is removed from the ADR.
ADR uses what it refers to as a flood-controlled incident system, whereby it allows only a certain number of incidents under a problem to log diagnostic data.By default, ADR allows 5 diagnostic data dumps per hour for a single problem. If an incident occurs 20 times but all the incidents are connected to the same problem,
you have to report to Oracle Support only one incident.
The set of diagnostic data pertaining to an incident or incidents relating to a problem (or problems) is called an incident package. When you ask for help from Oracle Support, it’s this incident package that they will expect.
By default, the database automatically creates incidents upon the occurrence of a critical error. You can also create incidents yourself through the new Enterprise Manager Support Workbench when you want to report problems to Oracle Support that haven’t been raising any critical errors in the database.
ADR follows a retention policy so it can limit the amount of diagnostic data it must store. The retention policy actually includes two different settings, one for metadata retention and the other for incident files and dumps retention, as explained here:

• The incident metadata retention policy, which has a default setting of one year, determines how long ADR retains the incident metadata.
• The incident files and dumps retention policy, with a default setting of one month, determines how long ADR retains the dump files generated for critical errors.

The MMON background process is in charge of automatically purging expired ADR data.Besides,You can’t disable automatic incident creation for critical errors.

An incident can be in any one of the following states at a given point in time:

1. Collecting：A newly created incident is currently collecting diagnostic data.
2. Ready： The incident’s data collection phase is complete, and you can package the incident to send to Oracle Support.
3. Tracking：The incident must be kept in the ADR indefinitely because the DBA is currently working on it. You must manually set the incident status to this value.
4. Closed：The incident is resolved and the ADR will purge it once the incident passes its retention period.
5. Data-Purged：The incident metadata is still valid but the associated files have been detached from the incident.

If an incident remains in the collecting or ready state for a period that’s twice as long as its retention period, it automatically is moved to a closed state.To check an incident’s current status, use either the Support Workbench or issue the following ADRCI command:
adrci> show incident –mode detail
You can issue just the plain show incident command to get basic details about all incidents currently considered open.
Incident Packaging Service
In previous releases of the Oracle database, you had to manually gather diagnostic data from multiple sources to submit to Oracle Support when you notified them of a problem. Oracle Database 11g provides a new feature called the incident packaging service (IPS), which lets you automatically gather all diagnostic data pertaining to a critical error such as the trace files and dump files that you’re familiar with, as well
as the new health check reports, SQL test cases, and related information, and package the data into a Zip file for sending to Oracle Support. The IPS uses a critical error’s incident number to automatically identify and gather all relevant diagnostic files and adds them to the incident package. The IPS uses rules to package all dumps and traces for a given problem and lets you package them easily for sending to Oracle Support.You can use rules to gather files generated around a time period, or related to a particular client or a specific error code, for example.
You are allowed the latitude to add, delete, or remove diagnostic files before finalizing an incident package and sending it to Oracle Support. Here are some things you need to know about incident packages:

• An incident package is a logical construct that represents one or more problems. By default, the first and the last three incidents for a problem are included in an incident package. It contains just the metadata for a problem,
• The package you need to send in the form of a Zip file to Oracle Support is a physical package (Zip file) that contains all the files referenced by the metadata in the logical incident package.
• You must finalize a package before the ADRCI can generate a physical package from the initial logical package. During the “finalizing” stage, you can add other diagnostic information in the form of alert log entries, trace files, SQL test cases, and configuration information. You can finalize a package manually
• through the ADRCI utility and can remove any files you want after reviewing the finalized package.
• You can generate complete and incremental Zip files.

• Oracle employs an incident flood control mechanism, as explained earlier,to limit the amount of diagnostic data that a problem generates in the ADR.Flood control in this context means that ADRCI lets only a certain number of incidents under a given problem be dumped during a given time interval.Once a certain threshold is reached, a flood controlled incident merely generates an alert log entry but not any incident dumps. You can’t change the preset threshold levels for incident flood control. Here’s how the thresholds are determined:

1. After 5 incidents relating to a certain problem in one hour, further incidents are flood controlled for that hour.
2. After 25 incidents occur for any problem during one day, further incidents for that problem key are flood controlled for that day.

Packaging Incidents with ADRCI

You manage the IPS through either the new Support Workbench, which you can access from the Enterprise Manager, or through the ADRCI tool. You can create packages and upload them to Oracle Support through either means, although the Support Workbench is more intuitive. The ADRCI tool, however, makes up by providing more capabilities to manage incidents and problems in the database.
Creating a Logical Package   

Before you can create a physical incident package and transmit it to Oracle Support, you must create a logical package, which the ADR stores as metadata.You can create a logical package as an empty package and add diagnostic information later on. Or, you can create a logical package based on an incident number, problem number, problem key, or a time interval. When you create a non-empty logical package, diagnostic information is automatically added to the logical package.
To create an empty package, use this command:
adrci> ips create package
Created package 4 without any contents,
correlation level typical
The package just created (Package 4) is an empty logical package. To create a nonempty logical package with diagnostic information about an incident, use the following command.
adrci> ips create package incident 17060
Created package 5 based on incident id 17060,
correlation level typical
You can also create a logical package covering all incidents between two time periods, as shown here:
adrci> ips create package time '2007-09-20 00:00:00 -12:00' to
       '2007-09-30 00:00:00 -12:00'
The previous command will create a logical package that includes diagnosticinformation for all incidents that occurred between September 20 and September 30 of 2007. If you want, you can also use the following variations of the create package command:

ips create package problem：Create a package based on a problem ID.
ips create package problemkey：Create a package based on a problem key.
ips create problem seconds：Create a package that includes all incidents generated from the specified number of seconds in the past until the present time.

Adding Logical Information to a Logical Package   

If you create a logical
package by using the ips create package command without specifying an incident ID, problem ID, or time range, the package will be empty and you must then add diagnostic information to the existing logical package. Here’s how you add diagnostic information for an incident to an empty logical package:
adrci> ips add incident 17060 package 4
Added incident 17060 to package 4
You can add files to an existing package by using the following command:
adrci> ips add file <file_name> package <package_number>
Note that you can add only those files that are located in the ADR directory hierarchy (under the ADR base).
Generating a Physical Incident Package

Once you load the logical package with diagnostic data, it’s time to create the physical package so you can send it to Oracle Support. Here’s how you create a physical incident package:
adrci> ips generate package 4 in /u01/app/oracle/diag
Generated package 4 in file
/u01/app/oracle/diag/IPSPKG_20070929163401_COM_1.zip,mode complete
The previous command generates a physical package in the directory /u01/app/oracle/support from the logical package 4 that you created earlier. Note that the physical file has the COM_1 suffix in its filename, indicating it’s a complete incident file. You can create an incremental physical incident package by specifying the keyword incremental, as shown here:
adrci> ips generate package 4 in /u01/app/oracle/diag incremental
Generated package 4 in file
/u01/app/oracle/diag/IPSPKG_20070929163401_INC_2.zip, mode incremental
Once you’ve incorporated all the diagnostic data and are ready to transmit the physical package to Oracle Support, you can finalize the incident package using the following command:
adrci> ips finalize package 4
Finalized package 4
You’re now ready to upload the physical package you’ve just created to Oracle Support. Note that you still have to send the file the old-fashioned way, by uploading it manually. If you use the Support Workbench to package incidents, you can automate the transmission of the package.

 

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

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

如有错误，欢迎指正

邮箱:[e-mail]