Oracle Database 11g Diagnosability D52360

Oracle Database 11g:
Diagnosability
Student Guide
D52360GC10
Edition 1.0
September 2007
PRODUCTION
Copyright © 2007, Oracle. All rights reserved.
This documentation contains proprietary information of Oracle Corporation. It is provided under a license agreement containing
restrictions on use and disclosure and is also protected by copyright law. Reverse engineering of the software is prohibited. If this
documentation is delivered to a U.S. Government Agency of the Department of Defense, then it is delivered with Restricted Rights and
the following legend is applicable:
Restricted Rights Legend
Use, duplication or disclosure by the Government is subject to restrictions for commercial computer software and shall be deemed to be
Restricted Rights software under Federal law, as set forth in subparagraph (c)(1)(ii) of DFARS 252.227-7013, Rights in Technical Data
and Computer Software (October 1988).
This material or any portion of it may not be copied in any form or by any means without the express prior written permission of the
Education Products group of Oracle Corporation. Any other copying is a violation of copyright law and may result in civil and/or criminal
penalties.
If this documentation is delivered to a U.S. Government Agency not within the Department of Defense, then it is delivered with
“Restricted Rights,” as defined in FAR 52.227-14, Rights in Data-General, including Alternate III (June 1987).
The information in this document is subject to change without notice. If you find any problems in the documentation, please report them
in writing to Worldwide Education Services, Oracle Corporation, 500 Oracle Parkway, Box SB-6, Redwood Shores, CA 94065. Oracle
Corporation does not warrant that this document is error-free.
Oracle, JD Edwards, PeopleSoft, and Siebel are registered trademarks of Oracle Corporation and/or its affiliates. Other names may be
trademarks of their respective owners.
Author
Jean-Francois Verrier
Technical Contributors and Reviewers
Maria Colgan, Roger Knopf
This book was published using: oracletutor

Table of Contents
Automatic Diagnostic Repository ..................................................................................................................1-2

Chapter 1Automatic Diagnostic Repository..................................................................................................1-2
Objectives......................................................................................................................................................1-3
Self-Managing Database: The Next Generation............................................................................................1-4
Oracle Database 11g R1: Fault Management ................................................................................................1-5
Ease Diagnosis: Automatic Diagnostic Workflow ........................................................................................1-6
Automatic Diagnostic Repository .................................................................................................................1-7
ADRCI: The ADR Command-Line Tool ......................................................................................................1-9
V$DIAG_INFO.............................................................................................................................................1-10
Location for Diagnostic Traces .....................................................................................................................1-11
Viewing the Alert Log Using Enterprise Manager........................................................................................1-12
Viewing the Alert Log Using ADRCI...........................................................................................................1-13
Summary .......................................................................................................................................................1-14
Using Support Workbench .............................................................................................................................2-2
Chapter 2Using Support Workbench.............................................................................................................2-2
Objectives......................................................................................................................................................2-3
Problems and Incidents .................................................................................................................................2-4
Incident Packaging Service (IPS)..................................................................................................................2-6
Incident Packages ..........................................................................................................................................2-7
EM Support Workbench: Overview..............................................................................................................2-8
Oracle Configuration Manager......................................................................................................................2-10
EM Support Workbench Roadmap ...............................................................................................................2-11
View Critical Error Alerts in Enterprise Manager.........................................................................................2-13
View Problem Details ...................................................................................................................................2-14
View Incident Details....................................................................................................................................2-15
Create a Service Request ...............................................................................................................................2-17
Package and Upload Diagnostic Data to Oracle Support ..............................................................................2-18
Track the SR and Implement Repairs............................................................................................................2-19
Close Incidents and Problems .......................................................................................................................2-21
Incident Packaging Configuration.................................................................................................................2-22
Custom Packaging: Create New Package......................................................................................................2-24
Custom Packaging: Manipulate Incident Package ........................................................................................2-26
Custom Packaging: Finalize Incident Package..............................................................................................2-27
Custom Packaging: Generate Package ..........................................................................................................2-28
Custom Packaging: Upload Package.............................................................................................................2-29
Viewing and Modifying Incident Packages...................................................................................................2-30
Creating User-Reported Problems.................................................................................................................2-31
Invoking IPS Using ADRCI..........................................................................................................................2-33
Summary .......................................................................................................................................................2-35
Using Health Monitor and SQL Repair Advisor ..........................................................................................3-2
Chapter 3Using Health Monitor and SQL Repair Advisor............................................................................3-2
Objectives......................................................................................................................................................3-3
Health Monitor: Overview ............................................................................................................................3-4
Running Health Checks Manually: EM Example .........................................................................................3-6
Running Health Checks Manually: PL/SQL Example ..................................................................................3-7
Viewing HM Reports Using the ADRCI Utility ...........................................................................................3-8
SQL Repair Advisor: Overview ....................................................................................................................3-9
Accessing SQL Repair Advisor Using EM ...................................................................................................3-10
Using SQL Repair Advisor from EM............................................................................................................3-12
Using SQL Repair Advisor from PL/SQL: Example ....................................................................................3-14
Viewing, Disabling, or Removing a SQL Patch............................................................................................3-15
Using SQL Test Case Builder .......................................................................................................................3-16
Data Recovery Advisor .................................................................................................................................3-17
Summary .......................................................................................................................................................3-18
Oracle Database 11g: Diagnosability Table of Contents

i
Oracle Database 11g: Diagnosability Table of Contents

ii
Automatic Diagnostic
Repository
Automatic Diagnostic Repository

Chapter 0 - Page 1
Chapter 1Automatic Diagnostic Repository
Oracle Database 11g

Chapter 1 - Page 2
Objectives
Objectives
After completing this lesson, you should be able to:

• Describe the extensions to the self-managing database
in Oracle Database 11g
• Set up the Automatic Diagnostic Repository

Chapter 1 - Page 3
Self-Managing Database: The Next Generation
Self-Managing Database: The Next Generation
Manage Performance and Resources

Manage
Change
Manage Fault
Oracle Database 11g adds two more important axes to the overall self-management goal: change
management and fault management.
In this eStudy, we concentrate on the fault management capabilities introduced in Oracle
Database 11g.

Chapter 1 - Page 4
Oracle Database 11g R1: Fault Management
Oracle Database 11g R1: Fault Management
Goal: Reduce Time to Resolution
Change assurance
and Automatic Proactive
Intelligent
Diagnostic patching
automatic health resolution
Workflow
checks
Diagnostic Solution Delivery
Prevention Resolution
The goals of the fault diagnosability infrastructure are the following:

• Detecting problems proactively
• Limiting damage and interruptions after a problem is detected
• Reducing problem diagnostic time
• Reducing problem resolution time
• Simplifying customer interaction with Oracle Support

Chapter 1 - Page 5
Ease Diagnosis: Automatic Diagnostic Workflow
Ease Diagnosis: Automatic Diagnostic Workflow

Automatic
Critical Diagnostic
Error Repository
DBA
Alert DBA
Auto incident creation
1 2 Targeted health checks
First failure capture Assisted SR filing
No Known
DBA bug?
Yes
EM Support Workbench:
Package incident info EM Support Workbench:
4
Data Repair
Apply patch/Data repair DBA
3
An always-on, in-memory tracing facility enables database components to capture diagnostic data
upon first failure for critical errors. A special repository, called Automatic Diagnostic Repository
(ADR), is automatically maintained to hold diagnostic information about critical error events.
This information can be used to create incident packages to be sent to Oracle Support Services for
investigation.
Here is a possible workflow for a diagnostic session:
1. Incident causes an alert to be raised in Enterprise Manager (EM).
2. The DBA can view the alert via the EM Alert page.
3. The DBA can drill down to the incident and problem details.
4. DBA or Oracle Support Services can decide or ask for that information to be packaged and
sent to Oracle Support Services via MetaLink. The DBA can add files to the data to be
packaged automatically.

