Monitoring and Improving Performance

Monitoring and Improving Performance
Copyright © 2005, Oracle. All rights reserved.

Objectives
After completing this lesson you should be able to do

the following:
• Troubleshoot invalid and unusable objects
• Gather optimizer statistics
• View performance metrics
• React to performance issues
13-2 Copyright © 2005, Oracle. All rights reserved.
Oracle Database 10g: Administration Workshop I 13-2

Performance Monitoring
Memory
Memory
allocation
allocation
issues
issues
Input/output
Input/output Resource
Resource
device
device contention
contention
contention
contention
?
Application
DBA Network
Application Network
code bottlenecks
bottlenecks
code
problems
problems
Performance Monitoring
To administer Oracle Database 10g and keep it running smoothly, the database
administrator must regularly monitor performance to locate bottlenecks and correct
problem areas.
There are hundreds of performance measurements the DBA can look at, covering
everything from network performance to disk input/output speed to the time spent
working on individual application operations. These performance measurements are
commonly referred to as database metrics.

Monitoring Methodologies
• Reactive
• Proactive
– Server-generated alerts
– Automated Database Diagnostic Monitor (ADDM)
Monitoring Methodologies
The Oracle Database 10g supports both proactive and reactive monitoring. Reactive
monitoring is a response to a known or reported problem. You may begin monitoring
performance metrics in reaction to user complaints about response time, instance
failures, or errors found in the alert log.
Reactive monitoring is inevitably necessary sometimes, but your goal should be to
detect and repair problems before they affect system operation. Fixing problems before
they occur, or at least before they are widely noticed, is a proactive approach to system
maintenance.
Oracle Database 10g includes several tools that aid in proactive monitoring. Two of
these are server-generated alerts and the Automated Database Diagnostic Monitor
(ADDM). Proactive monitoring will be covered in the next lesson.

Database and Instance Metrics
Several hundred different performance statistics are

available through:
• Data dictionary
• Dynamic performance views
• Optimizer statistics
DBA
Database and Instance Metrics

There are hundreds of different measurement points available to monitor your system.
The data dictionary provides information about space consumption and object status.
Real-time performance metrics covering memory usage, wait events, input/output
device throughput, and instance activity are available through dynamic performance
views, also known as v$ views.
Oracle Databases can be extremely large (terabyte databases are becoming common and
exabyte databases are possible). With such large datasets it is critical that the instance
locate the particular piece of data a user is looking for in the most efficient way
possible. The portion of the instance that decides how to look for data is known as the
optimizer.
Data distribution metrics are used to help the Oracle Database 10g optimizer choose the
most efficient way to retrieve data, and are therefore commonly referred to as
“optimizer statistics.”

Database and Instance Metrics (continued)
Optimizer statistics showing data distribution for each table include:
• Number of rows
• Average row length
• Amount of empty space that is allocated to the table
• Number of rows that are “chained” (existing in two or more data blocks due to
long row length or inefficient data storage settings)
One example of an optimizer choice is between a full table scan (reading the entire table
to find a particular row) and an index scan (looking for the row in an index first, then
going directly to the data block in the table that holds the row). For small tables, a full
table scan is usually more efficient than looking through an index for data and later
jumping to the correct block. For a large table (remember that large can easily be
hundreds of millions of rows) an index scan probably makes much more sense.

Data Dictionary Metrics
Object status:
• PL/SQL code objects
• Indexes
Data Dictionary Metrics

