Академический Документы
Профессиональный Документы
Культура Документы
James F. Koopmann
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.
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
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.
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.
For instance, if the previously mentioned SQL was issued again in 10 minutes, that SQL
might have these statistics.
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
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.
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.
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;
2 Use the SID & SERIAL# column information to start a trace for a particular session.
Refer to the Oracle documentation site and read about the DBMS_MONITOR package:
http://www.oracle.com/technology/software/tech/orion/index.html
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.
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.
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.
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.
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.
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
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
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
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:
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
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.
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
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.
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
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
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.