Chapter 1 - Page 6

DIAGNOSTIC_DEST
$ORACLE_BASE BACKGROUND_DUMP_DEST
CORE_DUMP_DEST
USER_DUMP_DEST
$ORACLE_HOME/log
ADR
Base
Support Workbench
diag
rdbms
DB
Name
ADR metadata
SID
Home
alert cdump incpkg incident hm trace (others)
incdir_1 … incdir_n
ADRCI
log.xml V$DIAG_INFO
alert_SID.log
ADR is a file-based repository for database diagnostic data, such as traces, incident dumps and
packages, the alert log, Health Monitor reports, core dumps, and more. It has a unified directory
structure across multiple instances and multiple products stored outside of any database. It is,
therefore, available for problem diagnosis when the database is down.
Beginning with Oracle Database 11g R1, the database, Automatic Storage Management (ASM),
Cluster Ready Services (CRS), and other Oracle products or components store all diagnostic data
in ADR. Each instance of each product stores diagnostic data in its own ADR home directory.
For example, in a Real Application Clusters (RAC) environment with shared storage and ASM,
each database instance and each ASM instance have a home directory within ADR. ADR’s
unified directory structure uses consistent diagnostic data formats across products and instances,
and a unified set of tools enable customers and Oracle Support to correlate and analyze diagnostic
data across multiple instances.
Starting with Oracle Database 11g, R1, the traditional …_DUMP_DEST initialization parameters
are ignored. The ADR root directory is known as the ADR base. Its location is set by the
DIAGNOSTIC_DEST initialization parameter. If this parameter is omitted or left null, the
database sets DIAGNOSTIC_DEST upon startup as follows: If the environment variable
ORACLE_BASE is set, DIAGNOSTIC_DEST is set to $ORACLE_BASE. If the environment
variable ORACLE_BASE is not set, DIAGNOSTIC_DEST is set to $ORACLE_HOME/log.
Within the ADR base, there can be multiple ADR homes, where each ADR home is the root
directory for all diagnostic data for a particular instance of a particular Oracle product or
component. The location of an ADR home for a database is shown in the graphic given in the

Chapter 1 - Page 7
preceding slide.
Also, two alert files are now generated. One is textual, like the alert file used with the previous
releases of Oracle database, and is located under the TRACE directory of each ADR home. In
addition, an alert message file conforming to the extensible markup language (XML) standard is
stored in the ALERT subdirectory inside the ADR home. You can view the alert log in text format
(with the XML tags stripped) with EM and with the ADRCI utility.
The graphic in the slide shows the directory structure of an ADR home. The INCIDENT
directory contains multiple subdirectories, where each subdirectory is named for a particular
incident, and where each contains dumps pertaining only to that incident.
The HM directory contains the checker run reports generated by the Health Monitor.
There is also a METADATA directory that contains important files for the repository itself. You
can compare this to a database dictionary. This dictionary can be queried using ADRCI.
You can use the ADR Command Interpreter (ADRCI) utility to perform all tasks permitted by the
Support Workbench, but in a command-line environment. The ADRCI utility also enables you to
view the names of the trace files in ADR, and to view the alert log with XML tags stripped, with
and without content filtering.
In addition, you can use V$DIAG_INFO view to list some important ADR locations.

Chapter 1 - Page 8
ADRCI: The ADR Command-Line Tool
ADRCI: The ADR Command-Line Tool
• Allows interaction with ADR from OS prompt

• Can invoke IPS with command line instead of EM
• DBAs should use EM Support Workbench:
– Leverages same toolkit/libraries that ADRCI is built upon
– Easy to follow GUI
ADRCI> show incident

ADR Home = /u01/app/oracle/product/11.1.0/db_1/log/diag/rdbms/orcl/orcl:
*****************************************************************************
INCIDENT_ID PROBLEM_KEY CREATE_TIME
------------ -------------------------------------- ---------------------------------
1681 ORA-600_dbgris01:1,_addr=0xa9876541 17-JAN-07 09.17.44.843125000…
1682 ORA-600_dbgris01:12,_addr=0xa9876542 18-JAN-07 09.18.59.434775000…
2 incident info records fetched
ADRCI>
ADRCI is a command-line tool that is part of the fault diagnosability infrastructure introduced in
Oracle Database Release 11g. ADRCI enables you to:
• View diagnostic data within ADR
• Package incident and problem information into a zip file for transmission to Oracle Support.
This is done using a service called Incident Package Service (IPS).
ADRCI has a rich command set and can be used in interactive mode or within scripts. Also,
ADRCI can execute scripts of ADRCI commands in the same way that SQL*Plus executes scripts
of SQL and PL/SQL commands.
There is no need to log in to ADRCI, because the data in ADR is not intended to be secure.
ADR data is secured only by operating system permissions on the ADR directories.
The easiest way to package, and otherwise manage, diagnostic data is with the Support
Workbench of Oracle Enterprise Manager. ADRCI provides a command-line alternative to most
of the Support Workbench functionality, and adds capabilities, such as listing and querying trace
files.
The slide example shows you an ADRCI session where you list all open incidents stored in the
ADR.
Note: For more information about ADRCI, refer to the Oracle Database Utilities guide.

Chapter 1 - Page 9
V$DIAG_INFO
V$DIAG_INFO
SQL> SELECT * FROM V$DIAG_INFO;
NAME VALUE
------------------- ---------------------------------------------------------------
Diag Enabled TRUE
ADR Base /u01/app/oracle
ADR Home /u01/app/oracle/diag/rdbms/orcl/orcl
Diag Trace /u01/app/oracle/diag/rdbms/orcl/orcl/trace
Diag Alert /u01/app/oracle/diag/rdbms/orcl/orcl/alert
Diag Incident /u01/app/oracle/diag/rdbms/orcl/orcl/incident
Diag Cdump /u01/app/oracle/diag/rdbms/orcl/orcl/cdump
Health Monitor /u01/app/oracle/diag/rdbms/orcl/orcl/hm
Default Trace File /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_ora_11424.trc
Active Problem Count 3
Active Incident Count 8
The V$DIAG_INFO view lists all important ADR locations:

• ADR Base: Path of ADR base
• ADR Home: Path of ADR home for the current database instance
• Diag Trace: Location of text alert log and the background/foreground process trace files
• Diag Alert: Location of an XML version of the alert log
• …
• Default Trace File: Path to the trace file for your session. SQL Trace files are written here.

Chapter 1 - Page 10
Location for Diagnostic Traces
Location for Diagnostic Traces
Diagnostic Data Previous Location ADR Location