One of the most important data dictionary metrics deals with object status. Database
indexes and stored procedures both need to be VALID to be used.
Indexes can become UNUSABLE due to normal maintenance operations on tables.
Indexes contain pointers to the physical location of individual rows of data. If the DBA
causes those rows to change location through maintenance operations such as the MOVE
command, the pointers are no longer valid and the index will not be usable until it is
rebuilt.
PL/SQL code objects have an INVALID status for several reasons. If the code contains
a programming error, the PL/SQL object will not compile correctly and will be marked
invalid. A valid procedure can become invalid if an object the procedure references
changes. Suppose a procedure references the salary column of the employees
table. If the column precision is changed, or if the column is dropped, there is no
guarantee that the procedure that worked correctly on the old table definition will still
run on the new table definition.
Unusable indexes always require DBA intervention to restore them to a valid state.
Invalid PL/SQL objects will normally recompile automatically the first time they are
called, but sometimes require DBA intervention in cases where the automatic
recompilation fails.
Invalid and Unusable Objects
• PL/SQL code objects are recompiled.

• Indexes are rebuilt.
Invalid and Unusable Objects

If you find PL/SQL objects with a status of INVALID, the first question you need to
answer is “has this object ever been VALID?” Often, an application developer neglects
to clean up code that does not work. If the PL/SQL object is invalid because of a code
error, then there is little that can be done until that error is fixed. If the procedure was
valid at some time in the past and has recently become invalid, you have two options to
fix the problem:
1. Do nothing. Most PL/SQL objects will automatically recompile if needed when
they are called. Users will experience a slight delay while the objects recompile
(in most cases this delay is not even noticeable).
2. Manually recompile the invalid object.
Invalid PL/SQL objects can be manually recompiled using Enterprise Manager or
through SQL commands:
ALTER PROCEDURE HR.add_job_history COMPILE;
Manually recompiling PL/SQL packages requires two steps:
ALTER PACKATE HR.maintainemp COMPILE;
ALTER PACKATE HR.maintainemp COMPILE BODY;

Invalid and Unusable Objects (continued)
Unusable indexes are made valid by rebuilding them to recalculate the pointers.
Rebuilding an unusable index re-creates the index in a new location, then drops the
unusable index. This can either be done using Enterprise Manager or through SQL
commands.
ALTER INDEX HR.emp_empid_pk REBUILD;
ALTER INDEX HR.emp_empid_pk REBUILD ONLINE;
ALTER INDEX HR.email REBUILD TABLESPACE USERS;
If the TABLESPACE clause is left out, the index is rebuilt in the same tablespace where
it already exists. The REBUILD ONLINE clause allows users to continue updating the
index’s table while the rebuild takes place (without the ONLINE keyword users must
wait for the rebuild to finish before performing DML on the affected table).
Enterprise Manager uses the Reorganize action to repair an UNUSABLE index.

Note: Rebuilding an index requires that free space be available for the rebuild. Verify
that there is sufficient space before attempting the rebuild. Enterprise Manager checks
space requirements automatically.
Optimizer Statistics
Optimizer statistics are:

• Not real-time
• Persistent across instance restarts
• Collected automatically
SQL> SELECT COUNT(*) FROM hr.employees;
COUNT(*)
----------
214
SQL> SELECT num_rows FROM dba_tables
2 WHERE owner='HR' AND table_name = 'EMPLOYEES';
NUM_ROWS
----------
107
Optimizer Statistics
Optimizer statistics for tables and indexes are stored in the data dictionary. These
statistics are not intended to provide real-time data. They provide the optimizer a
statistically correct snapshot of data storage and distribution which the optimizer uses to
make decisions on how to access data.
Metrics collected include:
• Size of the table or index in database blocks
• Number of rows
• Average row size and chain count (tables only)
• Height and number of deleted leaf rows (indexes only)
As data is inserted, deleted, and modified these facts change. The performance impact
of maintaining real-time data distribution statistics would be prohibitive, so these
statistics are updated by periodically gathering statistics on tables and indexes.
Optimizer statistics are collected automatically by the pre-configured
GATHER_STATS_JOB, which runs during predefined maintenance windows, once per
day.

