Escolar Documentos
Profissional Documentos
Cultura Documentos
Study Guide
1Z0-033
Last Updated:
October 15, 2006
www.examguru.net
WWW.EXAMGURU.NET
Copyright © 2004 - 2006 by ExamGuru, Inc.
All rights reserved. No part of this document sh all be stored in a retrieval system or
transmitted by any means, electronic, mechanical, photocopying, recording, or
otherwise, without written p ermission from the ExamGuru. No patent liability is
assumed with respect to the use of the information contained herein.
Warning and Disclaimer
Every effort has been made to make this document as complete and as accurate as
possible, but no warranty or fitness is implied. The publisher and au thors assume no
responsibility for errors or omissions. The information provided is on an "as is" basis.
The authors and the publisher shall have neither liability nor responsibility to any
person or entity with respect to any loss or damages arising from the information
contained in this document.
Report Unauthorized Usage
Report unauthorized usage, or free downloads made available to public by
anyone and ExamGuru will reward you with more free products and/or cash.
Please contact ExamGuru directly via: abuse@examguru.net
Performance Tuning (IZ0-033)
Table of Contents
Performance Tuning Overview.............................................................................................................................. ......... 3
Diagnostic and Tuning Tools .............................................................................................................................. ........... 5
Oracle Configuration Parameters ........................................................................................... ................................... .... 5
Performance Tuning Views.............................................................................................................................. .............. 5
The Alert Log .............................................................................................................................. ................................... 6
Trace Files .............................................................................................................. ....................................................... 7
Background Trace Files .............................................................................................................................. ............... 7
Event Trace Files .............................................................................................................................. ......................... 7
User Trace Files ............................................................................................... ............................... ........................... 8
TKPROF .............................................................................................................................. ....................................... 8
UTLBSTAT/UTLESTAT .............................................................................................................................. ................. 10
StatsPack .................................................................................................. ................................................................... 10
Oracle Enterprise Manager (OEM) GUI Performance Tools ....................................................................................... 11
The OEM Architecture .............................................................................................................................. ................ 11
The OEM Console.............................................................................................................. ...................................... 11
Oracle Diagnostics Pack .............................................................................................................................. ............ 12
Oracle Tuning Pack.............................................................................................................................. .................... 13
Oracle-provided Tuning Scripts ..................................................................................................... .............................. 13
The Explain Facility.............................................................................................................................. ........................ 14
The AUTOTRACE Facility .............................................................................................................................. ............. 15
Tuning Applications and Design Tuning ................................................................................................ .................... 15
OLTP Versus DSS Tuning Requirements ................................................................................................................... 15
The Optimizer ............................................................. ................................................................. ................................ 16
Optimizer Statistics.............................................................................................................................. ..................... 17
Plan Stability .............................................................................................................................. .................................. 19
Materialized Views ....................................... ....................................................................................... ......................... 20
Indexes.............................................................................................................................. ........................................... 20
Partitions .............................................................................................................................. ........................................ 21
Clusters .............................................................................................................................. .......................................... 22
Tuning The Shared Pool ................................................................................... ........................................... ................. 22
Tuning the Library Cache.............................................................................................................................. ............... 23
Tuning the Dictionary Cache.............................................................................................................................. .......... 23
To Improve Performance ...................................................................................... ........................................ ............... 23
The Large Pool .............................................................................................................................. .............................. 24
The Java Pool .............................................................................................................................. ................................ 24
Performance Tuning (IZ0-033)
1 Data Design
2 Application Design
3 Memory Allocation
5 Resource Contention
6 Underlying Platform
90% of all tuning problems are resolved within the first 2 steps above. Exam questions, however, concentrate
mainly on the last 4 steps.
In 9i, Oracle Corporation favors a set of prioritized Performance Tuning Principles, instead of their older Oracle
Tuning Methodology:
Priority: Principle:
Oracle promotes the newer Performance Tuning Principles as best for tuning Production systems, and the older
Oracle Tuning Methodology as best for tuning Development systems. The new approach is also better for tuning
packaged (vended) applications, since customers can not usually change the data design or application design in this
case (steps 1 and 2 of the older methodology).
Tuning should be goal-oriented -- you set goals, then measure your progress tow ards those goals throughout the
tuning process. Tuning is an iterative process -- it may be ongoing and cycle through several problems and
resolutions before you have achieved all your tuning goals. Tuning may occur within the context of a Service Level
Agreement (SLA) -- a written document that specifies what the IT department guarantees for end users with respect to
the performance of a particular application or system.
Performance Tuning (IZ0-033)
Goal-oriented tuning means establishing a statistical picture of system performance, called a benchmark.
Benchmark statistics can then be re-taken as the tuning process proceeds, to see if you are meeting your tuning
goals. This Cramsession tells you how to gather Oracle statistics at length in the next section.
Tuning goals should be:
Specific – So everyone understands them and can agree whether or not they have been met.
Measurable - So you can determine when and if they are met.
For Online Transaction Processing (OLTP) applications, performance usually means optimizing throughput - the
amount of work accomplished by the system in a given peri od of time. For Decision Support (DSS) or Data
Warehouse (DW) applications, performance usually means minimizing response time - how long it takes for the
system to respond to a given user query.
The three main computer hardware resources to tune for good Oracle performance:
CPU
Disk I/O
Memory
Often you will face tuning trade-offs - situations where you may have to maximize perf ormance of one application or
program at the expense of some others, or where you may have to trade-off between better performance versus
increasing the hardware expenditures to get there.
Performance problems and the need for tuning present themselves at different points in the application lifecycle.
You may need to tune:
During application design
When configuring a new system or an upgrade to an existing system
After changes in workload
There are dependencies between these stages of lifecycle tuning. For example, the choices you make during
application design affect performance at other stages in the application lifecycle.
A basic principle in tuning is to change one aspect of the system at one time. Then test it and measure it. Then go
on to the next change. This iterative process of making one change at a time promotes safety and allows you to
know the exact impact of each change you make. If you change several things at once, you won't know the impact of
each change, and you could even make negative progress due to side-effects or unanticipated consequences of the
changes you made.
The most common tuning problems are:
Poorly-written application SQL
Inefficient SQL execution plans
Improperly size System Global Area (SGA) memory structures
Excessive file I/O
Waits for database resources
The entire IT organization must work together to resolve tuning problems. Each member fulfills a different role in the
tuning process:
Programmers and Developers - Tune their programs and their SQL.
Performance Tuning (IZ0-033)
Database Administrators - Tune Oracle itself, its configuration, memory settings, etc. May advise programmers
in their role.
System Administrators - Tune on the "platform level" (the operating system), configure hardware resources to
support all others in their roles.
Managers - Coordinate the process and roles among IT professionals.
Systems Analysts – Design Oracle databases that meet application needs and performance requirements, using
Oracle9I features to achieve this goal.
View: Usage:
View: Usage:
point to data corruption or database structural problems. Sites usually track ORA-0600 errors through Oracle
Enterprise Manager (OEM) event alerts or by writing scripts that process the Alert Log and notify them.
Trace Files
Oracle Trace Files contain textual information generated either by server processes or trace events. They may
originate from Oracle itself or be initiated by users. You are responsible for managing (periodically erasing) old trace
files from directories where they are written.
Set the init.ora parameter MAX_DUMP_FILE_SIZE to specify the maximum size a generated user trace file can be.
Set this value as K (kilobytes), M (megabytes), unlimited, or just as an unlabelled number (this specifies the maximum
size in terms of OS blocks).
TKPROF
To interpret user trace files, you must run the Oracle-provided command line utility called Trace Kernel Profile (or
TKPROF) against them. Example:
$ tkprof ora_1252.trc trace.txt
This processes user trace file ora_1252.trc and sends formatted output to file trace.txt. Now read the report in file
trace.txt to learn what you need to kn ow about the user's SQL.
Performance Tuning (IZ0-033)
You can optionally specify any of these TKPROF command line options (place them at the end of the command):
Option: Usage:
AGGREGATE Tells whether multiple exe cutions of the same SQL statement
are counted
The above parameter SORT offers you 22 different sort options. These can be applied in any of three phases of SQL
statement execution:
Parse - Parses SQL statement and readies it for execution.
Execute - SQL statement execution.
Fetch - When a row of a result set is r eturned to the user (a SQL FETCH operation).
To interpret TKPROF formatted output, remember these labels in the output report and their meanings:
Statistic Meaning:
Label:
Disk Total number of data blocks read during the three phases
Query Total number of rollback blocks read from the SGA during the
three phases
Current Total number of data blocks read from the SGA during the three
Performance Tuning (IZ0-033)
phases
In general, identify SQL statements that need tuning by seeing which ones consume a lot of CPU; take a long time in
Parse, Execute, or Fetch; read many data blocks from disk and few from the SGA; or access many data blocks but
return few rows.
UTLBSTAT/UTLESTAT
One way to collect and report Oracle performance statistics is via the Oracle-provided utility scripts, UTLBSTAT.SQL
and UTLESTAT.SQL. The B stands for "Begin collecting statistics," the E for "End collecting statistics." Here's how
to use these utilities:
1. Ensure the instance has been "up" long enough to allow the V$ views to b ecome populated with meaningful
statistics (at least 30 minutes)
2. Run UTLBSTAT.SQL to create temporary statistical tables and initially accumulate statistics into them
3. After at least 15 minutes has passed, run UTLESTAT.SQL to calculate metrics since the UTLBSTAT.SQL
script was run and to end the process. This also creates the file named REPORT.TXT in the user's current
directory.
4. Review the textual information in the REPORT.TXT file with any standard text editor. This contains the SQL
statements executed, and all sorts of performance statistics relating to them.
StatsPack
Statspack was introduced in Oracle8i Release 3 as an improved utility for reporting. It was designed to supercede the
older UTLBSTAT/UTLESTAT utilities. Here's how to use StatsPack:
1. Run the Oracle-provided script SPCREATE.SQL as user SYSDBA to create the PERFSTAT schema and all
its objects (tables, indexes, packages).
2. Change the default PERFSTAT schema password of PERFSTAT to something better. It is also
recommended to put the schema in its own tablespace.
3. Review the three log files created by SPCREATE.SQL to ensure it ran OK (SPCUSR.LIS, SPCTAB.LIS, and
SPCPKG.LIS). If anything went wrong, you can run the script SPDROP.SQL as user SYSDBA to clean up
and start over.
4. Run the procedure STATSPACK.SNAP two or more times as the user PERFSTAT to accumulate statistics.
Or, you may schedule this script to run automatically for you at intervals thro ugh script SPAUTO.SQL (this
uses DBMS_JOBS to schedule snapshot statistics data collection -- of course, to use DBMS_JOBS you must
have set the init.ora parameter JOB_QUEUE_PROCESSES to a non-zero value).
5. Run the procedure SPREPORT.SQL. Specify starting and ending points for the statistical period you want to
investigate. The report will be written to any file name you specify.
6. View the report with any text editor.
Tuning info you get from StatsPack includes SQL statements, which you can order by Gets, Reads, Executions, or
Parse Calls. There are thresholds SQL statements must meet or exceed in order to be included in the StatsPack
Performance Tuning (IZ0-033)
report. A SQL statement must have at least 10,000 Gets, 1,000 Reads, 100 Executions, or 1,000 Parse Calls to be
included in the StatsPack report.
The report output by StatsPack is much more clear and readable than that produced by UTLBSTAT/UTLESTAT. The
report provides lots of performance information both for SQL stat ements and the Oracle system as a whole. Note that
each execution of UTLBSTAT/UTLESTAT replaces the previous statistics; StatsPack keeps older statistics until you
delete them.
StatsPack and UTLBSTAT/UTLESTAT are two basic tools you use to collect the benchmark statistics referred to in the
first section "Performance Tuning Overview" in this CramSession. They are a more readable alternative than directly
querying the V$ tables and doing calculations using their data yourself.
Component: Usage:
Security Manager Create and manage user ids, privileges, and roles
Component: Usage:
Top Sessions Displays the sessions using the most resources (as you
define them).
Lock Monitor Identifies which users are locking resources, and what
kinds of locks are applied.
Top SQL Identifies which SQL statements are using the most
resources (as you define them).
Trace Data Viewer GUI for viewing trace file output (an alternative to
TKPROF)
Component: Usage:
Script: Usage:
Since output accumulates in the PLAN_TABLE, you might wish to truncate it befo re each SQL statement you analyze.
Or use the SET STATEMENT_ID= qualifier on the EXPLAIN PLAN FOR statement to identify outputs fr om separate
executions.
You can also read plan output by running either of the Oracle-provided scripts UTLXPLS.SQL or UTLXPLP.SQL to
write a formatted report.
Performance Tuning (IZ0-033)
The Optimizer
The optimizer is that component of Oracle that figures out how to access data for SQL statements (it creates the plan
or access path). Oracle’s two methods of optimization are:
Rule Based Optimizer (RBO) – Uses a set of “rules of thumb” to determine access paths. RBO is older and
considered more primitive.
Cost Based Optimizer (CBO) - Determines the most efficient data access paths by picking the data access
alternative that costs the least in terms of resources (disk I/O, CPU, etc.). This is the newer, recommended
approach.
The choice of optimizer (or optimizer mode) can be set at these levels:
Statement
Session
Instance
If set at more than one level, the order of precedence (highest to lowest) is in the order above (Statement setting
overrides Session setting which overrides Instance setting). If not set anywhere, the setting defaults to CBO if
statistics have been collected, or RBO if no statistics have been collected.
On SQL Statements, optimizer hints can be encoded to tell the optimizer what do to. Hints are coded with this syntax:
SELECT /*+ hint_goes_here */ ….
Oracle has over 40 hints. The optimizer mode hints include:
Hint: Usage:
Optimizer Statistics
CBO requires that you collect statistics on the data to create optimal plans. These stats are stored by Oracle in its
Data Dictionary or catalog. Statistics include such data as: the size of table or index, number of rows it contains, row
length, and cardinality (how many different values a column contains). Statistics can be collected at these levels:
table, index, schema, or the entire database. The main ways to gather statistics are:
The ANALYZE SQL command
The package DBMS_UTILITY.ANALYZE_SCHEMA
The package DBMS_STATS
Through the OEM Console
Copying statistics from one database to another
Clause: Usage:
FOR ALL INDEXES Gather stats for all indexes on the table (no table
stats)
Procedure: Usage:
Option: Usage:
Plan Stability
Whenever you perform an Oracle upgrade or change database configuration parameters, there is always t he
possibility that your actions will have the side-effect of changing existing program plans (access paths to data).
Plan Stability stores the preferred execution plan for a SQL statement in the data dictionary (as a stored outline). It
is a mechanism to avoid un-desired changes to plans. To use this feature, do the following:
1. All stored outlines use the OUTLN schema. Change the OUTLN default password, and give it its own def ault
and temporary tablespaces. Move its two tables OL$ and OL$HINTS out of the SYSTEM tablespace to
OUTLN's own tablespace.
2. Create stored outlines for the SQL you want to have plan stability by using the CREATE OR REPLACE
OUTLINE statement.
3. Activate stored outlines by setting the init.ora parameter USE_STORED_OUTINES=TRUE and restarting the
instance. Or you can dynamically activate this by running: ALTER SYSTEM SET
USE_STORED_OUTLINES=TRUE, or choose to activate it only for certain categories or groups of stored
outlines.
Manage outlines by the Oracle package OUTLN_PKG and the commands ALTER OUTLINE and DROP OUTLINE.
View stored outline info by querying the views DBA_OUTLINES and DBA_OUTLINE_HINTS.
To generate stored outlines for every statement, set the init.ora parameter CREATE_STORED_OUTLINES=TRUE.
Obviously this impacts performance.
9I also supports private outlines, outlines that reside in the user’s session and are only available to that user. Use
the CREATE PRIVATE OUTLINE statement to create private outlines. Activate private outlines in the session with
ALTER SESSION SET USE_P RIVATE_OUTLINES=TRUE, and de-activate them in the session by running this same
statement with the value of FALSE.
Performance Tuning (IZ0-033)
Materialized Views
Materialized views speed up queries by storing data in 1) pre-joined or 2) pre-calculated form. For pre-calculated form,
the calculations are typically those of the functions SUM, COUNT, MIN, MAX, or AVG. Materialized views do the "up
front" work so that queries run faster by not having to perform th is work in real time. This gives you the option to spe ed
up queries by doing some of the work at a more convenient time. Materialized views are a good tool for faster data
access when their use is well planned.
Use the CREATE MATERIALIZED VIEW statement with some of these keywords to create materialized views:
Keyword: Use:
Use the DBMS_MVIEW package to manually refresh materialized views. The procedures REFRESH,
REFRESH_DEPENDENT, and REFRESH_ALL_MVIEWS are used for manual refreshes.
Usually you’ll use Oracle’s automated refresh feature for convenience. Automatic refreshes are defined by creating
the materialized view with the ON COMMIT option or by scheduling the refresh with the DBMS_MVIEW and
DBMS_JOB packages.
Indexes
Indexes speed data access at the cost of the disk space required for their storage. Indexes can also slow down
updates (because the update must internally update the index as well as the table). The six kinds of Oracle indexes
are:
B-tree – Index stores keys (indexed data values) with the row ids where they are located in the database.
Compressed B-tree – saves storage space by not storing duplicate occurrences of the indexed column(s)
value.
Function-based – Applies a function to the index c olumn. Useful where the function is typically applied to the
value in the WHERE clause for retrieval.
Performance Tuning (IZ0-033)
Reverse-key – Useful when index column contains sequential numbers. It reverses the bytes in each column
that is indexed. Example key of 12345 becomes 54321.
Bitmap – Stores a binary mapping of row values called a bitmap. Differs from all other index types in that it
is best applied to low-cardinality data (data having few different values, for exam ple, GENDER is either M or
F). Best for data warehousing or other read-only applications because updating the bitmap is relatively slow.
Specify by the keywords CREATE BITMAP INDEX.
Index-Organized Tables (IOT) – Stores the row itself in the index (rath er than a row id that points to the row in
the data table). This avoids the extra I/O required to follow the row id and get the row from t he table, plus table
rows are stored in index order. Specify by the keyw ords ORGANIZATION INDEX on the CREATE TABLE
statement.
Partitions
Partitioning allows Oracle to store a very large table in multiple tablespaces. Query performance can be enhanced
because Oracle’s optimizer is smart and only searches partition(s) in which the desired row resides. The four kinds of
Oracle partitioning are:
Range – Partitions are defined as continuous ranges of data values. The highest range may be specified as
MAXVALUE (this ensures all values can be inserted somewhere in the table).
List – Partitions are defined by lists of values for each partition. The classic example of list partitioning is a table
that contains data divided by groupings of the 50 state codes.
Hash – Data is inserted and retrieved to and from partitions based on the application of a hash function.
Obviously, the hash function must provide consistent results when applied to the same value, so that that value
may be both inserted and then later retrieved.
Composite – Combines both range and hash partit ioning, so that you can use range partitioning but still get an
even number of values in each range. This option uses the syntax PARTITION BY RANGE… SUBPARTITION
BY HASH.
Clusters
Oracle supports two kinds of clusters: index and hash.
Index Clusters store data from one or more tables in the same physical blocks. Use them when:
The table data will always be retrieved together (not individually).
There will be little update activity after the initial data load.
There are roughly equal numbers of child records for each parent key.
Hash Clusters use a hashing algorithm to store and retrieve rows quickly without using an index. Use them when:
SQL statements will use equality matches on the indexed column in their WHERE clauses.
There will be little update activity after the initial load.
There is uniform distribution of values in the indexed column.
There will be a predictable number of values in the indexed co lumn.
To Improve Performance
Set the size of the Shared Pool via the init.ora parameter SHARED_POOL_SIZE. Set it dynamically like this:
ALTER SYSTEM SET SHAR ED_POOL_SIZE = 800M;
The value you set dynamically can not exceed the init.ora parameter SGA_MAX_SIZE. Oracle decides how to
allocate the memory among the SGA components (you do not set those values individually).
Since large PL/SQL packages can “hog” the Shared Pool, Oracle allows you to keep them in the Shared Pool
Reserved Area. Set the init.ora parm SHARED_POOL_RESERVED_SIZE to any value up to 50% of the size of the
SHARED_POOL_SIZE. By default it is 5%. Monitor view V$DB_OBJECT_CACHE to optimally size the Shared Pool
Reserved Area.
You can permanently keep (or pin) frequently-used packages and triggers in memory. Pinned packages are stored in
the Shared Pool Reserved Area space. Before you can pin anything, you must run the Oracle-supplied script
DBMSPOOL.SQL one time. Then, pin a package like this:
EXECUTE DBMS_SHARED_POOL.KEEP(‘package_name’);
You can make sure it got pinned by interrogati ng V$DB_OBJECT_CACHE. Pinning only lasts for the lifetime of the
instance. If you shutdown and startup Oracle, you must re-pin the package again by running the same statement.
You can make best use of the Library Cache by encouraging your developers to reuse code. Use coding standards to
ensure the common use of case, spacing, and lines in the application code SQL. Also have programmers use bind
variables (rather than hard-coded literal values), as in this example:
SELECT row_info FROM my_table WHERE row_key_value = :row_key;
Here, avoiding the hard-coding of the row_key_value means code reuse. The semi-colon denotes the bind variable.
You also affect statement sharing by the setting of the init.ora parameter CURSOR_SHARING:
Performance Tuning (IZ0-033)
CURSOR_SHARINGPa Usage:
rameter:
Oracle logically replaces literal values with bind variables in order to achieve cursor sharing for similar SQL
statements.
Component: Role:
Response Queue Shared server processes place the SQL result sets here.
There is one response queue for each dispatcher process
To tune SSO, you want to ensure that no user waits for either:
A dispatcher
A shared server process
Inspect V$QUEUE, V$DISPATCHER, and V$DISPATCHER_RATE to determine how busy the dispatchers are.
Increase the number of dispatchers by a statement like this:
ALTER SYSTEM SET DISPATCHERS = ‘tcp, 10’;
The number you specify is the total number you want (not how many more to add).
Dispatchers are specific for a communications protocol. Each Dispatcher serves only a single protocol!
Inspect Shared Server process performance by calculating the busy ratio from V$SHARED_SERVER and
V$SHARED_SERVER_MONITOR. High or increasing ratios mean you need to spawn more Shared Server
processes. Do so like this:
ALTER SYSTEM SET SHAR ED_SERVERS = 10 ;
The number you specify is the total number you want (not how many more to add).
Performance Tuning (IZ0-033)
The Dirty List or Write List is used to ensure Dirty buffers do eventually get written to disk.
The performance of the Database Buffer Cache is best measured by the hit ratio – how many reads Oracle satisfies
from the buffer rather than from real I/O. The hit ratio should be greater than 90% for good performance on OLTP
systems. View V$SYSSTAT for this information. (Or, of course, use UTLBSTAT/UTLESTAT, StatsPack, or the OEM
GUI for this purpose). Make the buffer bigger by increasing the init.ora parameter DB_CACHE_SIZE to increase the
hit ratio. You can increase it dynamically by running:
ALTER SYSTEM SET DB_CACHE_S IZE = n;
Get advice on the size of the buffer cache through 9I’s new Buffer Cache Advisory feature. Set the init.ora
parameter DB_CACHE_ADVICE=ON. Let Oracle collect statistics on its use for at least 30 minutes. Then inspect
view V$DB_CACHE_ADVICE to see what Oracle recommends.
Make better use of the database buffer by dividing it into up to three areas or pools:
Performance Tuning (IZ0-033)
Related Topics
As well as maximizing the database buffer hit ratio, you’ll also want to
minimize Free Buffer Waits and Buffer Busy Waits.
View the performance of Oracle’s Database Writer background process in
V$SYSTEM_EVENT and V$SYSSTAT. (Or, of course, use
UTLBSTAT/UTLESTAT, S tatsPack, or the OEM GUI for this purpose). To
tune Database Writer:
On computers that do not support asynchronous I/O, set the
init.ora parameter DBWR_IO_SLAVES to create slave processes to
simulate asynchronous I/O.
Or create up to 10 Database Writers by setting the init.ora parameter
DB_WRITER_PROCESSES . The default for this parm is 1 (one
Database Writer). If you specify this parm, you shou ld not specify
DBWR_IO_SLAVES.
In Oracle, caching a table in memory means that its buffers are not placed
on the least recently used end of the LRU list when they are accessed via a
full table scan. Instead they are placed on the most recently used end so
they’ll tend to remain in the cache longer. Cache a table in memory by
creating it with the CACHE keyword on the CREATE TABLE statement. Or
run:
ALTER TABLE my_table CACHE;
Performance Tuning (IZ0-033)
Use Locally Managed Tablespaces (LMT). These use bitmaps in datafile headers to manage space rather
than free lists in the Data Dictionary. This is faster and more efficient because Oracle does not have to access
the Data Dictionary so much just to manage space in the tablespaces. LMTs are recommended for all new
tablespaces you create. Specify their use on the CREATE TABLESPACE statement.
Set the init.ora parameter DB_FILE_MULTIBLOCK_READ_COUNT to something bigger than its default value
of 8. This determines how many database blocks a Server Process reads in one I/O operation during full table
scans. High values are especially warranted for read-only or data warehouse applications. Monitor full table
scan activity and impact by V$SESSION_LONGOPS.
Raw devices (aka – also known as - asynchronous devices) give Oracle direct I/O authority, leaving out
the operating system’s file system drivers. This traditionally was much faster than the alternative, file system
I/O (aka cooked devices or synchronous I/O), though on modern systems the difference may be negligib le.
Ensure you have defined at least the minimum recommended tablespaces: SYSTEM, TOOLS, USERS, TEMP,
RBS, APPL_DATA, and APPL_IDX.
Use Automatic Undo Management (AUM) and let Oracle manage rollbacks. Recall that rollback segments
contain before-change images. Just set the init.ora parameter UNDO_MANAGEMENT=AUTO and specify an
UNDO_TABLESPACE. You can also specify UNDO_RETENTION=seconds_value to tell how long to keep
rollback information after transactions commit. Increasing this value can eliminate “SNAPSHOT TOO OLD”
errors. Its default is 900 sec onds. Monitor the Undo Tablespace by viewing DBA_TABLESPACE and
V$UNDOSTAT.
Use Oracle Flexible Architecture (OFA) in laying out the datafiles on the Oracle disks. This ensures better
performance by spreading out I/O across disks.
Minimize non-database I/O on the server (do not share the database server with other non-database activities,
for example, by using it as a file server or as another kind of server as well).
PGA_AGGREGATE_TARGE T and WORKAREA_SIZE_POLICY are new in 9i. The former defaults to 0. If you
specify it, then you must set WORKAREA_SIZE_POLICY=AUTO.
The type of access a lock needs is called its lock mode. Lock modes for DML locks, for example, are Row Exclusive
(RX), Table Row Share (RS), Share (S), Share Row Exclusive (SRX), and Exclusive (X).
To monitor locks, first run the Oracle-supplied script CATBLOCK.SQL one time to create Data Dictionary views
DBA_BLOCKERS and DBA_WAITERS. Those two views show processes that are blocking others, or are waiting for
locks (respectively). Views V$LOCK and V$LOCKED_OBJECT also to monitor locks and locked objects. The
easiest way to monitor locks is simply to use the OEM GUI tool, the Lock Monitor.
To kill off a process holding a lock: get its SID and SERIAL# from V$SESSION.
Then issue: ALTER SYSTEM KILL SESSION ‘s id,serial#’ ;
To minimize contention, code applications that:
Contain only short transactions (frequently issue COMMIT or ROLLBACK to end transactions)
Do not explicitly request table-level locks (i.e., do not issue the sta tement
LOCK TABLE IN EXCLUSIVE MODE )
Write efficient SQL
A deadlock occurs when two processes each hold an exclusive lock on a resource the other requires, and refuses to
give it up. Oracle automatically identifies deadlocks and resolves them by rolling back one of the transactions (killing
it and releasing its lock so that the other transaction can complete). Oracle writes a trace file to the
USER_DUMP_DEST directory with the details. The way to minimize deadlocks is to ensure that all applications
process resources in the same order.
Example: If two programs both process rows 17, 188944, and 3000, they should process those rows in the same
order. If they process tables A, B, and C, they should both process those tables in the same order.
Oracle manages locks by a queuing mechanism called an enqueue. The default number of enqueues is derived by
Oracle from the init.ora parameter SESSIONS. Or manually encode the init.ora parameter
ENQUEUE_RESOURCES=.
Performance Tuning (IZ0-033)
Latches
A latch is a special kind of lock Oracle uses internally to control access to its memory structures, or to serialize its
execution. Latches can be either:
Willing to Wait – The process will wait for the latch and re-try
Immediate – The process continues with other work if the latch is not immediately available
Monitor latches through view V$LATCH. Overall latch behavior can be seen through V$SYSTEM_EVENT, via
StatsPack, via UTLBSTAT/UTLESTAT, or via OEM Perfor mance Manager. DBAs do not tune latc hes. Latch waits
indicate some other problem (e.g., insufficient space in the SGA), so you tune those “root causes” instead.
You can define multiple resource plans; however, only one resource plan can be active for the instance at one time.
To set the instance’s resource plan dynamically, run:
ALTER SYSTEM SET RESOURCE_ MANAGER_PLAN = plan_name ;
Automatic consumer group switching means that a user can be automatically switched to a secondary resource
group. This is set up and controlled by three resource plan directive parameters:
SWITCH_TIME – How long a session must be active before RM switches the session to the group named in
SWITCH_GROUP. Default time is 1,000,000 seconds.
SWITCH_ESTIMATE – If TRUE, RM uses the estimated execution time to decide whether to assign the session
to the SWITCH_GROUP before execution begins. Default is FALSE.
SWITCH_GROUP – Group the user is switched to.
Remember that SWITCH_ESTIMATE must be set to TRUE for automatic consumer group switching to occur.
Monitor the RM through dynamic performance views V$SESSION, V$RSRC_CONSUMER_GROUP , and
V$RSRC_PLAN.
Also of interest: DBA_RSRC_CONSUMER_GROUPS, DBA_RSRC_CONSUMER_GROUPS_PRIVS,
DBA_RSRC_PLANS, DBA_RSRC_PLAN_DIRECTIVES, DBA_RSRC_MANAGER_SYSTEM_PRIVS, and
DBA_USERS. Or better yet, take the easy way out and use the GUI provided by the Resource Manager OEM tool.