How to Create SR1

Oracle Database 11 g: 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: oracle tutor


Oracle Database 11g: Diagnosability Table of Contents i

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 ii


Automatic Diagnostic Repository Chapter 0 - Page 1

Automatic Diagnostic Repository



Chapter 1Automatic Diagnostic Repository


Oracle Database 11 g



Objectives

Objectives

After completing this lesson, you should be able to :• Describe the extensions to the self-managing databa se

in Oracle Database 11 g• Set up the Automatic Diagnostic Repository



Self-Managing Database: The Next Generation

Self-Managing Database: The Next Generation

Manage Performance and Resources

Manage Fault

ManageChange

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.



Oracle Database 11g R1: Fault Management

Oracle Database 11 g R1: Fault Management

Change assuranceand

automatic healthchecks

Automatic DiagnosticWorkflow

Intelligentresolution

Proactivepatching

Goal: Reduce Time to Resolution

Prevention Resolution

Diagnostic Solution Delivery

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



Ease Diagnosis: Automatic Diagnostic Workflow

Ease Diagnosis: Automatic Diagnostic Workflow

DBA

CriticalError

AutomaticDiagnosticRepository

Knownbug?

DBA

EM Support Workbench:Apply patch/Data repair

Yes

DBA

No

Alert DBATargeted health checks

Assisted SR filing

Auto incident creationFirst failure capture

EM Support Workbench:Package incident info

Data Repair

1 2

3

4

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.





diag

rdbms

DBName

SID

ADRBase

$ORACLE_HOME/log

DIAGNOSTIC_DEST

ADRHome

$ORACLE_BASE

ADRCIlog.xml alert_SID.log

V$DIAG_INFO

BACKGROUND_DUMP_DEST

USER_DUMP_DESTCORE_DUMP_DEST

alert cdump (others)hmincpkg incident

metadata

incdir_1 incdir_ n…

trace

Support Workbench

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



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.



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 incidentADR 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 fetchedADRCI>

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.



V$DIAG_INFO

V$DIAG_INFO

NAME VALUE------------------- -------------------------------- -------------------------------Diag Enabled TRUEADR Base /u01/app/oracleADR Home /u01/app/oracle/diag/rdbms/or cl/orclDiag Trace /u01/app/oracle/diag/rdbms/or cl/orcl/traceDiag Alert /u01/app/oracle/diag/rdbms/or cl/orcl/alertDiag Incident /u01/app/oracle/diag/rdbms/or cl/orcl/incidentDiag Cdump /u01/app/oracle/diag/rdbms/or cl/orcl/cdumpHealth Monitor /u01/app/oracle/diag/rdbms/or cl/orcl/hmDefault Trace File /u01/app/oracle/diag/rdbms/or cl/orcl/trace/orcl_ora_11424.trcActive Problem Count 3Active Incident Count 8

SQL> SELECT * FROM V$DIAG_INFO;

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.



Location for Diagnostic Traces

Location for Diagnostic Traces

$ADR_HOME/incident/incdir_ nUSER|BACKGROUND_DUMP_DESTIncident dumps

$ADR_HOME/cdumpCORE_DUMP_DESTCore dumps

$ADR_HOME/alert &traceBACKGROUND_DUMP_DESTAlert log data

$ADR_HOME/traceBACKGROUND_DUMP_DESTBackground process traces

$ADR_HOME/traceUSER_DUMP_DESTForeground process traces

ADR LocationPrevious LocationDiagnostic Data

ADR trace Oracle Database 10 g 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.



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.



Viewing the Alert Log Using ADRCI

Viewing the Alert Log Using ADRCI

adrci> set homepath diag/rdbms/orcl/orcladrci> show alert –tail

ADR Home = /u01/app/oracle/diag/rdbms/orcl/orcl:*************************************************** **********************2007-04-16 22:10:50.756000 -07:00ORA-1654: unable to extend index SYS.I_H_OBJ#_COL# by 128 in tablesp ace SYSTEM2007-04-16 22:21:20.920000 -07:00Thread 1 advanced to log sequence 400

Current log# 3 seq# 400 mem# 0: +DATA/orcl/onlinelo g/group_3.266.618805031Current log# 3 seq# 400 mem# 1: +DATA/orcl/onlinelo g/group_3.267.618805047

…Thread 1 advanced to log sequence 401

Current log# 1 seq# 401 mem# 0: +DATA/orcl/onlinelo g/group_1.262.618804977Current log# 1 seq# 401 mem# 1: +DATA/orcl/onlinelo g/group_1.263.618804993

DIA-48223: Interrupt Requested - Fetch Aborted - Retu rn Code [1]

adrci> SHOW ALERT -P "MESSAGE_TEXT LIKE '%ORA-600%' "

ADR Home = /u01/app/oracle/diag/rdbms/orcl/orcl:*************************************************** **********************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.



Summary

Summary

In this lesson, you should have learned how to:• Describe the extensions to the self-managing databa se

in Oracle Database 11 g• Set up the Automatic Diagnostic Repository


Using Support Workbench Chapter 0 - Page 1

Using Support Workbench



Chapter 2Using Support Workbench

Using Support Workbench




Objectives

Objectives

After completing this lesson, you should be able to :• Compare a problem with an incident• Use Support Workbench



Problems and Incidents

Problems and Incidents

Problem

Incident

ProblemKey

Problem ID

Incident ID

CriticalError

Automatically

Manually

Automatictransition

Closed

Data-Purged

Tracking

Ready

Collecting

Incident Status

MMON ADRAuto-purge

Floodcontrol

Traces

Non-criticalError

Package to besent to

Oracle Support

DBA

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