Optimizer Statistics (continued)
A large table that experiences 10 percent growth (or reduction) within a 24-hour period
is usually considered too volatile for statistics collection once per day to be sufficient.
For tables that experience this level of change, Oracle recommends collecting statistics
more frequently, preferably often enough that the table never changes by more than
about 10 percent between collection periods. This requires manual statistics collection.
Statistics can be manually collected using Enterprise Manager, or through the use of the
DBMS_STATS package as shown below:
SQL> EXEC
dbms_stats.gather_table_stats(‘HR’,’EMPLOYEES’);
SQL> SELECT num_rows FROM dba_tables
2 WHERE owner='HR' AND table_name = 'EMPLOYEES';
NUM_ROWS
----------
214
Note that the number of rows now correctly reflects what was in the table as of the time
statistics were gathered. DBMS_STATS also allows manual collection of statistics for an
entire schema, or even the whole database.

Manage Optimizer Statistics Page
Manage Optimizer Statistics Page

Go to Enterprise Manager’s page for managing optimizer statistics by clicking Manage
Optimizer Statistics on the Administration tab. Note that, as this page shows, the
GATHER_STATS_JOB is enabled, has run nine times, and the last time it successfully
ran against 97 objects, and that took a little over a minute.
From this page you can perform the following tasks on statistics:
• Gather Optimizer Statistics manually. This action submits the gather job that the
GATHER_STATS_JOB automatically does. This should be done in the case
where a table's content has changed so much between automatic gathering jobs
that the statistics no longer represent the table accurately. Examples of this are
where a table is truncated in the middle of the day, or a batch job runs that adds
large amounts of data to a table.
• Restore Optimizer Statistics to a point in the past. The point in time chosen must
be within the optimizer statistics retention period, which defaults to 30 days.
• Lock Optimizer Statistics to guarantee that, for certain objects, their statistics are
never overwritten. This is useful if statistics have been calculated for a certain
table at a time when well representative data was present, and you desire to always
have those statistics. No fluctuation in the table will affect the statistics if they are
locked.
• Unlock Optimizer Statistics to undo the previously done lock.
• Delete Optimizer Statistics to delete statistics.
Manually Gathering Optimizer Statistics
Gathering Optimizer Statistics

Enterprise Manager’s Gather Statistics Wizard (available from the Maintenance page) is
the recommended way to manually collect or update optimizer statistics. The wizard
prompts for information and then creates a job to collect statistics.:
1. Scope: Choose the scope for collecting statistics from among: database, schema,
tables, indexes, fixed objects, or dictionary objects.
2. Object selection: Choose the objects to gather statistics for. You can select
individual tables or indexes or select everything in the chosen schema.
3. Schedule: Provides host credentials and determines when the statistics will be
collected. Choices include immediately, a scheduled time, or a named
maintenance window.
4. Review: Shows the code generated by the wizard and allows you to submit the
job.

Dynamic Performance Views
Dynamic Performance views are:

• Real-time
• Non-persistent across instance restarts
SQL> SELECT name, value FROM v$sysstat
2 WHERE name='sorts (memory)' ORDER BY name;
NAME VALUE
--------------- ----------
sorts (memory) 1979183
SQL> /
NAME VALUE
--------------- ----------
sorts (memory) 1979184
Dynamic Performance Views

There are over 300 dynamic performance views in the Oracle Database 10g that provide
detailed information on session and system statistics, file I/O, and instance activity.
Dynamic performance views provide a snapshot of real-time data. As you can see from
the example above, each access of a dynamic performance view gives up-to-date
results. For the statistic shown above, the act of selecting the information with the
ORDER BY clause caused sorts (memory) to increment.
Dynamic performance data is also nonpersistent. After the instance is shut down, the
views reset and begin counting up again. That means that performance data obtained
from dynamic performance views should not be used to make configuration decisions
until the instance has been operational for a while.
Dynamic performance metrics are usually not meaningful as a single measurement.
They should be considered in the context of performance trends (increasing, decreasing)
or against baseline data.
For more information on dynamic performance views, refer to Oracle Database:
Reference.

Viewing Metric Information
• Use the All Metrics link in