Foreground USER_DUMP_DEST $ADR_HOME/trace
process traces
Background BACKGROUND_DUMP_DEST $ADR_HOME/trace
process traces
Alert log data BACKGROUND_DUMP_DEST $ADR_HOME/alert&trace
Core dumps CORE_DUMP_DEST $ADR_HOME/cdump
Incident dumps USER|BACKGROUND_DUMP_DEST $ADR_HOME/incident/incdir_n
ADR trace = Oracle Database 10g trace – critical error trace
The table shown in the slide describes the different classes of trace data and dumps that reside
both in Oracle Database 10g and in Oracle Database 11g.
With Oracle Database 11g, there is no distinction between foreground and background trace files.
Both types of files go into the $ADR_HOME/trace directory.
All nonincident traces are stored inside the TRACE subdirectory. This is the main difference
compared with previous releases where critical error information is dumped into the
corresponding process trace files instead of incident dumps. Incident dumps are placed in files
separated from the normal process trace files starting with Oracle Database 11g.
Note: The main difference between a trace and a dump is that a trace is more of a continuous
output, such as when SQL tracing is turned on, and a dump is a one-time output in response to an
event, such as an incident. Also, a core is a binary memory dump that is port specific.
In the slide, $ADR_HOME is used to denote the ADR home directory. However, there is no
official environment variable called ADR_HOME.

Chapter 1 - Page 11
Viewing the Alert Log Using Enterprise Manager
Viewing the Alert Log Using Enterprise Manager
You can view the alert log with a text editor with Enterprise Manager, or with the ADRCI utility.
To view the alert log with Enterprise Manager:
1. Access the Database Home page in Enterprise Manager.
2. Under Related Links, click Alert Log Contents.
The View Alert Log Contents page appears.
3. Select the number of entries to view, and then click Go.

Chapter 1 - Page 12
Viewing the Alert Log Using ADRCI
Viewing the Alert Log Using ADRCI
adrci> set homepath diag/rdbms/orcl/orcl

adrci> show alert –tail
ADR Home = /u01/app/oracle/diag/rdbms/orcl/orcl:

*************************************************************************
2007-04-16 22:10:50.756000 -07:00
ORA-1654: unable to extend index SYS.I_H_OBJ#_COL# by 128 in tablespace
SYSTEM
2007-04-16 22:21:20.920000 -07:00
Thread 1 advanced to log sequence 400
Current log# 3 seq# 400 mem# 0: +DATA/orcl/onlinelog/group_3.266.618805031
…
Thread 1 advanced to log sequence 401
DIA-48223: Interrupt Requested - Fetch Aborted - Return Code [1]
adrci> SHOW ALERT -P "MESSAGE_TEXT LIKE '%ORA-600%'"

*************************************************************************
adrci>
You can also use ADRCI to view the content of your alert log file. Optionally, you can change the
current ADR home. You use the SHOW HOMES command to list all ADR homes, and the SET
HOMEPATH command to change the current ADR home.
You should ensure that operating system environment variables, such as ORACLE_HOME are set
properly, and then enter the following command at the OS command prompt: adrci.
The utility starts and displays its prompt as shown above.
You then use the SHOW ALERT command. You can limit output to the last records by using the –
TAIL option. This displays the last portion of the alert log (about 20 to 30 messages), and then
waits for more messages to arrive in the alert log. As each message arrives, it is appended to the
display. In this manner, you can perform live monitoring of the alert log. You press CTRL-C to
stop waiting and return to the ADRCI prompt. You can also specify the amount of lines to be
printed if you want.
You can also filter the output of the SHOW ALERT command as shown in the lowermost example
in the section in the slide, where you want to display only those alert log messages that contain
the string ORA-600.
Note: ADRCI allows you to spool the output to a file as in SQL*Plus.

Chapter 1 - Page 13
Summary
Summary
In this lesson, you should have learned how to:

• Describe the extensions to the self-managing database
in Oracle Database 11g
• Set up the Automatic Diagnostic Repository

Chapter 1 - Page 14
Using Support Workbench

Chapter 0 - Page 1
Chapter 2Using Support Workbench
Oracle Database 11g

Chapter 2 - Page 2
Objectives
Objectives

• Compare a problem with an incident
• Use Support Workbench

Chapter 2 - Page 3
Problems and Incidents
Problems and Incidents

Problem ID
Critical
Error
Problem
Automatically Problem
Key Incident Status
Collecting
Flood Automatic
control Ready
Incident transition
Tracking
Incident ID
Data-Purged
DBA Closed
Manually
Traces
MMON
ADR
Auto-purge
Non-critical
Error
Package to be
sent to
Oracle Support
To facilitate diagnosis and resolution of critical errors, the fault diagnosability infrastructure
introduces two concepts for the Oracle database: problems and incidents.
• A problem is a critical error in the database and problems are tracked in the Automatic
Diagnostic Repository (ADR). Each problem is identified by a unique problem ID and has a
problem key, which is a set of attributes that describe the problem. The problem key includes the
ORA error number, error parameter values, and other information. Here is a possible list of
critical errors:
- All internal Errors – ORA-60x errors
- All system access violations – (SEGV, SIGBUS)
- ORA-4020 (Deadlock on library object), ORA-8103 (Object no longer exists), ORA-
1410 (Invalid ROWID), ORA-1578 (Data block corrupted), ORA-29740 (Node
eviction), ORA-255 (Database is not mounted), ORA-376 (File cannot be read at this
time), ORA-4030 (Out of process memory), ORA-4031 (Unable to allocate more bytes of
shared memory), ORA-355 (The change numbers are out of order), ORA-356

Chapter 2 - Page 4
(Inconsistent lengths in change description), ORA-353 (Log corruption), ORA-7445
(Operating System exception)
• An incident is a single occurrence of a problem. When a problem occurs multiple times, as is
often the case, an incident is created for each occurrence. Incidents are tracked in ADR. Each
incident is identified by a numeric incident ID, which is unique within an ADR home.
When an incident occurs, the database makes an entry in the alert log, gathers diagnostic data
about the incident (a stack trace, the process state dump, and other dumps of important data
structures), tags the diagnostic data with the incident ID, and stores it in an ADR subdirectory
created for that incident. Each incident has a problem key and is mapped to a single problem. Two
incidents are considered to have the same root cause if their problem keys match. Large amounts of
diagnostic information can be created very quickly if a large number of sessions stumble across the
same critical error. Having diagnostic information for more than a small number of incidents is not
required. That is why ADR provides flood control so that only a certain number of incidents under
the same problem can be dumped in a given time interval. Note that flood-controlled incidents still
generate incidents; they only skip the dump actions. By default, only five dumps per hour for a given
problem are allowed.
You can view a problem as a set of incidents that are perceived to have the same symptoms. The
main reason for introducing this concept is to make it easier for users to manage errors on their
systems. For example, a symptom that occurs 20 times should be reported to Oracle only once.
Mostly, you will manage problems instead of incidents, using the Incident Packaging Service (IPS)
to package a problem to be sent to Oracle Support. Often, incidents are automatically created when a
critical error occurs. However, you are also allowed to create an incident manually, via the graphical
user interface (GUI) provided by the Enterprise Manager Support Workbench. Manual incident
creation is mostly done when you want to report problems that are not accompanied by critical errors
raised inside the Oracle code.
Over time, more and more incidents are accumulated in ADR. A retention policy allows you to
specify how long to keep the diagnostic data. ADR incidents are controlled by two policies:
• The incident metadata retention policy controls how long the metadata is kept. This policy has a
default setting of one year.
• The incident files and dumps retention policy controls how long generated dump files are kept.
This policy has a default setting of one month.
You can change these settings by using the Incident Package Configuration link on the EM Support
Workbench page. Inside the RDBMS component, Memory Monitory (MMON) is responsible for
purging automatically expired ADR data.
For simplicity, problem metadata is internally maintained by ADR. Problems are automatically
created when the first incident (of the problem key) occurs. The problem metadata is removed after
its last incident is removed from the repository.
Note: It is not possible to disable automatic incident creation for critical errors.

