Oracle Performance Top Issue list

Here summarize totally 10 MISTAKES we will encouter during the Performance Testing or Database process Monitor Process:

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
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.

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.

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.

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
-----------------------------------------
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.

--Refers to the Oracle Performance Tuning Guide.

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/12361284/viewspace-465925/，如需轉載，請註明出處，否則將追究法律責任。