the Related Links region.
• Drill-down for in-depth
analysis.
Viewing Performance Information

Enterprise Manager’s All Metrics page groups metrics by functional area.
1. Expand the area of interest.
2. Click the link for the metric you want to view.
The metric detail page displays:
• Last known value
• High- and low- water mark values
• Average readings
• Graphical representation of the metric plotted over a user-defined time period

Reacting to Performance Issues
Use Enterprise Manager to:

• Find key performance issues
• Drill down to the root cause

Enterprise Manager’s Performance page is the best place to start if you notice a
degradation in system performance. The Performance page is divided into four main
regions:
• Host CPU: The CPU load on the machine, system wide.
• Active Sessions: Metrics about all active sessions including CPU. I/O activity, and
concurrency, among others.
• Instance Disk I/O: I/O activity for the entire instance.
• Instance Throughput: For the instance, transactions, logons, redo size, and
physical reads.
Each of these sections can be drilled into by clicking the metric of interest.

Drill down into performance measurements to identify

bottlenecks
• CPU user: a specific update statement
Reacting to Performance Issues (continued)

Drilling down into the CPU used reveals that there is an update statement that is using
most of the CPU at a specific time. You can further click on that SQL ID and see the
explain plan and tuning information for that single statement.

Tuning Tips
Considerations:
• There are some general guidelines that serve as a
starting point in performance tuning
• Your situation may not fit the guideline
• Test any changes under a representative
production environment to see the affects
• There are written volumes and multi-day classes
dedicated to tuning an Oracle database
Tuning Tips
The guidelines that follow are simply that. This is not an attempt to list tuning
parameters that will fix every system's performance problems, but there are some
starting point to consider. As you work with these tips, investigate further in the Oracle
documentation and other resources, and test them on your system, you will be able gain
better understanding of how to tune your database, with your applications, with your
workload, in your environment.

Tuning Activities
The three activities in performance management are:

• Performance planning
• Instance tuning
• SQL tuning
Tuning Tips
The three facets of tuning involve performance planning, instance tuning, and SQL
tuning. Performance planning is the process of establishing the environment: the
hardware, software, operating system, network infrastructure, and so on. Instance tuning
is the actual adjustment of Oracle and operating system parameters to gain better
performance of the Oracle database. SQL tuning involves making your application
submit efficient SQL. This is an application-wide consideration, as well as a statement-
specific one. System-wide, you want to be sure different parts of the application are
leveraging each other's work, and are not competing for resources unnecessarily. We'll
also look at some common actions to take to tune specific SQL statements.
Note: For more information about performance tuning, please refer to the Oracle
Database Performance Tuning Guide.

Performance Planning
• Investment Options
• System Architecture
• Scalability
• Application Design Principles
• Workload Testing, Modeling, and Implementation
• Deploying New Applications
Performance Planning
There are many facets to performance planning. You have to consider the investment in
your system architecture: the hardware and software infrastructure needed to meet your
requirements. The number of hard drives and controllers has an impact on speed of data
access. Striping data across many devices is often a way to make performance gains.
This, of course, requires analysis to determine the value for your given environment,
application, and performance requirements.
The ability of an application to scale is also important. This means you are able to
handle more and more users, clients, session, or transactions, without incurring a huge
impact on overall system performance. The most obvious violator against scalability is
serializing operations among users. If all users have to go through a single path one at a
time, then as more users are added, there will definitely be adverse affects on
performance, as more and more users line up to go through that path. Poorly written
SQL also affects scalability, requiring many users to wait for inefficient SQL to
complete, each one competing with the other on a large number of resources they should
not actually be in need of.
Principles of application design can greatly affect performance. Simplicity of design,
use of views and indexes, and data modeling are all very important.
Performance Planning (continued)
Any application needs to be tested under a representative production workload. This
requires estimating database size and workload, and generating test data and system
load.
Performance must be considered as new applications, or new versions of applications,
are deployed. Sometimes design decisions are made to maintain compatibility to old
systems during the rollout. A new database should be configured specifically for the
applications it is hosting, based on the production environment.

