2007 Update: Since the days of Oracle7 when Oracle Corporation recommended keeping the buffer cache hit ratio above a fixed threshold, research has show some important facts. 

Please read: Is the Oracle buffer hit ratio a useless metric for monitoring and tuning?

Keeping your Oracle database tuned for peak performance requires an understanding of a number of issues. In my previous article, I explained how to tune the server and network. Once you've addressed those tasks, the next place to look is within the Oracle instance itself. An Oracle instance consists of the memory region of the database, called the System Global Area or SGA, and the Oracle background processes. Once the instance has been tuned, we look at tuning individual objects (tables and indexes) within the database, and finally we tune the SQL statements that are run against the database.

If you haven't read the first two articles in this series, you can still catch up. The first installment, "Oracle tuning: Start by looking at the big picture," provides an overview of Oracle tuning. The second, "Oracle tuning: Monitoring hardware with UNIX tools," looks at tuning the database server.

• shared_pool_size—The memory region allocated for the library cache and internal control structures
• db_block_size—The size of each data block
• db_block_buffers—The number of data buffers to allocate for the instance
• sort_area_size—The amount of RAM reserved for each user to perform sorting operations
• optimizer_mode—The default mode in which all SQL statements will be optimized for an execution plan
• db_file_multiblock_read_count—The parameter that controls the number of blocks that are read asynchronously in full-table scan operations

We have to remember that all Oracle instances are generally constrained by I/O operations. I/O is the single most dramatic component of Oracle performance, and any initialization parameters that can be used in order to reduce I/O will improve the performance of the database. For example, the db_block_size and db_block_buffers (later renamed db_cache_size, db_nnk_cache_size, &c) initialization parameters are very important in terms of reducing I/O. As a general rule, the larger the Oracle block size, the more the database can read in a single disk I/O and the less I/O contention the system will have.

• Shared pool delays—Delays in the shared pool are most commonly caused by large amounts of nonreusable SQL in the library cache. When a new SQL statement is parsed, Oracle will check in the library cache to see if the SQL statement has already been processed by an earlier task. This checking can slow down SQL possessing, especially for a database whose SQL is not reusable.
   
• Buffer busy waits—Buffer busy waits occur when a data block is in the buffer but can't be accessed because another task has a lock on the data block. This is most frequently caused by concurrent insert or update activity against a table that does not have multiple freelists defined.
   
• Buffer hit ratio—This metric is a measure of the effectiveness of the Oracle data block buffer. The higher the buffer hit ratio, the more frequently Oracle found a data block in memory and avoided an I/O.