Chapter 2 - Page 5
Incident Packaging Service (IPS)
Incident Packaging Service (IPS)
• IPS uses rules to correlate all relevant dumps and

traces from ADR for a given problem and allows you to
package them to ship to Oracle Support.
• Rules can involve files that were generated around the
same time, and associated with the same client, same
error codes, and so on.
• DBAs can explicitly add/edit or remove files before
packaging.
• You can access IPS through EM or ADRCI.
With Incident Packaging Service (IPS), you can automatically and easily gather all diagnostic data
(traces, dumps, health check reports, SQL test cases, and more) pertaining to a critical error, and
package the data into a zip file suitable for transmission to Oracle Support.
Because all diagnostic data relating to a critical error are tagged with that error’s incident number,
you do not have to search through trace files, dump files, and so on, to determine the files that are
required for analysis; IPS identifies all the required files automatically and adds them to the package.

Chapter 2 - Page 6
Incident Packages
Incident Packages
Pkg_database_ORA_600__qksdie_-_feature_QKSFM_CVM__021207074555_COM_1.zip
• An incident package is a logical

structure inside ADR representing ADR
one or more problems. Base
• A package is a zip file containing diag
dump information related to an rdbms
incident package. DB
Name
• By default, only the first and
ADR metadata
the last three incidents of Home
SID
each problem are included

alert cdump incpkg incident hm trace (others)
in an incident package.
• You can generate complete pkg_1 … pkg_n
or incremental zip files.
To upload diagnostic data to Oracle Support Services, you first collect the data in an incident
package. When you create an incident package, you select one or more problems to add to it. The
Support Workbench then automatically adds to the incident package the incident information, trace
files, and dump files associated with the selected problem(s). Because a problem can have many
incidents (many occurrences of the same problem), by default only the first three and the last three
incidents for each problem are added to the incident package. You can change this default number on
the Incident Packaging Configuration page accessible from the Support Workbench page.
After the incident package is created, you can add any type of external file to the incident package,
remove selected files from the package, or edit selected files in the package to remove sensitive data.
An incident package is a logical construct only, until you create a physical file from the incident
package contents. That is, an incident package begins as a collection of metadata in ADR. As you
add and remove incident package contents, only the metadata is modified.
When you are ready to upload the data to Oracle Support Services, you invoke a Support Workbench
or an ADRCI function that gathers all the files referenced by the metadata, places them into a zip file,
and then uploads the zip to MetaLink.

Chapter 2 - Page 7
EM Support Workbench: Overview
EM Support Workbench: Overview
• EM Support Workbench is a Wizard that guides you

through the process of handling problems.
• You can perform the following tasks with EM Support
Workbench:
– View details on problems and incidents.
– Run health checks.
– Generate additional diagnostic data.
– Run advisors to help resolve problems.
– Create and track service requests through MetaLink.
– Generate incident packages.
– Close problems when resolved.
The Support Workbench is an Enterprise Manager Wizard that helps you through the process of
handling critical errors. It displays incident notifications, presents incident details, and enables you to
select incidents for further processing. Further processing includes running additional health checks,
invoking the IPS to package all diagnostic data about the incidents, adding SQL test cases and
selected user files to the package, filing a technical assistance request (TAR) with Oracle Support,
shipping the packaged incident information to Oracle Support, and tracking the TAR through its life
cycle.
You can perform the following tasks with the Support Workbench:
• View details on problems and incidents.
• Manually run health checks to gather additional diagnostic data for a problem.
• Generate additional dumps and SQL test cases to add to the diagnostic data for a problem.
• Run advisors to help resolve problems.
• Create and track a service request through MetaLink, and add the service request number to the
problem data.

Chapter 2 - Page 8
• Collect all diagnostic data relating to one or more problems into an incident package and then
upload the incident package to Oracle Support Services.
• Close the problem when the problem is resolved.