Instance Tuning
• Have well-defined goals

• Allocate memory to database structures
• Consider I/O requirements in each part of the
database
• Tune the operating system for optimal
performance of the database
Instance Tuning
At the start of any tuning activity it is necessary to have specific goals. A goal such as
"Process 500 sales transactions per minute" is easier to work toward than one that says
"Make it go as fast as you can, and we'll know when it's good enough."
You have to allocate Oracle memory suitably for your application to attain optimum
performance. You have a finite amount of memory to work with, and too little allotted
to certain parts of the Oracle database can cause inefficient background activity that you
may not even be aware of without doing some analysis.
Disk I/O is often the bottleneck of a database, and so requires a lot of attention at the
outset of any database implementation.
The operating system configuration can also affect the performance of an Oracle
database. See the Oracle Database Installation Guide for your particular platform for
more information.

Tuning Memory Allocation
SGA
Database
buffer cache
Streams pool Redo log
buffer
Shared pool
Large pool Fixed SGA
Java pool
SGA_TARGET = 8G
What is the optimal allocation?
STATISTICS_LEVEL = TYPICAL

The System Global Area (SGA) is internally divided into memory components. A
component represents a pool of memory that is used to satisfy a particular class of
memory allocation requests.
The most commonly configured memory components include the database buffer cache,
shared pool, large pool, and Java pool. You can manually specify sizes for these
components, but the recommended method is to use Automatic Shared Memory
Management. This feature enables the Oracle Database to automatically determine the
size of each of these memory components within the limits of the total SGA size. Set
SGA_TARGET to the amount of memory you want to dedicate to the SGA. Also,
STATISTICS_LEVEL should be set to either TYPICAL or ALL.
The auto–tuned SGA parameters DB_CACHE_SIZE, SHARED_POOL_SIZE,
LARGE_POOL_SIZE, JAVA_POOL_SIZE and STREAMS_POOL_SIZE have
default values of zero when SGA_TARGET is set to a nonzero value. These components
are automatically sized by the Automatic Shared Memory Management algorithm. If
one of these specific memory component variables is set to a non-zero value while
SGA_TARGET is also set, then that value is considered to be the minimum amount of
memory that SGA component could be sized to. It can be larger than that, though.
Tuning Memory Allocation (continued)
The manual SGA size parameters are:
• DB_KEEP_CACHE_SIZE
• DB_RECYCLE_CACHE_SIZE
• DB_nK_CACHE_SIZE (n = 2, 4, 8, 16, 32)
• LOG_BUFFER
• STREAMS_POOL_SIZE (In Oracle Database 10g Release 1, this parameter was
manually set. In Oracle Database 10g Release 2, this parameter can be auto–
tuned.)
Manual SGA parameters are specified by the user, and the given sizes precisely control
the sizes of their corresponding components.
When SGA_TARGET is set, the total size of manual SGA size parameters is subtracted
from the SGA_TARGET value, and balance is given to the auto–tuned SGA components.
For example, if SGA_TARGET = 8G and DB_KEEP_CACHE_SIZE = 1G, the total size
of the four auto–tuned components (shared pool, Java pool, default buffer cache, and
large pool) is limited to 7 GB. The 7 GB include the fixed SGA and log buffer, and only
after those have been allocated is the rest of the memory divided between the
components. The size of the keep cache is 1 GB, as specified by the parameter.

Memory Tuning Guidelines
• Try to fit the SGA into physical memory

• Consider the buffer cache hit ratio, with caveats:
– Even valid and necessary full table scans lower it
– It is possible that unnecessary repeated reads of
the same blocks are artificially raising it
• Use the Memory Advisor

