Oracle Database 10g: Performance Tuning 1-2

Oracle Database 10g: Performance Tuning 1-3

Who Tunes?
Everyone involved with the Oracle database software—including system architects, designers,
developers, database administrators, and system administrators—should think about
performance.
If problems develop, the database administrator (DBA) usually makes the first attempt at
resolving them. Therefore, the DBA should have an accurate overview of all the applications in
the database and their interactions with each other. DBAs often enlist the aid of either developers
for application tuning or system administrators for tuning OS and I/O issues. This course is
intended for the DBA who is responsible for ongoing tuning and monitoring of an Oracle
database. However, anyone involved in the design, development, and deployment of an Oracle
database can also benefit.

Oracle Database 10g: Performance Tuning 1-4

What Is Tuned?
To have a well-tuned system, you must carefully design systems and applications. Common
performance problems can be grouped as follows:
• Application issues: Poorly written SQL, serialized resources, and poor session management
• Instance issues: Memory, I/O, and instance configuration
• Operating system issues: Swap, I/O, parameter settings, and network issues
You achieve the largest return on investment of time and effort by tuning the application. Tuning
the SQL statements, the access paths, and the storage structures are all important parts of
application tuning.
Instance tuning and application tuning use different sets of skills and tools. Application tuning is
dependent on the type of application. Data warehouse applications and online transaction
processing applications use different access methods and data structures for performance.
Operating system tuning is dependent on the operating system being used.
Separate Oracle University courses address the specific skills and tools used in application
tuning: Oracle Database 10g: SQL Tuning Workshop for OLTP tuning and statement tuning, and
Oracle Database 10g: Implement and Administer a Data Warehouse for data warehouse issues.

Oracle Database 10g: Performance Tuning 1-5

What Is Tuned? (continued)
Some database issues require assistance from the system administrator. This course addresses
some of the generic issues. Separate courses are available for Linux- and Windows-based
systems that deal with OS-specific issues. The Linux course covers many issues that are generic
to UNIX and UNIX-like operating systems.

Oracle Database 10g: Performance Tuning 1-6

What to Tune in the Instance
This course focuses on instance tuning: memory, I/O, and instance configuration. This is the
typical realm of the DBA. The workshop examples use well-tuned SQL statements so that you
can focus on instance issues. Outside of the practice environment, problems will not be so clearly
defined. Application issues can appear to be instance issues. Application tuning and instance
tuning overlap. Sometimes an instance can be tuned to compensate for application problems.
Instance tuning areas can be broken down further:
• Memory issues: Insufficient memory or poorly allocated memory
• I/O issues: Insufficient bandwidth, poorly allocated disk space, or poor database
configuration
• Instance configuration: Inappropriate instance parameters, and poor recovery and
availability configuration

Oracle Database 10g: Performance Tuning 1-7

Which Tuning Methodology Is Used?
The methodology that you use varies with the tools that are available.
If you have Oracle Database 10g: Enterprise Edition with the optional tuning packs, Automatic
Database Diagnostic Monitor (ADDM) is available along with other Automatic Workload
Repository (AWR)–based tools.
If you have Oracle Database 10g: Standard Edition, the tool to use is Statspack.
The steps for using both tools (ADDM and Statspack) are covered in this course.
In addition, many DBAs have developed their own tools and scripts for tuning.
All tuning tools depend on the basic tools of the dynamic performance views, statistics, and
metrics that are collected by the instance.

Oracle Database 10g: Performance Tuning 1-8

Traditional Performance Tuning Methodology: Challenges
There are three main phases in any performance tuning methodology.
• Data collection: In this phase, you need to identify the information relevant to diagnosing
performance problems and set up an infrastructure to collect that information on a regular
basis. However, your biggest challenge is to be able to replay the workload that causes the
problems you encounter so that you can evaluate your solution.
• Data analysis: This phase is probably the most difficult because it needs an expert to
understand and correlate all the relevant statistics together.
• Solution implementation: In this phase, you are often faced with multiple solutions for
different problems identified during the previous phase. However, you need to use your
own judgment to prioritize and quantify the solutions by impact.

Oracle Database 10g: Performance Tuning 1-9