Chapter 2 - Page 9
Oracle Configuration Manager
Oracle Configuration Manager
EM Support Workbench uses Oracle Configuration Manager to upload the physical files generated
by IPS to MetaLink. If Oracle Configuration Manager is not installed or properly configured, the
upload may fail. In this case, a message is displayed with a path to the incident package zip file and a
request that you upload the file to Oracle Support manually.
You can upload manually with MetaLink.
During Oracle Database 11g installation, Oracle Universal Installer has a special Oracle
Configuration Manager Registration window as shown in the slide. In that window, you must select
the Enable Oracle Configuration Manager check box and accept the license agreement before you
enter your Customer Identification Number (CSI), your MetaLink account username, and your
country code.
If you do not configure Oracle Configuration Manager, you will still be able to manually upload
incident packages to MetaLink.
Note: For more information about Oracle Configuration Manager, see the “Oracle Configuration
Manager Installation and Administration
Guide”[http://www.oracle.com/technology/documentation/oem.html].

Chapter 2 - Page 10
EM Support Workbench Roadmap
EM Support Workbench Roadmap
View critical
1 error alerts in
Enterprise Manager.
7 Close incidents. View problem

2 details.
Gather additional
6 Track the SR and 3 diagnostic
implement repairs.
information.
Package and upload

4
Create a
diagnostic data service request.
to Oracle Support.
5
The graphic above gives a summary of the tasks that you complete to investigate, report, and in some
cases, resolve a problem using EM Support Workbench:
1. Start by accessing the Database Home page in Enterprise Manager and reviewing critical error
alerts. Select an alert for which to view details.
2. Examine the problem details and view a list of all incidents recorded for the problem. Display
findings from any health checks that were automatically run.
3. Optionally, run additional health checks and invoke the SQL Test Case Builder, which gathers
all required data related to a SQL problem and packages the information in a way that enables
the problem to be reproduced by Oracle Support. The type of information that the SQL Test
Case Builder gathers includes query being executed, table and index definitions (but no data),
optimizer statistics, and initialization parameter settings.
4. Create a service request with MetaLink and optionally record the service request number with
the problem information.
5. Invoke a wizard that automatically packages the gathered diagnostic data for a problem and
uploads the data to Oracle Support. Optionally, edit the data to remove sensitive information
before uploading.

Chapter 2 - Page 11
6. Optionally, maintain an activity log for the service request in the Support Workbench. Run
Oracle advisors to help repair SQL failures or corrupted data.
7. Set status for one, some, or all incidents for the problem to Closed.

Chapter 2 - Page 12
View Critical Error Alerts in Enterprise Manager
View Critical Error Alerts in Enterprise Manager
You begin the process of investigating problems (critical errors) by reviewing critical error alerts on
the Database Home page. To view critical error alerts, access the Database Home page in Enterprise
Manager. On the Home page, you can look at the Diagnostic Summary section where you click the
Active Incidents link if there are incidents. You can also use the Alerts section and look for critical
alerts flagged as Incidents.
When you click the Active Incidents link, you access the Support Workbench page on which you can
retrieve details about all the problems and the corresponding incidents. From there, you can also
retrieve all the packages created and run by Health Monitor checker.
Note: The tasks described in this section are all Enterprise Manager based. You can also accomplish
these tasks with the ADRCI command-line utility. See the Oracle Database Utilities guide for more
information about the ADRCI utility.

Chapter 2 - Page 13
View Problem Details
View Problem Details
On the Problems subpage on the Support Workbench page, click the ID of the problem you want to
investigate. This takes you to the corresponding Problem Details page.
On this page, you see all incidents related to your problem. You can associate your problem with a
MetaLink service request and bug number. In the Investigate and Resolve section of the page, you
have a Self Service subpage that has direct links to the operation you can perform on this problem. In
the same section, the Oracle Support subpage has direct links to MetaLink.
The Activity Log subpage shows the system-generated operations that have been performed on your
problem so far. This subpage allows you to add your comments while investigating your problem.
On the Incidents subpage, you can click a related incident ID to get to the corresponding Incident
Details page.

Chapter 2 - Page 14
View Incident Details
After the Incident Details page opens, the Dump Files subpage appears and lists all the
corresponding dump files. You can then click the eyeglass icon for a particular dump file to visualize
the file content with its various sections.

Chapter 2 - Page 15
On the Incident Details page, click Checker Findings to view the Checker Findings subpage. This
page displays findings from health checks that were automatically run when the critical error was
detected. Often, you have the option to select one or more findings, and invoke an advisor to fix the
issue.

Chapter 2 - Page 16
Create a Service Request
Create a Service Request
Before you can package and upload diagnostic information for the problem to Oracle Support, you
must create a service request. To create a service request, you must go to MetaLink first.
MetaLink can be accessed directly from the Problem Details page by clicking the Go to MetaLink
button in the Investigate and Resolve section of the page. When MetaLink opens, log in and create a
service request as explained earlier.
When finished, you have the option to enter the service request for your problem. However, this is
entirely optional and for your reference only.
In the Summary section, click the Edit button that is adjacent to the SR# label, and in the window
that opens, enter the SR#, and then click OK.

Chapter 2 - Page 17
Package and Upload Diagnostic Data to Oracle Support
Package and Upload Diagnostic Data to

Oracle Support
The Support Workbench provides two methods for creating and uploading an incident package: the
Quick Packaging method and the Custom Packaging method. The example in the slide shows you
how to use Quick Packaging.
Quick Packaging is a more automated method with minimum steps. You select a single problem,
provide an incident package name and description, and then schedule the incident package upload,
either immediately or at a specified date and time. The Support Workbench automatically places
diagnostic data related to the problem into the incident package, finalizes the incident package,
creates the zip file, and then uploads the file. With this method, you do not have the opportunity to
add, edit, or remove incident package files, or add other diagnostic data such as SQL test cases. To
package and upload diagnostic data to Oracle Support:
1. On the Problem Details page, in the Investigate and Resolve section, click Quick Package. The
Create New Package page of the Quick Packaging Wizard appears.
2. Enter a package name and description.
3. Enter the service request number to identify your problem.
4. Click Next, and then proceed with the remaining pages of the Quick Packaging Wizard. Click
Submit on the Review page to upload the package.

Chapter 2 - Page 18
Track the SR and Implement Repairs
After uploading diagnostic information to Oracle Support, you may perform various activities to
track the service request and implement repairs. Among these activities are the following:
Add an Oracle bug number to the problem information. To do so, on the Problem Details page click
the Edit button that is adjacent to the Bug# label. This is for your reference only.
Add comments to the problem activity log. To do so, complete the following steps:
1. Access the Problem Details page for the problem.
2. Click Activity Log to display the Activity Log subpage.
3. In the Comment field, enter a comment, and then click Add Comment. Your comment is
recorded in the activity log.
Respond to a request by Oracle Support to provide additional diagnostics. Your Oracle Support
representative may provide instructions for gathering and uploading additional diagnostics.

Chapter 2 - Page 19
On the Incident Details page, you can run an Oracle advisor to implement repairs. Access the
suggested advisor in one of the following ways:
• In the Self-Service tab of the Investigate and Resolve section of the Problem Details page
• On the Checker Findings subpage of the Incident Details page as shown in the slide
The advisors that help you repair critical errors are:
• Data Recovery Advisor: Corrupted blocks, corrupted or missing files, and other data failures
• SQL Repair Advisor: SQL statement failures

Chapter 2 - Page 20
Close Incidents and Problems
Close Incidents and Problems
When a particular incident is no longer of interest, you can close it. By default, closed incidents are
not displayed on the Problem Details page. All incidents, whether closed or not, are purged after 30
days. You can disable purging for an incident on the Incident Details page.
To close incidents:
1. Access the Support Workbench Home page.
2. Select the desired problem, and then click View. The Problem Details page appears.
3. Select the incidents to close and then click Close. A Confirmation page appears.
4. Click Yes on the Confirmation page to close your incident.

Chapter 2 - Page 21
Incident Packaging Configuration
Incident Packaging Configuration
As already seen, you can configure various aspects of retention rules and packaging generation. You
can access the Incident Packaging Configuration page from the Related Links section of the Support
Workbench page by clicking the Incident Packaging Configuration link. Here are the parameters that
you can change:
• Incident Metadata Retention Period: Metadata is basically information about the data. As for
incidents, it is the incident time, ID, size, problem, and so on. Data is the actual contents of an
incident, such as traces.
• Cutoff Age for Incident Inclusion: This value includes incidents for packaging that are in the
range up to the current time. If the cutoff date is 90, for example, the system includes only those
incidents that are within the last 90 days.
• Leading Incidents Count: For every problem included in a package, the system selects a
certain number of incidents from the problem at the beginning (leading) and at the end (trailing).
For example, if the problem has 30 incidents, and the leading incident count is five and the
trailing incident count is four, the system includes the first five incidents and the last four
incidents.
• Trailing Incidents Count: See explanation above.

Chapter 2 - Page 22
• Correlation Time Proximity: This parameter is the time interval that defines “happened at the
same time.” There is a concept of correlated incidents/problems to a certain incident/problem—
that is, what problems seem to have a connection with a said problem. One criterion for
correlation is time correlation: find incidents that happened at the same time as the incidents in a
problem.
• Time Window for Package Content: The time window for content inclusion is from x hours
before the first included incident to x hours after the last incident (where x is the number
specified in that field).
Note: You have access to more parameters if you are using the ADRCI interface. For a complete
description of all possible configurable parameters, issue the ips show configuration
command in ADRCI.

Chapter 2 - Page 23
Custom Packaging: Create New Package
Custom Packaging: Create New Package
Custom Packaging is a more manual method than Quick Packaging, but gives you greater control
over the incident package contents. You can create a new incident package with one or more
problems, or you can add one or more problems to an existing incident package. You can then
perform a variety of operations on the new or updated incident package, including:
• Adding or removing problems or incidents
• Adding, editing, or removing trace files in the incident package
• Adding or removing external files of any type
• Adding other diagnostic data such as SQL test cases
• Manually finalizing the incident package, and then viewing the incident package contents to
determine whether you must edit or remove sensitive data, or remove files to reduce the incident
package size
With the Custom Packaging method, you create the zip file and request upload to Oracle Support as
two separate steps. Each of these steps can be performed immediately or scheduled for a future date
and time.
To package and upload a problem with Custom Packaging:

Chapter 2 - Page 24
1. On the Problems subpage at the lowermost section of the Support Workbench Home page, select
the first problem that you want to package, and then click Package.
2. On the “Package: Select packaging mode” subpage, select the Custom Packaging option, and
then click Continue.
3. The Custom Packaging: Select Package page appears. To create a new incident package,
select the Create New Package option, enter an incident package name and description, and then
click OK. To add the selected problems to an existing incident package, select the “Select from
Existing Packages” option, select the incident package to update, and then click OK.
In the example given above, you decide to create a new package.

Chapter 2 - Page 25
Custom Packaging: Manipulate Incident Package
Custom Packaging: Manipulate Incident Package
On the Customize Package page, you get the confirmation that your new package has been created.
This page displays the incidents that are contained in the incident package, plus a selection
of packaging tasks to choose from. You run these tasks against the new incident package
or the updated existing incident package.
As you see above, you can exclude/include incidents or files and many other possible
tasks.

Chapter 2 - Page 26
Custom Packaging: Finalize Incident Package
Custom Packaging: Finalize Incident Package
Finish Contents Preparation is used to add correlated files from other components, such as Health
Monitor, to the package. Recent trace files and log files are also included in the package.
You can finalize a package by clicking the Finish Contents Preparation link in the Packaging Tasks
section as shown in the slide. A confirmation page is displayed that lists all the files that will be part
of the physical package.

Chapter 2 - Page 27
Custom Packaging: Generate Package
Custom Packaging: Generate Package
After your incident package has been finalized, you can generate the package file. You must go back
to the corresponding package page and click Generate Upload File.
The Generate Upload File page appears. On this page, select the Full or Incremental option to
generate a full incident package zip file or an incremental incident package zip file.
For a full incident package zip file, all the contents of the incident package (original contents and all
correlated data) are added to the zip file.
For an incremental incident package zip file, only the diagnostic information that is new or modified
since the last time you created a zip file for the same incident package is added to the zip file.
When finished, select the Schedule and click Submit. If you scheduled the generation immediately, a
Processing page appears until packaging is finished. This is followed by the Confirmation page,
where you click OK.
Note: The Incremental option is unavailable if a physical file was never created for the incident
package.

Chapter 2 - Page 28
Custom Packaging: Upload Package
Custom Packaging: Upload Package
After you have generated the physical package, you can go back to the Customize Package page and
click the View/Send Uploaded Files link in the Packaging Tasks section.
This takes you to the View/Send Upload Files page where you can select your package, and click the
“Send to Oracle” button.
The “Send to Oracle” page appears. There, you can enter the service request number for your
problem and choose a Schedule. You can then click Submit.

Chapter 2 - Page 29
Viewing and Modifying Incident Packages
Viewing and Modifying Incident Packages
After a package is created, you can always modify it through customization.

For example, go to the Support Workbench page and click the Packages tab. This takes you to the
Packages subpage. On this page, you can select a package and delete it, or click the package link to
go to the Package Details page. On the Package Details page, you can click Customize to go to the
Customize Package page where you can modify your package by adding/removing problems,
incidents, or files.

Chapter 2 - Page 30
Creating User-Reported Problems
Creating User-Reported Problems
Critical errors generated internally to the database are automatically added to the ADR and tracked in
the Support Workbench. However, there may be a situation in which you want to manually add a
problem you noticed to the ADR so that you can put it through the Support Workbench workflow.
An example of such a situation would be when the performance of the database or a particular query
suddenly and noticeably degraded. The Support Workbench includes a mechanism for you to create
and work with such a user-reported problem.
To create a user-reported problem, open the Support Workbench page and click the Create User-
Reported Problem link in the Related Links section. This takes you to the Create User-Reported
Problem page where you are asked to run a corresponding advisor before continuing. This is
necessary only if you are not sure about your problem. However, if you know what is going on,
select the issue that describes closely the type of problem you are encountering and click “Continue
with Creation of Problem.”
By clicking this button, you basically create a pseudoproblem inside the Support Workbench. This
allows you to manipulate the problem by using the previously seen Support Workbench workflow
for handling critical errors. So, you end up on a Problem Details page for your issue. Note that at first
the problem does not have any diagnostic data associated with it. At this point, you must create a

Chapter 2 - Page 31
package and upload the necessary trace files by customizing that package. This has already been
described previously.

Chapter 2 - Page 32
Invoking IPS Using ADRCI
Invoking IPS Using ADRCI

IPS SET CONFIGURATION
INCIDENT
PROBLEM | PROBLEMKEY
IPS CREATE PACKAGE
SECONDS | TIME
INCIDENT
Ø
NEW INCIDENTS IPS ADD
FILE
IN FILE
IPS COPY
OUT FILE
INCIDENT
IPS REMOVE
FILE
IPS FINALIZE PACKAGE
IPS GENERATE PACKAGE
Creating a package is a two-step process: you first create the logical package, and then generate the
physical package as a zip file. Both steps can be performed using ADRCI commands. To create a
logical package, the IPS CREATE PACKAGE command is used.
There are several variants of this command that allow you to choose the contents:
• IPS CREATE PACKAGE creates an empty package.
• IPS CREATE PACKAGE PROBLEMKEY creates a package based on a problem key.
• IPS CREATE PACKAGE PROBLEM creates a package based on problem ID.
• IPS CREATE PACKAGE INCIDENT creates a package based on incident ID.
• IPS CREATE PACKAGE SECONDS creates a package containing all incidents generated from
seconds ago until now.
• IPS CREATE PACKAGE TIME creates a package based on the specified time range.
It is also possible to add contents to an existing package. For example:

• IPS ADD INCIDENT PACKAGE adds an incident to an existing package.
• IPS ADD FILE PACKAGE adds a file inside ADR to an existing package.

Chapter 2 - Page 33
IPC COPY copies files between ADR and the external file system. It has two forms:
• IN FILE—to copy an external file into ADR and associate it with an existing package, or
optionally, an incident
• OUT FILE—to copy a file from ADR to a location outside ADR
IPS COPY is essentially used to COPY OUT a file, edit it, and COPY IN it back into ADR.
IPS FINALIZE is used to finalize a package for delivery, meaning that other components, such as
Health Monitor, are called to add their correlated files to the package. Recent trace files and log files
are also included in the package. If required, this step is run automatically when a package is
generated.
To generate the physical file, the IPS GENERATE PACKAGE command is used. The syntax is:
IPS GENERATE PACKAGE IN [COMLPETE | INCREMENTAL]
It generates a physical zip file for an existing logical package. The file name contains either COM for
complete or INC for incremental, followed by a sequence number that is incremented each time a zip
file is generated.
IPS SET CONFIGURATION is used to set IPS rules.
Note: Refer to the Oracle Database Utilities guide for more information about ADRCI.

Chapter 2 - Page 34
Summary
Summary

• Compare a problem with an incident
• Use Support Workbench

Chapter 2 - Page 35

Chapter 2 - Page 36
Using Health Monitor and SQL
Repair Advisor
Using Health Monitor and SQL Repair Advisor

Chapter 0 - Page 1
Chapter 3Using Health Monitor and SQL Repair Advisor
Oracle Database 11g

Chapter 3 - Page 2
Objectives
Objectives

• Run health checks
• Use SQL Repair Advisor

Chapter 3 - Page 3
Health Monitor: Overview
Health Monitor: Overview

V$HM_CHECK
Critical DB-offline
error Redo Check ADRCI
V$HM_RUN
Database Cross Check EM
DBMS_HM
hm
(reports)
Reactive
ADR
Manual
Health Monitor
EM or DBMS_HM
V$HM_CHECK DB-online
DBA
Logical Block Check Undo Segment Check
Table Row Check Data Block Check
Transaction Check Table Check
Table-Index Row Mismatch
Database Dictionary Check
Table-Index Cross Check
Beginning with Release 11g, the Oracle Database includes a framework called Health Monitor
for running diagnostic checks on various components of the database.
Health Monitor checkers examine various components of the database, including files, memory,
transaction integrity, metadata, and process usage. These checkers generate reports of their
findings and recommendations for resolving problems. Health Monitor checks can be run in two
ways:
• Reactive: The fault diagnosability infrastructure can run Health Monitor checks
automatically in response to critical errors.
• Manual: As a DBA, you can manually run Health Monitor checks by using either the
DBMS_HM PL/SQL package or the Enterprise Manager interface.
In the slide, you see some of the checks that Health Monitor runs. For a complete description of
all possible checks, look at V$HM_CHECK. These health checks fall into one of two categories:
• DB-online: These checks can be run while the database is open (that is, in OPEN mode or
MOUNT mode).
• DB-offline: In addition to being “runnable” while the database is open, these checks can also
be run when the instance is available and the database itself is closed (that is, in NOMOUNT
mode).
After a checker has run, it generates a report of its execution. This report contains information
about the checker’s findings, including the priorities (low, high, or critical) of the findings,
descriptions of the findings and their consequences, and basic statistics about the execution.

Chapter 3 - Page 4
Health Monitor generates reports in XML and stores the reports in ADR. You can view these
reports by using V$HM_RUN, DBMS_HM, ADRCI, or Enterprise Manager.
Note: Redo Check and Database Cross Check are DB-offline checks. All other checks are DB-
online checks. There are around 25 checks you can run.

Chapter 3 - Page 5
Running Health Checks Manually: EM Example
Running Health Checks Manually: EM Example
Enterprise Manager provides an interface for running Health Monitor checkers. You can find this
interface in the Checkers tab on the Advisor Central page. The page lists each checker type. You
can run a checker by clicking it, and then click OK on the corresponding checker page after you
have entered the parameters for the run. The slide shows how you can run the Data Block
Checker manually.
After a check is completed, you can view the corresponding checker run details by selecting the
checker run from the Results table and clicking Details. Checker runs can be reactive or manual.
On the Findings subpage, you can see various findings and corresponding recommendations
extracted from V$HM_RUN, V$HM_FINDING, and V$HM_RECOMMENDATION.
If you click View XML Report on the Runs subpage, you can view the run report in XML format.
Viewing the XML report in EM generates the report if it is not yet generated in your ADR. You
can then view the report using ADRCI without requiring to generate it.

Chapter 3 - Page 6
Running Health Checks Manually: PL/SQL Example
Running Health Checks Manually:

PL/SQL Example
SQL> exec dbms_hm.run_check('Dictionary Integrity Check',
'DicoCheck',0,'TABLE_NAME=tab$');
SQL> set long 100000

SQL> select dbms_hm.get_run_report('DicoCheck') from dual;
DBMS_HM.GET_RUN_REPORT('DICOCHECK')
--------------------------------------------------------------------------------
Basic Run Information (Run Name,Run Id,Check Name,Mode,Status)
Input Paramters for the Run
TABLE_NAME=tab$
CHECK_MASK=ALL
Run Findings And Recommendations
Finding
Finding Name : Dictionary Inconsistency
Finding ID : 22
Type : FAILURE
Status : OPEN
Priority : CRITICAL
Message : SQL dictionary health check: invalid column number 8 on
object TAB$ failed
Message : Damaged rowid is AAAAACAABAAAS7PAAB - description: Object
SCOTT.TABJFV is referenced
You can use the DBMS_HM.RUN_CHECK procedure for running a health check. To call
RUN_CHECK, supply the name of the check found in V$HM_CHECK, the name for the run (this is
just a label used to retrieve reports later), and the corresponding set of input parameters for
controlling its execution. You can view these parameters by using V$HM_CHECK_PARAM.
In the example in the slide, you want to run a Dictionary Integrity Check for the TAB$ table.
You call this run DICOCHECK, and you do not want to set any timeout for this check.
After DICOCHECK is executed, you execute the DBMS_HM.GET_RUN_REPORT function to get
the report extracted from V$HM_RUN, V$HM_FINDING, and V$HM_RECOMMENDATION. The
output clearly shows that a critical error was found in TAB$. This table contains an entry for a
table with an invalid number of columns.
Furthermore, the report gives you the name of the damaged table in TAB$.
When you call the GET_RUN_REPORT function, it generates the XML report file in the HM
directory of your ADR. For this example, the file is called HMREPORT_DicoCheck.hm.
Note: Refer to the Oracle Database PL/SQL Packages and Types Reference for more information
about DBMS_HM.

Chapter 3 - Page 7
Viewing HM Reports Using the ADRCI Utility
Viewing HM Reports Using the ADRCI Utility

adrci> show hm_run
…
*************************************************************************
HM RUN RECORD 1
**********************************************************
RUN_ID 1
RUN_NAME HM_RUN_1
CHECK_NAME DB Structure Integrity Check
NAME_ID 2
MODE 2
START_TIME 2007-07-02 17:31:54.271917 +07:00
RESUME_TIME <NULL>
END_TIME 2007-07-02 17:31:57.579834 +07:00
MODIFIED_TIME 2007-07-02 17:31:57.579834 +07:00
TIMEOUT 0
FLAGS 0
STATUS 5
SRC_INCIDENT_ID 0
NUM_INCIDENTS 0
ERR_NUMBER 0
REPORT_FILE <NULL>
…
adrci> create report hm_run HM_RUN_1
Adrci> show report hm_run HM_RUN_1
…
You can create and view Health Monitor checker reports using the ADRCI utility. To do that,
ensure that operating system environment variables, such as ORACLE_HOME are set properly, and
then enter the following command at the operating system command prompt: adrci.
The utility starts and displays its prompt as shown in the slide. Optionally, you can change the
current ADR home. Use the SHOW HOMES command to list all ADR homes, and the SET
HOMEPATH command to change the current ADR home.
You can then enter the SHOW HM_RUN command to list all checker runs registered in ADR and
visible from V$HM_RUN. Locate the checker run for which you want to create a report and note
the checker run name by using the corresponding RUN_NAME field. The REPORT_FILE field
contains a file name if a report exists for this checker run. Otherwise, you can generate the report
using the CREATE REPORT HM_RUN command as shown in the slide. To view the report, use the
SHOW REPORT HM_RUN command.

Chapter 3 - Page 8
SQL Repair Advisor: Overview
SQL Repair Advisor: Overview

Generate
SQL Statement incident in ADR
statement Execute crashes automatically
Trace files
SQL Repair Advisor
DBA run DBA gets

SQL Repair Advisor alerted
investigates
DBA
DBA accept
SQL patch
Execute
SQL patch SQL statement Statement executes

generated patched successfully again
You run the SQL Repair Advisor after a SQL statement fails with a critical error that generates a
problem in ADR. The advisor analyzes the statement and in many cases recommends a patch to
repair the statement. If you implement the recommendation, the applied SQL patch circumvents
the failure by causing the query optimizer to choose an alternate execution plan for future
executions. This is done without changing the SQL statement itself.
Note: In case no workaround is found by the SQL Repair Advisor, you are still able to package
the incident files and send the corresponding diagnostic data to Oracle Support.

Chapter 3 - Page 9
Accessing SQL Repair Advisor Using EM
There are basically two ways to access SQL Repair Advisor from Enterprise Manager.
The first and the easiest way is when you get alerted in the Diagnostic Summary section of the
database home page. Following a SQL statement crash that generates an incident in ADR, you are
automatically alerted through the Active Incidents field. You click the corresponding link to get
to the Support Workbench Problems page where you can click the corresponding problem ID
link. This takes you to the Problem Details page where you can click the SQL Repair Advisor
link in the “Investigate and Resolve” section of the page.

Chapter 3 - Page 10
If the SQL statement crash incident is no longer active, you can go to the Advisor Central page,
where you can click the SQL Advisors link and choose the “Click here to go to Support
Workbench” link in the SQL Advisor section of the SQL Advisors page. This takes you to the
Problem Details page, where you can click the SQL Repair Advisor link in the “Investigate and
Resolve” section of the page.
Note: To access the SQL Repair Advisor in case of nonincident SQL failures, you can go to the
SQL Details page or to the SQL Worksheet.

Chapter 3 - Page 11
Using SQL Repair Advisor from EM
On the SQL Repair Advisor: SQL Incident Analysis page, specify a Task Name, a Task
Description, and a Schedule. When finished, click Submit to schedule a SQL diagnostic analysis
task. If you specify Immediately, you end up on the Processing: SQL Repair Advisor Task page
that displays the various steps of the task execution.

Chapter 3 - Page 12
After the SQL Repair Advisor task executes, you are sent to the SQL Repair Results page for that
task. On this page, you see a corresponding Recommendations section, especially if a SQL Patch
was generated to fix your problem. As shown in the slide, you select the statement for which you
want to apply the generated SQL Patch and click View. This takes you to the “Repair
Recommendations for SQL ID” page where you ask the system to implement the SQL Patch by
clicking Implement after selecting the corresponding Findings. You then get a confirmation for
the implementation and you can execute your SQL statement again.

Chapter 3 - Page 13
Using SQL Repair Advisor from PL/SQL: Example
Using SQL Repair Advisor from PL/SQL: Example
declare
rep_out clob;
t_id varchar2(50);
begin
t_id := dbms_sqldiag.create_diagnosis_task(
sql_text => 'delete from t t1 where t1.a = ''a'' and rowid <> (select max(rowid)
from t t2 where t1.a= t2.a and t1.b = t2.b and t1.d=t2.d)',
task_name => 'sqldiag_bug_5869490',
problem_type => DBMS_SQLDIAG.PROBLEM_TYPE_COMPILATION_ERROR);
dbms_sqltune.set_tuning_task_parameter(t_id,'_SQLDIAG_FINDING_MODE',
dbms_sqldiag.SQLDIAG_FINDINGS_FILTER_PLANS);
dbms_sqldiag.execute_diagnosis_task (t_id);
rep_out := dbms_sqldiag.report_diagnosis_task (t_id, DBMS_SQLDIAG.TYPE_TEXT);
dbms_output.put_line ('Report : ' || rep_out);
end;
/
execute dbms_sqldiag.accept_sql_patch(task_name => 'sqldiag_bug_5869490',

task_owner => 'SCOTT', replace => TRUE);
It is also possible that you invoke SQL Repair Advisor directly from PL/SQL.
After you get alerted about an incident SQL failure, you can execute a SQL Repair Advisor task
by using the DBMS_SQLDIAG.CREATE_DIGNOSIS_TASK function as illustrated in the slide.
You must specify the SQL statement for which you want the analysis to be done, and a task name
and a problem type that you want to analyze (possible values are
PROBLEM_TYPE_COMPILATION_ERROR and PROBLEM_TYPE_EXECUTION_ERROR).
You can then give the created task parameters by using the
DBMS_SQLTUNE.SET_TUNING_TASK_PARAMETER procedure.
When you are ready, you can execute the task by using the
DBMS_SQLDIAG.EXECUTE_DIAGNOSIS_TASK procedure.
Finally, you can get the task report by using the
DBMS_SQLDIAG.REPORT_DIAGNOSIS_TASK function.
In the example above, it is assumed that the report asks you to implement a SQL Patch to fix the
problem. You can then use the DBMS_SQLDIAG.ACCEPT_SQL_PATCH procedure to
implement the SQL Patch.