If possible, it is best to fit the SGA into physical memory, which provides the fastest
access. Even though the operating system may provide additional virtual memory, that
memory, by it's nature, can often be swapped out to disk.
The size of the database buffer cache can greatly influence the buffer cache hit ratio,
since it holds the data blocks in memory. This ratio is the percentage of times, when
Oracle requests a block, that it finds it already in memory versus having to perform a
physical I/O to get it from disk. So, a higher ratio is good; the blocks are frequently
found in memory.
It is not uncommon to have a buffer cache hit ratio above 99%. But that does not always
mean the system is well-tuned. If there is a query that is executed more often than
necessary, and is constantly requesting the same blocks over and over, that will raise the
ratio. If it is an inefficient or unnecessary query, then it is artificially inflating the ratio,
since it should not be executing in that manner, or that often in the first place.
Also, consider the fact that large full table scans, a full reading of the entire table from
disk, lowers this ratio, because the entire table is always read from disk; it does not take
advantage of the fact that some of the blocks may be in the buffer cache. So, if there are
some necessary full table scans in your application, your well-tuned database may
always have a low database
Oracle buffer10g:
Database cache hit ratio.
Administration Workshop I 13-25
Use Enterprise Manager's Memory Advisor, which was covered in Lesson 12. This can
help you size the SGA based on activity in your particular database.

Memory Tuning Guidelines
for the Library Cache
• Eliminate unnecessary duplicate SQL

• Establish formatting conventions for developers
so that SQL statements match in the cache
• Use PL/SQL when possible
• Use bind variables
• Cache sequence numbers
• Consider using CURSOR_SHARING

The library cache is where Oracle stores all the SQL, PL/SQL, and Java code that gets
executed. It goes into this central location so it can be shared among all users. The
values in sharing is that all users can take advantage of any work already done on behalf
of the SQL. Therefore, tasks such as parsing the statement and determining the data
access path, also known as the explain plan, are done only once per statement, no matter
how many times it is executed, and no matter how many users execute it. A library
cache that is too small will not have room for all the statements being executed, and thus
you will not be able to take advantage of this sharing of work for some statements. A
library cache that is too large will cause a burden on the system just to manage its
contents.
A library cache may end up being filled with what appear to be different statements,
when in fact they are copies of the same statement. A common cause of this is having
slightly different formatting for each statement. There is no match if the string does not
compare exactly. Another cause is the use of literals instead of bind variables. If the
only difference between two statements is literal values, then in most cases each of
those statement executions and the overall system would benefit from replacing those
literals with bind variables.
The init.ora variable CURSOR_SHARING can be set to have the system automatically
replace literals with bind variables when statements otherwise match. You should
typically take advantage of this setting as a temporary measure, until the application is
corrected to use bind variables where appropriate. As with all of these guidelines, usage
of this variable can have other side affects which you should investigate.
Rather than having the same SQL statement issued from several different places in an
application, put the statement or statements into a stored procedure, using PL/SQL.
Then just call the procedure. This guarantees the SQL will be shared, since only exists
in one location. Also, the SQL is already parsed and has an explain plan, since it is in an
already compiled stored procedure.
Sequence numbers can be cached, so if there are some with high activity, determine a
good setting for the cache size, and take advantage of it.

Tuning I/O
• Look for hot spots on disk

• Ensure you have right-sized redo log files
• Consider moving redo logs to separate disks
• Consider moving archive logs to separate disks
• Look for a high I/O rate on the TEMP tablespace
• Reduce contention for high I/O datafiles by
segregating them
• Consider striping all data across all disks
• Consider using Automatic Storage Management
Tuning I/O
A common cause of hot spots on a disk comes from insert-heavy applications, where
there is an index with keys that are very close in value to each other as they are inserted.
Examples of this are dates and sequences, or values that are based on some combination
of those. In these cases, all of the write activity for the index is in the same area of disk
because the key values are close, and get put in the same area of the index structure.
This can often be resolved by using a reverse key index, which reverses the bytes of the
index, causing the storage location in the index to be very different even for integers that
are one value apart.
If your log files are not large enough to handle the redo generated by the database, then
it's possible the system is frequently waiting for a switch to a new redo log. When one
fills, a different one must be activated. During that change in active log file, nothing can
be written to the redo log. If this happens too often, it could be affecting performance. A
typical goal for the redo log switch interval is roughly 20 minutes.
If you segregate redo log files and/or archived redo log files onto separate disks, this
may relieve I/O contention.