(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.



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, sam e 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.



Incident Packages

Incident Packages

• An incident package is a logicalstructure inside ADR representingone or more problems.

• A package is a zip file containingdump information related to anincident package.

• By default, only the first and the last three incidents of each problem are included in an incident package.

• You can generate completeor incremental zip files.

alert cdump (others)hmincpkg incident

metadata

pkg_1 pkg_ n…

trace

diag

rdbms

DBName

SID

ADRBase

ADRHome

Pkg_database_ORA_600__qksdie_-_feature_QKSFM_CVM__0 21207074555_ COM_1.zip

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.



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.



• 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.



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].



EM Support Workbench Roadmap

EM Support Workbench Roadmap

View criticalerror alerts in

Enterprise Manager.

View problemdetails.

Gather additionaldiagnostic information.

Create aservice request.

Package and uploaddiagnostic data

to Oracle Support.

Track the SR andimplement repairs.

Close incidents.

1

2

3

4

6

7

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.



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.



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.



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.



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.





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.



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.



Package and Upload Diagnostic Data to Oracle Support

Package and Upload Diagnostic Data toOracle 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.



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.





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



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.



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.



• 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.



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:



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.



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.



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.



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.



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.



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.



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



package and upload the necessary trace files by customizing that package. This has already been described previously.



Invoking IPS Using ADRCI

Invoking IPS Using ADRCI

INCIDENT

PROBLEM | PROBLEMKEY

Ø

SECONDS | TIME

NEW INCIDENTS

FILE

INCIDENT

IN FILE

OUT FILE

FILE

INCIDENT

IPS GENERATE PACKAGE

IPS ADD

IPS COPY

IPS REMOVE

IPS FINALIZE PACKAGE

IPS SET CONFIGURATION

IPS CREATE 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.



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.



Summary

Summary

In this lesson, you should have learned how to:• Compare a problem with an incident• Use Support Workbench




Using Health Monitor and SQL Repair Advisor Chapter 0 - Page 1

Using Health Monitor and SQL Repair Advisor



Chapter 3Using Health Monitor and SQL Repair Advisor

Using Health Monitor and SQL Repair Advisor




Objectives

Objectives

After completing this lesson, you should be able to :• Run health checks• Use SQL Repair Advisor



Health Monitor: Overview

Health Monitor: Overview

Criticalerror

DBA

Reactive

ManualHealth Monitor

EM or DBMS_HM

Redo CheckDatabase Cross Check

Logical Block CheckTable Row Check

Undo Segment CheckData Block Check

Table Check

Table-Index Row MismatchDatabase Dictionary Check

Table-Index Cross Check

Transaction Check

DB-online

DB-offline

ADR

V$HM_RUNDBMS_HM

ADRCI

EM

hm(reports)

V$HM_CHECK

V$HM_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.



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.



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.



Running Health Checks Manually: PL/SQL Example

Running Health Checks Manually:PL/SQL Example

SQL> set long 100000SQL> select dbms_hm.get_run_report('DicoCheck') fro m 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 RecommendationsFindingFinding Name : Dictionary InconsistencyFinding ID : 22Type : FAILUREStatus : OPENPriority : CRITICALMessage : SQL dictionary health check: invali d column number 8 on

object TAB$ failedMessage : Damaged rowid is AAAAACAABAAAS7PAAB - description: O bject

SCOTT.TABJFV is referenced

SQL> exec dbms_hm.run_check('Dictionary Integrity C heck','DicoCheck',0,'TABLE_NAME=tab$');

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.



Viewing HM Reports Using the ADRCI Utility

Viewing HM Reports Using the ADRCI Utilityadrci> show hm_run…ADR Home = /u01/app/oracle/diag/rdbms/orcl/orcl:*************************************************** **********************HM RUN RECORD 1*************************************************** *******

RUN_ID 1RUN_NAME HM_RUN_1CHECK_NAME DB Structure Integrit y CheckNAME_ID 2MODE 2START_TIME 2007-07-02 17:31:54.2 71917 +07:00RESUME_TIME <NULL>END_TIME 2007-07-02 17:31:57.5 79834 +07:00MODIFIED_TIME 2007-07-02 17:31:57.5 79834 +07:00TIMEOUT 0FLAGS 0STATUS 5SRC_INCIDENT_ID 0NUM_INCIDENTS 0ERR_NUMBER 0REPORT_FILE <NULL>

…adrci> create report hm_run HM_RUN_1Adrci> 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.



SQL Repair Advisor: Overview

SQL Repair Advisor: Overview

DBA

SQLstatement Execute

Statementcrashes

Generateincident in ADRautomatically

DBA runSQL Repair Advisor

DBA getsalerted

SQ

L R

epai

r A

dvis

orin

vest

igat

es

SQL patchgenerated

DBA acceptSQL patch

Statement executes successfully again

SQL statementpatched

Execute

Trace files

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.



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.





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.



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.





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.



Using SQL Repair Advisor from PL/SQL: Example

Using SQL Repair Advisor from PL/SQL: Example

declarerep_out clob;t_id varchar2(50);

begint_id := dbms_sqldiag.create_diagnosis_task( sql_text => 'delete from t t1 where t1.a = ''a'' an d 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_COMPILATI ON_ERROR);

dbms_sqltune.set_tuning_task_parameter(t_id,'_SQLDI AG_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.



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.



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.



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 r ight solution is often the biggest component of down tim e.

• The advisor analyzes failures based on symptoms.– For example, “Open failed” because data files are m issing

• It intelligently determines repair strategies.– Aggregates failures for efficient repair

— For example, restores an entire file for many bad b locks

– 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.



Summary

Summary

In this lesson, you should have learned how to:• Run health checks• Use SQL Repair Advisor

Documents

How to Create SR1