Chapter 3 - Page 14
Viewing, Disabling, or Removing a SQL Patch
Viewing, Disabling, or Removing a SQL Patch
After you apply a SQL patch with SQL Repair Advisor, you may want to view it to confirm its
presence, disable it, or remove it. One reason to remove a patch is when you install a later release
of the Oracle Database that fixes the problem that caused the failure in the nonpatched SQL
statement.
To view, disable/enable, or remove a SQL Patch, access the Server page in EM and click the SQL
Plan Control link in the Query Optimizer section of the page. This takes you to the SQL Plan
Control page. On this page, click the SQL Patch tab.
From the resulting SQL Patch subpage, locate the desired patch by examining the associated SQL
statement. Select it, and perform the corresponding task: Disable, Enable, or Delete.

Chapter 3 - Page 15
Using SQL Test Case Builder
Using SQL Test Case Builder
SQL Test Case Builder automates the somewhat difficult and time-consuming process of
gathering as much information as possible about a SQL-related problem and the environment in
which it occurred, so that the problem can be reproduced and tested by Oracle Support Services.
The information gathered by SQL Test Case Builder includes query being executed, table and
index definitions (but not the actual data), PL/SQL functions, procedures and packages, optimizer
statistics, and initialization parameter settings.
On the Support Workbench page, to access SQL Test Case Builder:
1. Click the corresponding Problem ID to open the problem details page.
2. Click the Oracle Support tab.
3. Click “Generate Additional Dumps and Test Cases.”
4. On the “Additional Dumps and Test Cases” page, click the icon in the Go To Task column to
run SQL Test Case Builder against your particular Incident ID.
The output of SQL Test Case Builder is a SQL script that contains the commands required to re-
create all the necessary objects and the environment.
Note: You can also invoke SQL Test Case Builder by using the DBMS_SQLDIAG.
EXPORT_SQL_TESTCASE_DIR_BY_INC function. This function takes the incident ID and a
directory object. It generates its output for the corresponding incident in the specified directory.