Tuning I/O (continued)
You may want to simply stripe all data across all available disks. This is referred to as
Stripe And Mirror Everything (SAME). This is a major underlying principle of
Automatic Storage Management (ASM). ASM provides striping, mirroring, and a
simplified interface for administering a large number of disks.
If you have high I/O rates on TEMP tablespace, that may mean there is excessive
sorting going on. Check on the SQL that is causing the sorting to ensure it needs to be
done.

Tuning SQL
• SQL Tuning Advisor

• The Query Optimizer
• Using Indexes and Clusters
• Using Optimizer Hints
• Using EXPLAIN PLAN
Tuning SQL
The SQL Tuning Advisor analyzes individual SQL statements and makes
recommendations for improving their performance.
The Query Optimizer analyzes each SQL statement and determines the most efficient
path to the data. This involves, among other things, determining what index to use, or
even if it is worthwhile to use an index.
Using an index is probably the most common solution to quickly accessing data in a
table. As described in Lesson 6, in their most basic form, indexes store key values
paired with pointers to data rows. This usually enables faster access to the data row,
because indexes are smaller and can be read through much more quickly than large
tables. They are also organized in a way that enables very fast key lookup. So, queries
that search a large table for a key value benefit greatly from an index. It is the Query
Optimizer's job to determine whether the index should be used though. If an index is not
being used, there may very well be a good reason for it.

Tuning SQL (continued)
Clusters allow multiple tables to share the same database blocks. If two tables that are
frequently accessed together are stored in the same cluster based on a common key, such
as a join key, then when those two tables are joined in a query, both tables' row data will
be found in the same data block, resulting is much faster query execution. The main
consideration when using clusters, though, is the fact that when a query is run that
accesses just one of those tables, there could be more I/O required, since there are fewer
of that table's rows in each block. This is because there must be room for two tables'
rows in each block.
Optimizer hints allow a developer to suggest to the Query Optimizer what plan to
consider. If for some reason the optimizer is not deciding on the ideal plan, and the
developer has a better idea, a hint can be used to influence the optimizer. Examples of
this are if an index is not being used that should be, or maybe a full table scan would be
more efficient than using an index. Note that the Query Optimizer does not always
decide in favor of the hint. A hint is placed in the SQL statement as a specially-
formatted comment. For example, this statement uses a hint to tell the optimizer to
consider doing a full table scan:
SELECT /*+ FULL(e) */ * FROM employees e
WHERE salary < 10000;
You can use the Explain Plan to find out what access path the Optimizer will decide
upon for a given SQL statement. You can either use the SQL*Plus EXPLAIN PLAN
command, or Enterprise Manager to see the plan for a statement.

Tuning Recommendations
Tuning Recommendations
The SQL Tuning Advisor is able to provide recommendations for improving the
performance of a SQL statement. In this example, where a statement was searching on
the OBJECT_ID column, it is noted that an index on that column may help.

The Recommendation Plan
The Recommendation Plan

It is possible to see the plan that would be used were the recommendation implemented.
This allows you to do "what if" analysis. In this example, the cost of the statement to
execute is lowered six fold.

SQL Statistics
select count(*) from x select count(*) from x

where object_id < 340 where object_id < 220
Each statement caused a hard parse
SQL Statistics
The SQL Tuning Advisor also shows you the statistics a cursor that represents an SQL
statement. By viewing statistics for each of these two cursors, you can see that each of
them cause a hard parse of the statement. This means the statement was not found to be
a match in the Library Cache. This is because of the use of literals instead of bind
variables.

