Top Ten List of Oracle Performance Mistakes

1) Bad connection Management:
The application connects and disconnects for each database interaction. This is common problem with stateless middlewarein application servers. This mistake has two orders of magnitude impact on performance, and it is totally unscalable.
2) Bad use of Cursors and Shared Pool:
Not using cursors results in repeated parses. If bind variables are not used, then hard parsing occurs of all SQL statements. This has an order of magnitude impact in performance, and it is totally unscalable. Use of cursors with bind variables that open the cursor and re-execute it many times.
3) Getting Database I/O wrong:
Many sites lay out their database 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.
4) Redo Log Setup Problems:
Many sites run with too few redo logs which 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 active cannot keep up, and the database stalls.
5) 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 to 8K to 16K, or in applications with large numbers of active users and few rollback segments.
6) 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.
7) In disk Sorting:
In disk sorts for online operations could indicate poor transaction design, missing indexes, or poor SQL optimization. In disk sorts, by nature, are I/O intensive and unscalable.
8) 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. Recursive SQL executed user another user ID is probably SQL and PL/SQL and this is not a problem.
9) Schema Errors and Optimizer Problems:
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 stats. These errors can lead to sub-optimal execution plans and poor interactive user performance.
10) Use of Nonstandard Initialization Parameters:
These might have been implemented based on poor advice or incorrect assumption. 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.