Chapter 3 - Page 16
Data Recovery Advisor
Data Recovery Advisor
• The Oracle Database provides outstanding tools for repairing

problems.
– Lost files, corrupt blocks, and so on
• Analyzing the underlying problem and choosing the right
solution is often the biggest component of down time.
• The advisor analyzes failures based on symptoms.
– For example, “Open failed” because data files are missing
• It intelligently determines repair strategies.
– Aggregates failures for efficient repair
— For example, restores an entire file for many bad blocks
– Presents only feasible repair options
— Are there backups?
— Is there a standby database?
– Ranked by repair time and data loss
• The advisor can automatically perform repairs.
Data Recovery Advisor: EM integrates with database health checks and Recovery Manager
(RMAN) to display data corruption problems, assess the extent of the problem (critical, high, or
low priority), describe the impact of the problem, recommend repair options, conduct a feasibility
check of the customer-chosen option, and automate the repair process.
Note: For more information about Data Recovery Advisor, refer to the corresponding lesson in
this course.

Chapter 3 - Page 17
Summary
Summary

• Run health checks
• Use SQL Repair Advisor

Chapter 3 - Page 18

Oracle Database 11g Diagnosability D52360

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Oracle Database 11g Diagnosability D52360

Diunggah oleh

Hak Cipta:

Format Tersedia

Oracle Database 11g:

Restricted Rights Legend

Technical Contributors and Reviewers

Maria Colgan, Roger Knopf

This book was published using: oracletutor

Automatic Diagnostic Repository ..................................................................................................................1-2

Copyright © 2007, Oracle. All rights reserved.

Oracle Database 11g: Diagnosability Table of Contents

Oracle Database 11g: Diagnosability Table of Contents

Copyright © 2007, Oracle. All rights reserved.

Automatic Diagnostic Repository

Automatic Diagnostic Repository