Performance Monitoring Solutions
In addition to the reactive tuning capabilities of previous releases (such as Statspack, SQL trace
files, and performance views), Oracle Database 10g includes new methodologies to monitor your
database.
• Proactive monitoring with Automatic Database Diagnostic Monitor (ADDM): This
component is the ultimate solution for Oracle database tuning. ADDM automatically
identifies bottlenecks within the Oracle database. Additionally, working with other
manageability components, ADDM makes recommendations about the options available
for fixing these bottlenecks.
• Reactive monitoring:
- Server-generated alerts: The Oracle database server can automatically detect
problematic situations. Reacting to a detected problem, the Oracle database server
sends you an alert message with possible remedial action.
- The Oracle database server has powerful new data sources and performance-reporting
capabilities. Database Control provides an integrated performance management
console that uses all relevant data sources. Using a drill-down method, you can
manually identify bottlenecks with just a few mouse clicks.

Oracle Database 10g: Performance Tuning 1-10

Performance Monitoring Solutions (continued)
Data sources are included to capture important information about your database’s
health—for example, memory statistics (for current diagnostics) as well as statistics history
stored in Automatic Workload Repository (AWR).
AWR simplifies performance data collection, and it has been designed with a high degree of
manageability, automation, and data collection efficiency, and after careful consideration of the
data volume collected. AWR is a part of the Database Diagnostics pack along with other features
such as Automatic Database Diagnostic Monitor (ADDM).
If you use the Database Diagnostics pack, the first place to go for performance diagnostic help is
ADDM. ADDM simplifies performance diagnosis by making it automatic, using the data
collected by AWR. If you are licensed to use the Diagnostics Pack, you should use ADDM to
perform the diagnostic work for you. For up-to-date license information specific to your release,
refer to the Oracle Database Licensing Information manual. If you use the Database Diagnostics
pack, you should use only AWR to capture performance data.

Oracle Database 10g: Performance Tuning 1-11

Using Features of the Packs
The management packs names and features are listed in the left section of the slide. They all
require a separate license that can be purchased only with Oracle Database Enterprise Edition.
The features in these packs are accessible through Oracle Enterprise Manager Database Control,
Oracle Enterprise Manager Grid Control, and APIs provided with the Oracle database software.
• Oracle Database Diagnostic Pack provides automatic performance diagnostic and advanced
system-monitoring functionality. The following are part of this pack:
- The DBMS_WORKLOAD_REPOSITORY package
- The DBMS_ADVISOR package, if you specify ADDM as the value for the
ADVISOR_NAME parameter, or if you specify any value starting with the ADDM
prefix for the value of the TASK_NAME parameter
- The V$ACTIVE_SESSION_HISTORY dynamic performance view
- All data dictionary views beginning with the DBA_HIST_ prefix, along with their
underlying tables
- All data dictionary views with the DBA_ADVISOR_ prefix if queries to these views
return rows with the value ADDM in the ADVISOR_NAME column or a value of
ADDM* in the TASK_NAME column or the corresponding TASK_ID

Oracle Database 10g: Performance Tuning 1-12

Using Features of the Packs (continued)
- The following reports found in the /rdbms/admin/ directory of the
ORACLE_HOME directory are part of this pack: awrrpt.sql, awrrpti.sql,
addmrtp.sql, addmrpti.sql, awrrpt.sql, awrrpti.sql,
addmrpt.sql, addmrpti.sql, ashrpt.sql, ashrpti.sql,
awrddrpt.sql, and awrddrpi.sql.
• Oracle Tuning Pack provides expert performance management for the Oracle database
environment, including SQL tuning and storage optimization. Oracle Diagnostic Pack is a
prerequisite product to Oracle Tuning Pack. Therefore, to use Tuning Pack, you must also
have a Diagnostic Pack. The following are part of this pack:
- The DBMS_SQLTUNE package
- The DBMS_ADVISOR package, when the value of the ADVISOR_NAME parameter is
either SQL Tuning Advisor or SQL Access Advisor
- The sqltrpt.sql report found in the /rdbms/admin/ directory of the
ORACLE_HOME directory
• Oracle Configuration Management Pack automates the time-consuming and often error-
prone process of software configuration, software and hardware inventory tracking,
patching, cloning, and policy management.
If you cannot purchase the packs mentioned above, especially the Database Diagnostics and
Database Tuning packs, you can still use the traditional approach to performance tuning and
monitoring by using Statspack reports, SQL traces, and most of the base statistics shown in the
previous slide.

Oracle Database 10g: Performance Tuning 1-13

