Вы находитесь на странице: 1из 28

Tuning Oracle with Consideration for

Storage and Your Application Mix

James F. Koopmann

Technical White Paper


26928-00, Rev. A
February 2007
Copyright © 2007 LSI Logic Corporation. All rights reserved.
Contents

Chapter 1: INTRODUCTION

Chapter 2: UNDERSTANDING THE APPLICATION MIX


Determining Oracle Workloads................................................................................................2-2
Workload for Existing Oracle Database...................................................................................2-3

Chapter 3: ANALYZING SQL


Oracle Trace .............................................................................................................................3-1
Creating a Trace .......................................................................................................................3-2
Original Method ..................................................................................................................3-2
Newer Method Using DBMS_MONITOR Package...........................................................3-2
Generated Trace Files .........................................................................................................3-3
Active Sessions ........................................................................................................................3-4
V$SESSION........................................................................................................................3-4
V$SQLAREA .....................................................................................................................3-5
DBMS_XPLAN Procedure.................................................................................................3-7
V$SQL_PLAN_STATISTICS............................................................................................3-7
V$SQLTEXT ......................................................................................................................3-8
V$SESS_IO ........................................................................................................................3-9

Chapter 4: RESOURCE CONTENTION


True Session Wait Activity in Oracle 10g ...............................................................................4-1
Resource Currently in High Demand..................................................................................4-2
What User is Waiting the Most .....................................................................................4-2
SQL Currently Using the Most Resources..........................................................................4-3
What Object is Currently Causing the Highest Resource Waits.........................................4-3

Tuning Oracle: Your Application Mix iii


Chapter 5: CONCLUSION
Contact Information .................................................................................................................5-1
North American Headquarters ......................................................................................5-1
LSI Logic KK Headquarters .........................................................................................5-1
LSI Logic Europe Ltd. European Headquarters ...........................................................5-1
References ................................................................................................................................5-2

iv Tuning Oracle: Your Application Mix


Chapter 1
Introduction

As a database administrator you already know that tuning an Oracle database is a complex
task. With hundreds of features and numerous application interfaces, you must weigh
tuning decisions carefully, and not lose sight of the intricacy of the full system. In fact
tuning Oracle is not a one-person job. Oracle tuning requires not only the database
administration staff but others who understand the full intent of the database and the
applications:
• Developers
• System administrators
• Storage administrators
• Architects
• Business personnel
You can address the complex task of tuning an Oracle database using a systematic
approach. This paper looks at the application aspects of tuning an Oracle database. Other
papers address the aspects of database files and memory.
An application is made up of code, procedural logic and SQL, that accesses the underlying
Oracle database objects and causes input/output (I/O) on the storage array. The application
and its connected sessions request information. These requests initiate requests for
physical I/O with the storage array. While this information is basic, it is sometimes
forgotten in the high speed at which development staffs are required to work and produce
solutions.
The performance you get out from the storage array is directly linked through the database
and ultimately to applications that request the information on disk drives.
• A poorly configured database system makes any application perform poorly.
• A poorly written application inhibits a database system from performing optimally.
No tuning effort is valid without considering whether the application is requesting
information optimally.

Tuning Oracle: Your Application Mix 1-1


Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Specifically, this paper focuses on these factors:


• Understanding the application mix
• Determining Oracle workload
• Identifying methods for analyzing the Oracle sessions:
■ Oracle trace
■ Active sessions
■ Resource contention
After you have analyzed your storage system, you can make the following decisions for
improved performance:
• Reconfiguring to allow for better IOPS or MBps
• Moving data files around to use more disk drives
• Adding more disk drives for higher throughput
• Purchasing additional storage equipment
• Reducing IOPS or MBps through the application

1-2 Tuning Oracle: Your Application Mix


Chapter 2
Understanding the Application Mix

Understanding the application mix that accesses an Oracle database is vital in


understanding the workload mix placed on a database and ultimately the performance
requirements of the storage system. With an understanding of the application mix, you can
make many of the adjustments to the configuration parameters within Oracle or the
storage array.
Applications can be categorized as either online transaction processing (OLTP) or online
analytical processing (OLAP):
• Typically, OLTP applications have these characteristics:
■ Read and write intensive
■ Transaction-based with performance based on I/Os per second (IOPS) along with
average latency or I/O turn-around time