Identifying Duplicate SQL
Bind variable
candidates
Identifying Duplicate SQL

Duplicate SQL can be identified by clicking Duplicate SQL on the Performance tab.
SQL that is determined to be duplicate expect for formatting or literal differences is
listed together. This helps you determine the SQL in your application can be
consolidated, thus lowering the requirements on the Library Cache, and speeding up
execution of the statement.

Summary
In this lesson you should have learned how to:

• Troubleshoot invalid and unusable objects
• Gather optimizer statistics
• View performance metrics
• React to performance issues
• Understand some basic tuning steps to take

Monitoring and Improving Performance

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Monitoring and Improving Performance

Uploaded by

Copyright:

Available Formats

Monitoring and Improving Performance

Copyright © 2005, Oracle. All rights reserved.

After completing this lesson you should be able to do

13-2 Copyright © 2005, Oracle. All rights reserved.

Oracle Database 10g: Administration Workshop I 13-2

13-3 Copyright © 2005, Oracle. All rights reserved.

Oracle Database 10g: Administration Workshop I 13-3

13-4 Copyright © 2005, Oracle. All rights reserved.

Oracle Database 10g: Administration Workshop I 13-4

Several hundred different performance statistics are

13-5 Copyright © 2005, Oracle. All rights reserved.

Database and Instance Metrics

Oracle Database 10g: Administration Workshop I 13-5

Oracle Database 10g: Administration Workshop I 13-6

13-7 Copyright © 2005, Oracle. All rights reserved.

Data Dictionary Metrics

• PL/SQL code objects are recompiled.

13-8 Copyright © 2005, Oracle. All rights reserved.

Invalid and Unusable Objects

Oracle Database 10g: Administration Workshop I 13-8

Enterprise Manager uses the Reorganize action to repair an UNUSABLE index.

Optimizer statistics are:

13-10 Copyright © 2005, Oracle. All rights reserved.

Oracle Database 10g: Administration Workshop I 13-10

Oracle Database 10g: Administration Workshop I 13-11

13-12 Copyright © 2005, Oracle. All rights reserved.

Manage Optimizer Statistics Page

13-13 Copyright © 2005, Oracle. All rights reserved.

Gathering Optimizer Statistics

Oracle Database 10g: Administration Workshop I 13-13

Dynamic Performance views are:

13-14 Copyright © 2005, Oracle. All rights reserved.

Dynamic Performance Views

Oracle Database 10g: Administration Workshop I 13-14

• Use the All Metrics link in

13-15 Copyright © 2005, Oracle. All rights reserved.

Viewing Performance Information

Oracle Database 10g: Administration Workshop I 13-15

Use Enterprise Manager to:

13-16 Copyright © 2005, Oracle. All rights reserved.

Reacting to Performance Issues

Oracle Database 10g: Administration Workshop I 13-16

Drill down into performance measurements to identify

• CPU user: a specific update statement

13-17 Copyright © 2005, Oracle. All rights reserved.

Reacting to Performance Issues (continued)

Oracle Database 10g: Administration Workshop I 13-17

13-18 Copyright © 2005, Oracle. All rights reserved.

Oracle Database 10g: Administration Workshop I 13-18

The three activities in performance management are:

13-19 Copyright © 2005, Oracle. All rights reserved.

Oracle Database 10g: Administration Workshop I 13-19

13-20 Copyright © 2005, Oracle. All rights reserved.

Oracle Database 10g: Administration Workshop I 13-21

• Have well-defined goals

13-22 Copyright © 2005, Oracle. All rights reserved.

Oracle Database 10g: Administration Workshop I 13-22

Large pool Fixed SGA

13-23 Copyright © 2005, Oracle. All rights reserved.

Tuning Memory Allocation

Oracle Database 10g: Administration Workshop I 13-24

• Try to fit the SGA into physical memory

13-25 Copyright © 2005, Oracle. All rights reserved.

select count() from x select count() from x