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, then 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 developers for application tuning, or system administrators
for tuning OS and I/O issues. This course is intended for the DBA 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
What to Tune Overall?
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.
Separate courses are available to address the specific skills and tools used in
application tuning. 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. There are separate
courses available to address these areas: 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.
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.
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 you can focus on instance issues. Outside of the practice
environment the 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
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.

Tuning Methodology
Oracle has developed a tuning methodology based on years of experience. This
methodology is applied independent of the tools that you use. The ADDM tool
follows this methodology automatically. The basic steps are the following:
Check the OS statistics and general machine health before tuning the instance to be
sure that the problem is in the database 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 it 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
though 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.
Tune the area with greatest potential benefit. The tuning methodology presented in
this course is simple. Identify the biggest bottleneck and tune it. Repeat. 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 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 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
largest service times.