Large bursts of small reads followed by inserts and updates

Mostly driven by the database issuing small random I/Os the size of the defined
Oracle database block size (db_block_size)
■ Database block size ranging from 2KB to 32KB with 8KB being average

IMPORTANT Be aware that although a database may have a low write percentage,
the database logs might make up for this with writes and must be
considered. Certain operations such as table scans or index scans,
backups, and parallel queries also can issue large I/Os.

Identify the reads-to-writes percentage as this is a critical ratio for determining storage
configurations. A typical ratio is 70:30.
• Typically OLAP applications have these characteristics:
■ Considered as data warehouses or reporting systems
■ Categorized as throughput-based and performance is based on moving large
amounts of data in mega-bytes per second (MBps)

Almost always purely read-only databases except during the load stage

Primarily large multi-block read and write I/O streams

Tuning Oracle: Your Application Mix 2-1


Understanding the Application Mix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Keep in mind that application mixes might change:


• A simple OLTP database could be cloned to a different system and begin to be used
with an OLAP application. The data is the same, but the I/O pattern is very different.
• A new group of power users that could turn an OLTP into an OLAP reporting engine
without giving notice.
The application mix might change throughout the day.
• Database backups that run during the day will change the type of read activity of the
database.
• Data loads or extraction, transformation, and load (ETL) processing could switch an
OLAP environment into an OLTP environment.

Determining Oracle Workloads


An Oracle workload is often representative of its application mix. Understanding and
translating an application mix into a database workload is critical for optimizing a storage
system. By determining the workload, you can better set the various parameters. Keep in
mind that a single storage system if configured for two different workload types will not
perform as well as a single storage system configured for a single workload type. Just as
there are basically two application mixes there are two primary workload types, small
random I/O and large sequential I/O.
• Small random I/O
■ OLTP applications
■ Transaction-based (IOPS & latency)
■ High levels of IOPS requiring more back-end drives
• Large sequential I/O
■ OLAP applications
■ Throughput-based (MBps)

High levels of MBps that can often be satisfied by less back-end drives
Large random I/O is a less common workload that you might need to consider. Because of
various database traffic or configurations, large sequential I/O may be turned into large
random I/O at the disk drive level of the storage system. Here are some examples:
■ Large sequential I/O caused by data warehouses, reporting applications, or utilities
such as backups that typically request large I/O streams can be broken up by
normal small random I/O of an OLTP system.
■ Striping will spread large sequential I/O across many disk drives that cause the
storage array to experience large random I/O.

2-2 Tuning Oracle: Your Application Mix


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Workload for Existing Oracle Database

Database systems often are predominantly one of the three previously mentioned
workloads. However, there are times when a database exhibits one or more of those
workloads continually and thus falls into the category of a mixed I/O workload.

Workload for Existing Oracle Database


If an existing Oracle 10g Release 2 (10gR2) database is available, use this SQL statement
to determine the workload.
set linesize 100
set head off

SELECT 'Number of Small Reads :'||


