Top Ten Mistakes Found in Oracle Systems
This section lists the
most common mistakes found in Oracle systems. By following the
Oracle performance
improvement methodology, you should be able to avoid these
mistakes altogether. If
you find these mistakes in your system, then re-engineer the
application where the
performance effort is worthwhile. See "Automatic Performance
Tuning Features"
on page 1-5 for information on the features that help diagnose and
tune Oracle systems. See Chapter
10, "Instance Tuning Using Performance Views" for a
discussion on how wait
event data reveals symptoms of problems that can be
impacting performance.
1.
Bad Connection Management
The application connects
and disconnects for each database interaction. This
problem is common with
stateless middleware in application servers. It has over
two orders of magnitude
impact on performance, and is totally unscalable.
2.
Bad Use of Cursors and the Shared Pool
Not using cursors results
in repeated parses. If bind variables are not used, then
there is hard parsing of
all SQL statements. This has an order of magnitude impact
in performance, and it is
totally unscalable. Use cursors with bind variables that
See
Also: Oracle Database Reference for more information on
V$SQL and V$SQLSTATS
The Oracle Performance
Improvement Method
Performance Improvement
Methods 3-5
open the cursor and
execute it many times. Be suspicious of applications
generating dynamic SQL.
3.
Bad SQL
Bad SQL is SQL that uses
more resources than appropriate for the application
requirement. This can be a
decision support systems (DSS) query that runs for
more than 24 hours or a
query from an online application that takes more than a
minute. SQL that consumes
significant system resources should be investigated for
potential improvement.
ADDM identifies high load SQL and the SQL tuning
advisor can be used to
provide recommendations for improvement. See Chapter 6,
"Automatic
Performance Diagnostics" and Chapter 12, "Automatic
SQL Tuning".
4.
Use of Nonstandard Initialization Parameters
These might have been
implemented based on poor advice or incorrect
assumptions. Most systems
will give acceptable performance using only the set of
basic parameters. In particular,
parameters associated with SPIN_COUNT on
latches and undocumented
optimizer features can cause a great deal of problems
that can require
considerable investigation.
Likewise, optimizer
parameters set in the initialization parameter file can override
proven optimal execution
plans. For these reasons, schemas, schema statistics, and
optimizer settings should
be managed together as a group to ensure consistency of
performance.
5.
Getting Database I/O Wrong
Many sites lay out their
databases poorly over the available disks. Other sites
specify the number of
disks incorrectly, because they configure disks by disk space
and not I/O bandwidth. See
Chapter 8, "I/O Configuration and Design".
6.
Redo Log Setup Problems
Many sites run with too
few redo logs that are too small. Small redo logs cause
system checkpoints to
continuously put a high load on the buffer cache and I/O
system. If there are too
few redo logs, then the archive cannot keep up, and the
database will wait for the
archive process to catch up. See Chapter 4, "Configuring
a Database for
Performance" for information on sizing redo logs for performance.
7.
Serialization of data blocks in the buffer cache due to lack of
free lists, free list
groups, transaction slots
(INITRANS), or shortage of rollback segments.
This is particularly
common on INSERT-heavy applications, in applications that
have raised the block size
above 8K, or in applications with large numbers of
active users and few
rollback segments. Use automatic segment-space
management (ASSM) to and
automatic undo management solve this problem.
8.
Long Full Table Scans
See
Also:
■ Oracle Database
Administrator's Guide for information on
initialization parameters
and database creation
■ Oracle Database
Reference for details on initialization parameters
■ "Performance
Considerations for Initial Instance Configuration"
on page 4-1 for
information on parameters and settings in an
initial instance
configuration
Emergency Performance
Methods
3-6
Oracle Database Performance Tuning Guide
Long full table scans for
high-volume or interactive online operations could
indicate poor transaction
design, missing indexes, or poor SQL optimization. Long
table scans, by nature,
are I/O intensive and unscalable.
9.
High Amounts of Recursive (SYS) SQL
Large amounts of recursive
SQL executed by SYS could indicate space
management activities,
such as extent allocations, taking place. This is unscalable
and impacts user response
time. Use locally managed tablespaces to reduce
recursive SQL due to
extent allocation. Recursive SQL executed under another
user Id is probably SQL
and PL/SQL, and this is not a problem.
10.
Deployment and Migration Errors
In many cases, an
application uses too many resources because the schema
owning the tables has not
been successfully migrated from the development
environment or from an
older implementation. Examples of this are missing
indexes or incorrect
statistics. These errors can lead to sub-optimal execution plans
and poor interactive user
performance. When migrating applications of known
performance, export the
schema statistics to maintain plan stability using the
DBMS_STATS package.
Although these errors are
not directly detected by ADDM, ADDM highlights the
resulting high load SQL.
No comments:
Post a Comment