Tuning Scenario Alternatives
The slide compares the tuning steps with and without the use of ADDM for a hard-parse
scenario.
Here are the steps involved when you do not use ADDM:
1. You receive a call from a user complaining that the system is slow.
2. You examine the server machine and see that there are plenty of resources available, so
obviously the slowdown is not due to the OS problems on the machine.
3. You look at the database instance and see that many of the sessions are waiting on latch-
free waits.
4. Drilling down into the latches, you see that most of the latch-free waits are on library cache
and shared pool latches.
5. From experience and referring to a number of books on the subject, you know that these
latches are often associated with hard-parsing issues. For a double check, you look at the
rate at which the statistics parse time elapsed and parse time CPU are increasing. You also
observe that the elapsed time is accumulating much faster than CPU time. Your suspicion is
confirmed.

Oracle Database 10g: Performance Tuning 1-14

Tuning Scenario Alternatives (continued)
6. At this stage, you have several ways to proceed, all of which try to identify skewed data
distribution. One way is to look at the statistics for parse count (hard) for all sessions to see
whether there are one or more sessions responsible for the majority of the hard parses. An
alternative is to examine the shared pool to determine whether there are many statements
with the same SQL plan but with different SQL text.
In your example, you do the latter and find that there are a small number of plans
associated with many different SQL texts.
7. When you review a few of these SQL statements, you determine that the SQL statements
contain literal strings in WHERE clauses and so each of the statements must be separately
parsed.
8. Having seen cases like this before, you can now say that the root cause of the problem is
hard parsing caused by not using bind variables. You can thus move on to fixing the
problem.
The following are the steps involved when using ADDM for the same scenario:
a. You receive a call from a user complaining that the system is slow.
b. You examine the latest ADDM report and the first recommendation reads:
FINDING 3: 31% impact (7798 seconds)
------------------------------------
SQL statements were not shared due to the usage of literals.
This resulted in additional hard parses which were consuming
significant database time.
RECOMMENDATION 1: Application Analysis, 31% benefit (7798
seconds)
ACTION: Investigate application logic for possible use of
bind variables instead of literals. Alternatively, you may
set the parameter "cursor_sharing" to "force".
RATIONALE: SQL statements with PLAN_HASH_VALUE 3106087033
were found to be using literals. Look in V$SQL for examples
of such SQL statements.
From this information, you immediately know that over 30% of the time is being spent parsing,
and a recommendation to resolve the situation is provided. Note that the finding also includes a
suspect plan hash value to enable you to quickly examine a few sample statements.

Oracle Database 10g: Performance Tuning 1-15

Tuning Methodology
Oracle has developed a tuning methodology based on years of experience. The methodology
presented in this course is also presented in the Oracle Database Performance Tuning Guide.
This methodology is applied independent of the tools that you use. The ADDM tool follows this
methodology automatically. The basic steps are the following:
• To be sure that the problem is in the database instance, check the OS statistics and general
machine health before tuning the instance.
• Tune from the top down. Start with the design, then the application, and then the instance.
As an example, try to eliminate the full table scans causing the I/O contention before
tuning the tablespace layout on disk. The design should use appropriate data structures for
the application and load characteristics. For example, reverse key indexes may work well
in a RAC environment to reduce hot blocks due to a sequential primary key, but they may
also lead to a large number of blocks being shipped across the interconnects if every
instance is inserting into the same table. The application should avoid processes that
require serialization through a single resource. A simple example is a single check number
generator used by multiple processes. Tuning at the instance level is often limited by design
and application choices.

Oracle Database 10g: Performance Tuning 1-16

Tuning Methodology (continued)
• Tune the area with greatest potential benefit. The tuning methodology presented in this
course is simple. Identify the biggest bottleneck and tune it. Then repeat this process. All
the various tuning tools have some way to identify the SQL statements, resource
contention, or services that are taking the most time. Oracle Database 10g provides a time
model and metrics to automate the process of identifying bottlenecks.
• Stop tuning when you meet your goal. This step implies that you already set tuning goals.
This is a general approach to tuning the database instance and may require multiple passes.
From a practical perspective, tuning during the design and development phases of a project tends
to be more top-down. The tuning efforts during testing and production phases are often reactive
and bottom-up. In all phases, tuning depends on actual test cases because theoretical tuning does
not know all the variables that can be present. After a problem area is suspected or discovered, a
test case is created and the area is tuned as in all the examples given in this course. Tune the area
that has the greatest potential benefit. Reduce the longest waits and the longest service times.

Oracle Database 10g: Performance Tuning 1-17

Oracle Database 10g: Performance Tuning 1-18