sum(decode(name,'physical read total IO
requests',value,0)-
decode(name,'physical read total multi block
requests',value,0)),
'Number of Small Writes:'||
sum(decode(name,'physical write total IO
requests',value,0)-
decode(name,'physical write total multi block
requests',value,0)),
'Number of Large Reads :'||
sum(decode(name,'physical read total multi block
requests',value,0)),
'Number of Large Writes:'||
sum(decode(name,'physical write total multi block
requests',value,0)),
'Total Bytes Read :'||
sum(decode(name,'physical read total bytes',value,0)),
'Total Bytes Written :'||
sum(decode(name,'physical write total bytes',value,0))
FROM gv$sysstat;

Here is an example of the statistics that might be returned:

Number of Small Reads :205903


Number of Small Writes:106883
Number of Large Reads :40298
Number of Large Writes:2791
Total Bytes Read :4188587008
Total Bytes Written :2009381888

Remember that statistics contained in the GV$ views are cumulative, so obtain samples
from the beginning and the end of a peak I/O cycle. Subtract the beginning statistics from
the ending statistics to obtain true reads and true writes that have occurred. Use this
statistic to determine the read-to-write ratios and to classify the database application mix
and its workload type.

Tuning Oracle: Your Application Mix 2-3


Understanding the Application Mix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

For instance, if the previously mentioned SQL was issued again in 10 minutes, that SQL
might have these statistics.

Number of Small Reads :500211


Number of Small Writes:123474
Number of Large Reads :142981
Number of Large Writes:8010
Total Bytes Read :22232604961
Total Bytes Written :5586081648

Calculate the IOPS for the small I/O and the large I/O, the percentage of reads to writes,
and the MBps throughput. This calculation example uses the previous examples of output.
Small Read IOPS =(500211-205903)/(10*60) = 490 IOPS
Small Write IOPS =(123474-106883)/(10*60) = 27 IOPS
Total Small IOPS =(294308-16591)/(10*60) = 517 IOPS
I/O Percentage of Reads to Writes = 94:6

Large Read IOPS =(142981-40298)/(10*60) = 171 IOPS


Large Write IOPS =(8010-2791) /(10*60) = 8 IOPS
Total Large IOPS =(102683+5219) /(10*60) = 179 IOPS
I/O Percentage of Reads to Writes = 96:4

Total MBPS Read =((22232604961-4188587008)/(10*60))/1048576=


28 MBPS
Total MBPS Written =((5586081648-2009381888) /(10*60))/1048576=
5 MBPS
Total MBPS =((18044017953+3576699760)/(10*60))/1048576=
34 MBPS

Your actual numbers can help you determine performance and storage requirements.
Obtain specifications from storage vendors or use various benchmarking tools such as
Oracle's Orion Workload tool to obtain them. By using the workload mix statistics and
available specifications for your particular storage array, you can make informed
decisions.
If you see Oracle workloads that are near the specifications for your storage array,
consider reconfiguration to allow for better IOPS or MBps.

2-4 Tuning Oracle: Your Application Mix


Chapter 3
Analyzing SQL

At the heart of every application is the underlying SQL. You can find many books and
procedures for determining troubleshooting and tuning SQL. As a start, consider using
Oracle trace files and active sessions to find problematic SQL, applications, and users.
You can use the information derived from trace files and active sessions to change either
application behavior or user behavior to reduce the workload placed on a storage array.
Use these tools to assist you in identifying objects in your database which are being
accessed the most, and in segregating the objects to improve I/O activity.

Oracle Trace
For many years, database administrators have been getting low level tracing information
about sessions by creating and reading Oracle-generated trace files. You can generate trace
files against a full system load or individual sessions. Trace files provide this information:
• SQL statements
• Explain plans
• Parse, run, and fetch counts
• CPU and elapsed times
• Physical reads and logical reads
• Number of rows processed
• Misses on the library cache
• User name under which each parse occurred
• Each commit and rollback
• Wait event data
• Row operations
• Logical, physical and elapsed times I/O types
Although Oracle 10g provides a few mechanisms to trace the session by querying internal
views, the generation of trace files is still quite viable.

Tuning Oracle: Your Application Mix 3-1


Analyzing SQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Creating a Trace
Original Method
1 Use the DBM_SESSION.SQL_TRACE command. You must enter the command
through the connected session or application.
SQL> exec dbms_session.set_sql_trace(true);

2 Use the ALTER SESSION SET SQL_TRACE command. You must enter the
command through the connected session or application.
SQL> ALTER SESSION SET SQL_TRACE = TRUE;

Newer Method Using DBMS_MONITOR Package


DBMS_Monitor is a robust package that allows starting a trace through a PL/SQL
interface and from outside the session or application. DBMS_MONITOR has the added
features to trace on a set of various application specific environment variables that can be
set within applications.
1 Determine the connected session or group of sessions that you would like to trace.
Query the V$SESSION view with this SQL.
SQL> SELECT sid, serial#,
client_identifier, service_name, action, module
FROM V$SESSION

2 Use the SID & SERIAL# column information to start a trace for a particular session.

Table 3-1 DBMS_MONITOR Package Variables

Session Variable Description


SID Identifier for the connected session.
SERIAL# Serial number of the connected.

SQL> EXECUTE DBMS_MONITOR.SESSION_TRACE_ENABLE(<SID>,<SERIAL#>,


TRUE,TRUE);

Refer to the Oracle documentation site and read about the DBMS_MONITOR package:
http://www.oracle.com/technology/software/tech/orion/index.html

3-2 Tuning Oracle: Your Application Mix


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a Trace

Generated Trace Files


When a trace file is generated, Oracle writes the file to a disk drive in an area that is
dictated by the parameter USER_DUMP_DEST. To find the USER_DUMP_DEST area
on a disk drive, use one of two strategies:
• Check the typical location, which is the $ORACLE_BASE/SID/udump directory on
the database server.
• Run these commands:
SQL > show parameter user_dump_dest
SQL > select value from v$parameter where name =
'user_dump_dest';

Use this syntax to run the TKPROF utility against a trace file and to then print a readable
report:
tkprof trace_file report_file

There are a several options to tkprof for providing various output characteristics:
• Formatting all cryptic information into a more readable form
• Breaking out each statement that was run during the trace period
• Presenting various statistics for determining slow performance areas and where you
might spend time tuning application code
• Generating an SQL script that allows you to store the captured statistics in a database
• Determining the explain plan for that was run SQL statements
The tkprof utility provides a summary as well as detail information for collected
statistics. The Oracle trace is a valuable tool for extracting statistics for a single session or
across a grouping of sessions. Oracle trace shows the current real-time activity for I/O
patterns and CPU activity. This is valuable information for determining the SQL causing
performance issues for placement of database objects across a storage array and for tuning
an Oracle database based on those SQL commands.

Tuning Oracle: Your Application Mix 3-3


Analyzing SQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Active Sessions
Active sessions is a set of SQL statements that you can use to help find active sessions that
are currently causing problems in the database. These SQL statements show all active
sessions but can easily be modified to find those sessions that are having particular
problems with I/O activities. As a database administrator you must to be able to detect
who is accessing the database and what SQL they are running so that you can develop a
strategy to reconstruct the application or the storage arrays for better performance.
This paper presents only basic active session information. For detailed techniques and
procedures, see the Oracle documentation site and read about SQL tuning: http://
www.oracle.com/technology/software/tech/orion/index.html
Active sessions can provide such invaluable information as, what SQL is running within
the Oracle engine, the SQL access path, and the true statistical values accumulated for
each run. Try these scripts, perhaps add to them, and you can begin to determine what
SQL is running within your environment.

V$SESSION
Use the V$SESSION to determine who is logged into the database and from a high level
overview, what they are doing. Table 3-2 shows some of the important columns for
obtaining this information.

Table 3-2 V$SESSION Columns

Column Description
SADDR Unique Oracle session address
SID Unique Oracle session
USERNAME Oracle user (same as from dba_users)
Status of the session. Check for ACTIVE sessions that are running
STATUS
SQL.
Operating system process id for the connection. This information is given
PROCESS
only as a reference for checking on the operating system side.
TYPE Type of session connected to the database
Address. Use this information with the SQL_HASH_VALUE column
SQL_ADDRESS
information to identify the SQL statement currently being ran.
Hash value unique to the SQL statement. The SQL_HASH_VALUE
column is unique for a particular SQL statement regardless of when
SQL_HASH_VALUE
it is run. Use this information with the SQL_ADDRESS column
information to identify the SQL statement currently running.

3-4 Tuning Oracle: Your Application Mix


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Active Sessions

Run the following SQL statement to determine if the user is actually running SQL at the
current time:
select sid,
to_char(logon_time,'MMDDYYYY:HH24:MI') logon_time,
username,
type,
status,
process,
sql_address,
sql_hash_value
from v$session
where username is not null

If a user has SQL that is running, the status column will be ACTIVE and the SQL_ADDR
& SQL_HASH_VALUE will be populated.

V$SQLAREA
Oracle assigns a unique SQL_HASH_VALUE and SQL_ADDRESS to each SQL
statement. Join columns from V$SESSION and V$SQLAREA to determine who is
running any current SQL. Table 3-3 shows some of the important columns for obtaining
this information from an SQL statement.

Table 3-3 V$SQLAREA Columns

Column Description
First 1000 characters of the SQL being run by the user. If you are
SQL_TEXT concerned with an SQL statement that is longer than 1000
characters, use V$SQL_TEXT which is described at V$SQLTEXT.
OPTIMIZER_MODE Optimizer mode the query is using
ADDRESS Address to the parent of this cursor/SQL
HASH_VALUE Hash value to the parent statement in the library cache
CPU_TIME Accumulated microseconds of CPU time used by the SQL
ELAPSED_TIME Accumulated microseconds elapsed time used by the SQL
EXECUTIONS Total number of times this statement has been run
DISK_READS Total number of disk reads for all runs
DIRECT_WRITES Total number of direct writes for all run
BUFFER_GETS Total number of buffer gets for all run
ROWS_PROCESSED Total number of rows processed for all runs
Session identifier. Use this information along with the with information in
SID
the SERIAL# column to identify a session and the objects that it uses.

Tuning Oracle: Your Application Mix 3-5


Analyzing SQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Table 3-3 V$SQLAREA Columns (continued)

Column Description
Serial number. Use this information along with the with information in the
SERIAL#
SID column to identify a session and the objects that it uses.
SQL_ID Identifier to the SQL currently running.
SQL_CHILD_NUMBER Child number of a SQL statement that is currently being ran

When Oracle runs a query, Oracle places the query in memory with a unique
SQL_HASH_VALUE and the SQL_ADDRESS for each SQL statement. This allows
Oracle to reuse the same SQL if needed by the running session at a latter date or by
another user.

The V$SQLAREA view gives you information on the amount of disk drive activity
caused by a particular SQL statement. Check for SQL statements that result in many reads
or writes but that process only a few rows of data. This pattern of activity can stress the
storage array and identify an area for improvement.
Use the following SQL statement to get the information on disk drive activity:
select session.sid,
session.serial#,
session.sql_id,
session.sql_child_number,
sesion.username,
optimizer_mode,
hash_value,
address,
cpu_time,
elapsed_time,
disk_reads,
direct_writes,
buffer_gets,
rows_processed,
sql_text
from v$sqlarea sqlarea, v$session session
where session.sql_hash_value = sqlarea.hash_value
and session.sql_address = sqlarea.address
and session.username is not null

3-6 Tuning Oracle: Your Application Mix


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Active Sessions

DBMS_XPLAN Procedure
DBMS_XPLAN is a procedure that you can use to obtain a run plan of a currently running
SQL statement. To use DBMS_XPLAN, you only need to supply the SQL_ID and
SQL_CHILD_NUMBER, from V$SESSION. DBMS_XPLAN will produce a formatted
explain output. Supply an SQL_ID and SQL_CHILD_NUMBER and then run this SQL
statement:
SELECT * FROM
table(DBMS_XPLAN.DISPLAY_CURSOR(('<sql_id>'),<sql_child_number>
));

From this SQL statement, you get the full explain output showing access paths, tables, and
indexes being used. Take note of the ID column for each line of output. Use this output to
find the actual runtime statistics for that line of the explain plan.
This paper presents only basic tuning for Oracle applications. For detailed techniques and
procedures, see the Oracle documentation site and read about SQL tuning: http://
www.oracle.com/technology/software/tech/orion/index.html

V$SQL_PLAN_STATISTICS
Use the V$SQL_PLAN_STATISTICS view to look at run statistics for an SQL statement.
The limitation of using the V$SQLAREA view is that it is an accumulation of statistics for
a particular SQL statement. If you need single-run statistics for an SQL statement, use the
V$SQL_PLAN_STATISTICS view. There are columns in this view that report on the last
time the statement was run. A real strength of this view is the actual statistics for each step
in the run plan through the OPERATION_ID column. Table 3-4 shows some of the
important columns for obtaining this information from an active SQL statement

Table 3-4 V$SQL_PLAN_STATISTICS Columns

Column Description
ADDRESS Address to the parent of this cursor/SQL
HASH_VALUE Hash value to the parent statement in the library cache
PLAN_HASH_VALUE Plan hash value
OPERATION_ID Number for each step in the run plan
OUTPUT_ROWS Number of rows returned
LAST_CR_BUFFER_GETS Number of consistent gets for the last run of the plan for a given step
LAST_DISK_READS Number of physical disk reads for the last run of the plan for a given step

Tuning Oracle: Your Application Mix 3-7


Analyzing SQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Run the following SQL statement to obtain statistics:


select sesion.sid,
sesion.username,
sql_plan_statistics.operation_id “Id”,
sql_plan_statistics.last_output_rows “Rows”,
sql_plan_statistics.last_cr_buffer_gets “Consistent Gets”,
sql_plan_statistics.last_disk_reads “Disk Reads”
from v$sql_plan_statistics sql_plan_statistics, v$session
sesion
where sesion.sql_hash_value = sql_plan_statistics.hash_value
and sesion.sql_address = sql_plan_statistics.address
and sesion.username is not null

V$SQLTEXT
Use the V$SQL TEXT statement to view SQL statements longer than 1000 characters.
Table 3-5 shows some of the important columns in the V$SQLTEXT view:

Table 3-5 V$SQLTEXT Columns

Column Description
Address to the parent of this cursor/SQL. Use this information along with
ADDRESS the HASH_VALUE to identify the SQL statement that is currently
running.
Hash value to the parent statement in the library cache. The
HASH_VALUE HASH_VALUE is unique for a particular SQL statement regardless
of when it runs.
PIECE Sequence number for piecing individual parts of SQL statement together
SQL_TEXT Individual piece of SQL text

Run the following SQL statement to view longer SQL text:


select sesion.sid,
sql_text
from v$sqltext sqltext, v$session sesion
where sesion.sql_hash_value = sqltext.hash_value
and sesion.sql_address = sqltext.address
and sesion.username is not null
order by sqltext.piece

3-8 Tuning Oracle: Your Application Mix


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Active Sessions

V$SESS_IO
Use the V$SESS_IO view to determine if a query is responsive and actually doing work
within the database. This command is useful if you have an active session and through the
V$SESSION or V$SQLAREA views show a valid SQL statement that seems to be taking
very long. If the GETS, READS, or CHANGES columns continue to increase for a
session, you can be certain that the SQL statement is responding. Table 3-6 shows some of
the important columns in the V$SESS_IO view.

Table 3-6 V$SESS_IO

Column Description
Unique Oracle session. Use the Oracle session identifier (SID) to link
SID
back to the V$SESSION view for the active session.
BLOCK_GETS Number of block gets done
CONSISTENT_GETS Number of consistent gets done
PHYSICAL_READS Number of physical reads done
BLOCK_CHANGES Number of blocks that where changed
CONSISTENT_CHANGES Number of consistent block changes done

A simple join, linking of two tables, to the V$SESSION view gives you the results to
determine the I/O being run by active sessions. Use the following SQL statement to show
the V$SESS_IO view.
select sess_io.sid,
sess_io.block_gets,
sess_io.consistent_gets,
sess_io.physical_reads,
sess_io.block_changes,
sess_io.consistent_changes
from v$sess_io sess_io, v$session sesion
where sesion.sid = sess_io.sid
and sesion.username is not null

Tuning Oracle: Your Application Mix 3-9


Analyzing SQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3-10 Tuning Oracle: Your Application Mix


Chapter 4
Resource Contention

To address resource contention in Oracle, you must obtain information on the areas of
slow performance in your system. Every application query must acquire resources such as
disk drives, locks, and memory calls to retrieve and alter information in database objects.
When a database is improperly tuned, these resource begin to get over-used or the request
queues for those objects becomes long. Processes must wait in a queue for a desired
resource. Oracle keeps track of these resource wait times and you can query for those wait
times through various SQL statements. You can then identify those resources that are most
waited upon and tune the various parts of the database or application to make those
resources more available. For storage array concerns, look for resources that are related to
read, writes, any file, and the buffers that are used for reading and writing to disk drive
files.

True Session Wait Activity in Oracle 10g


This chapter contains example sets of SQL statements for determining wait events, or poor
resource usage within your database. These sets of SQL use the V$ACTIVE_SESSION
_HISTORY view, which contains one row of sampled activity for each session that was
active, either on the central processing unit or waiting for a resource. This new view in
Oracle 10g also contains sample data that was acquired through internal kernel code. The
data is similar to the statistics seen in V$SESSION_WAIT, but has a limited amount of
buffer space, about two megabytes per central processing unit. As this buffer gets full due
to the activity on the system, Oracle moves the captured statistics to disk drive. This move
is part of the Automatic Workload Repository (AWR) Snapshot mechanism, and the
statistics are then available through the DBA_HIST_ACTIVE_SESS_HISTORY view.
Depending on the activity of the system, when querying for current information, you
might have to view both areas for a valid history. This is historical activity of the waits that
have occurred for SQL run. While you can view historical activity to find the true cause of
poor performance, there are some limitations:
• Because the statistics are stored in the rotating buffer and are moved only to the
DBA_HIST_ACTIVE_SESS_HISTORY view through a Snapshot, you may loose
statistics.
• When the Snapshot mechanism (AWR) moves database statistics between the
V$ACTIVE_SESSION_HISTORY view and the
DBA_HIST_ACTIVE_SESS_HISTORY view, AWR only takes a sampling of the data
in the V$ACTIVE_SESS_HISTORY view for the Snapshot.

Tuning Oracle: Your Application Mix 4-1


Resource Contention. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

• Because the AWR takes only a sampling of the data in the


V$ACTIVE_SESS_HISTORY view, you must either get what you want in the
V$ACTIVE_SESS_HISTORY view before a Snapshot or consider manually saving
the data elsewhere.

Resource Currently in High Demand


You can run an SQL query to get a list of the resources that were in high demand on your
system during the last 30 minutes. Look for those wait events that refer to reads, writes,
files, or buffers. Investigate any activity that produced high wait times.
Run this SQL statement to check for high demand on resources:
select active_session_history.event,
sum(active_session_history.wait_time +
active_session_history.time_waited) ttl_wait_time
from v$active_session_history active_session_history
where active_session_history.sample_time
between sysdate - 60/2880 and sysdate
group by active_session_history.event
order by 2

What User is Waiting the Most


Sometimes one user or a group of users can cause databases process to stop suddenly. You
can run an SQL query to determine usage. The results are for a single point in time,
independent of the total resources that a user has used. Specifically, you can answer these
questions:
• What user is consuming the most resources.
• Who is waiting the most for resources at a point in time.
If a user experiences delays, you can use this query to verify that the user is actually
waiting in the database for a result set for a given time period.
Use this example statement to determine which user is waiting more often. This SQL
statement is written for a 30-minute interval, which can be adjusted, from the current
system time.
select sesion.sid,
sesion.username,
sum(active_session_history.wait_time +
active_session_history.time_waited) ttl_wait_time
from v$active_session_history active_session_history,
v$session sesion
where active_session_history.sample_time
between sysdate - 60/2880 and sysdate
and active_session_history.session_id = sesion.sid
group by sesion.sid, sesion.username
order by 3

4-2 Tuning Oracle: Your Application Mix


. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . True Session Wait Activity in Oracle 10g

SQL Currently Using the Most Resources


You can run an SQL query to determine what SQL statement is consuming the most
resource wait times on your system. Another strategy is to use the V$SQLAREA view to
identify the top 10 or 20 SQL users on your system by disk drive reads or run.
The advantage of using this query is it that you can identify what SQL statements are
consuming resources and currently waiting the most.
select active_session_history.user_id,
dba_users.username,
sqlarea.sql_text,
sum(active_session_history.wait_time +
active_session_history.time_waited) ttl_wait_time
from v$active_session_history
active_session_history,
v$sqlarea sqlarea,
dba_users
where active_session_history.sample_time
between sysdate - 60/2880 and sysdate
and active_session_history.sql_id = sqlarea.sql_id
and active_session_history.user_id = dba_users.user_id
group by active_session_history.user_id,sqlarea.sql_text,
dba_users.username
order by 4

What Object is Currently Causing the Highest Resource Waits


You can run this query to see which objects a SQL statement is affecting. You can tailor
this query to report on the actual blocks that are being accessed within the objects for the
SQL statement. This helps you to determine if you need to reorganize your object or
redistribute them to reduce the contention on that object.
Use an SQL statement like this to determine what object is currently causing the highest
resource waits:
select dba_objects.object_name,
dba_objects.object_type,
active_session_history.event,
sum(active_session_history.wait_time +
active_session_history.time_waited) ttl_wait_time
from v$active_session_history active_session_history,
dba_objects
where active_session_history.sample_time
between sysdate - 60/2880 and sysdate
and active_session_history.current_obj# =
dba_objects.object_id
group by dba_objects.object_name,
dba_objects.object_type,
active_session_history.event
order by 4

Tuning Oracle: Your Application Mix 4-3


Resource Contention. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4-4 Tuning Oracle: Your Application Mix


Chapter 5
Conclusion

Tuning applications and the underlying storage array are critical to Oracle database
performance. Application and their connected sessions request information, which
initiates requests for physical I/O with the storage array. By matching Oracle application
requirements, IOPS and MBps, to the abilities of a storage array you can improve both the
application performance and the overall database system performance. Careful monitoring
of the database and ultimately the applications that request the information on disk drive
can ensure improved performance from the storage array.
Gaining an understanding of the application mixture, determining the Oracle workload
and analyzing Oracle sessions are strategies that you can use to tune Oracle and the
underlying storage array.
Better tuning of the applications and storage array means improved performance for
meeting the information needs of today and preparing for tomorrow’s needs.

Contact Information
For more information and sales office locations, visit the LSI Logic web sites at:
http://www.lsi.com/cm/ContactSearch.do

North American Headquarters


Milpitas, CA
Tel: 866 574 5741 (within U.S), 408 954 3108 (outside U.S.)

LSI Logic KK Headquarters


Tokyo, Japan
Tel: 81 3 5463 7165

LSI Logic Europe Ltd. European Headquarters


United Kingdom
Tel: 44 1344 413200

Tuning Oracle: Your Application Mix 5-1


Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

References
Oracle® Database Administrator's Guide 10g Release 2 (10.2)
Oracle® Database Performance Tuning Guide 10g Release 2 (10.2)
Oracle Orion downloads
http://www.oracle.com/technology/software/tech/orion/index.html
Best Practices for Creating a Low-Cost Storage Grid for Oracle Databases
http://www.oracle.com/technology/deploy/availability/pdf/ora_lcs.pdf
Resilient Low-Cost Storage
http://www.oracle.com/technology/deploy/availability/pdf/lcs_OW.doc.pdf
Orion: Oracle I/O Numbers Calibration Tool
http://download.oracle.com/otn/utilities_drivers/orion/Orion_Users_Guide.pdf

5-2 Tuning Oracle: Your Application Mix


Document Description
This document providesinformation on tuning Oracle with consideration for storage and your application
mix.

Ownership of Materials
The Document is provided as a courtesy to customers and potential customers of LSI Logic Corporation
(“LSI”). LSI assumes no obligation to correct any errors contained herein or to advise any user of liability
for the accuracy or correctness of information provided herein to a user. LSI makes no commitment to
update the Document. LSI reserves the right to change these legal terms and conditions from time to time at
its sole discretion. In the case of any violation of these rules and regulations, LSI reserves the right to seek
all remedies available by law and in equity for such violations. Except as expressly provided herein, LSI and
its suppliers do not grant any express or implied right to you under any patents, copyrights, trademarks, or
trade secret information. Other rights may be granted to you by LSI in writing or incorporated elsewhere in
the Document.

Trademark Acknowledgments
Engenio, the Engenio design, MegaRAID, HotScale, SANtricity, and SANshare are trademarks or registered
trademarks of LSI Logic Corporation. All other brand and product names may be trademarks of their
respective companies.

Performance Information
Performance tests and ratings are measured using specific computer systems and/or components and reflect
the approximate performance of LSI products as measured by those tests. Any difference in system
hardware or software design or configuration may affect actual performance. Buyers should consult other
sources of information to evaluate the performance of systems or components they want to purchase.

Вам также может понравиться