Oracle uses the SGA for the following operations:
• Caching of database blocks containing table and index data in the database buffer cache
• Caching of parsed and optimized SQL statements, stored procedures, and data dictionary information in the shared pool
• Buffering of redo log entries in the redo log buffer before they’re written to disk In versions prior to Oracle 9i, the amount of memory allocated to each of these areas within the SGA was determined at instance startup using initialization parameters and could not be altered without restarting the instance.
The majority of tuning efforts focused on the database buffer cache and the shared pool.
Automatic sizing for the SGA
Oracle Database 10geliminated manual tuning of SGA pools with automatic sizing for the SGA. Using automatic shared memory management, the database automati-cally allocates memory for the following SGA pools: database buffer cache, shared pool, large pool, Java pool, and Streams pool. Youhave to specify only the total amount of memory required by setting the SGA_TARGET initialization parameter.
Oracle and Memory Resources | 177 Since Oracle Database 10g, the database proactively monitors the memory require-ments for each pool and dynamically reallocates memory when appropriate. Youcan also specify the minimum amount of memory for any of the SGA pools while using automatic SGA sizing using the following initialization parameters: DB_CACHE_
SIZE, SHARED_POOL_SIZE, LARGE_POOL_SIZE, JAVA_POOL_SIZE, and STREAMS_POOL_SIZE. A few SGA pools, specified using such parameters as LOG_BUFFER, DB_KEEP_CACHE_SIZE, and DB_RECYCLE_CACHE_SIZE, are still manually sized.
The database buffer cache
If youdecide to disable SGA_TARGET by setting it to 0, youwill need to manually set initialization parameters for the memory pools (unless you want to use previous sizes). For the database buffer cache, you would assess the percentage of the data-base blocks requested by users read from the cache versus from the disk. This percentage is termed the hit ratio. If response times are too high and this ratio is lower than 90% (as a rule of thumb), increasing the value of the initialization param-eter DB_CACHE_SIZE can increase performance.
You can use Oracle Enterprise Manager to get information about the cache hit ratio.
It’s tempting to assume that continually increasing the size of the database buffer cache will translate into better performance. However, this is true only if the data-base blocks in the cache are actually being reused. Most OLTP systems have a relatively small set of core tables that are heavily used (for example, lookup tables for things such as valid codes). The rest of the I/O tends to be random, accessing a row or two in various database blocks in the course of the transaction. Because of this, having a larger buffer cache may not contribute to performance since there isn’t much reuse of data blocks occurring.
In addition, not all operations read from the database buffer cache. For example, large full-table scans are limited to a small number of buffers to avoid adversely impacting other users by dominating the cache. If your application performs a lot of table scans, increasing the buffer cache may not help performance because the cache will not contain the needed data blocks. Parallel table scans completely bypass the buffer cache and pass rows directly to the requesting user process. As with most per-formance issues, your understanding of how your application is actually using your data is the key that will help guide your database buffer-cache tuning.
The shared pool
The shared pool is used at several points during the execution of every operation that occurs in an Oracle database. For example, the shared pool is accessed to cache the
178 | Chapter 7: Oracle Performance
SQL sent to the database and for the data dictionary information required to execute the SQL. Because of its central role in database operations, a shared pool that is too small may have a greater impact on performance than a database buffer cache that is too small. If the requested database block isn’t in the database buffer cache, Oracle will perform an I/O to retrieve it, resulting in a one-time performance hit.
A shared pool that is too small will cause poor performance for a variety of reasons, affecting all users. These reasons include the following:
• Not enough data dictionary information can be cached, resulting in frequent disk access to query and update the data dictionary.
• Not enough SQL can be cached, leading to memory “churn,” or the flushing of useful statements to make room for incoming statements. A well-designed appli-cation issues the same statements repeatedly. If there isn’t enough room to cache all the SQL the application uses, the same statements get parsed, cached, and flushed over and over, wasting valuable CPU resources and adding overhead to every transaction.
• Not enough stored procedures can be cached, leading to similar memory churn and performance issues for the program logic stored and executed in the database.
If you are manually managing the shared pool and you’ve diagnosed which of these problems is occurring, the solution is fairly simple: increase the size of the shared pool using the SHARED_POOL_SIZE initialization parameter. Shared pool sizes in the 150–250 MB range are not uncommon for large, active databases. For more information about examining shared pool activity to identify problems, see the appropriateOracle Performance Tuning Guide, as well as the third-party books listed in Appendix B.
The redo log buffer
While the redo log buffer consumes a very small amount of memory in the SGA rela-tive to the database buffer cache and the shared pool, it’s critical for performance.
Transactions performing changes to the data in the database write their redo infor-mation to the redo log buffer in memory. The redo log buffer is flushed to the redo logs on disk when a transaction is committed (normally) or when the redo log buffer is one-third full. Oracle “fences” off the portion of the redo log buffer that’s being flushed to disk to make sure that its contents aren’t changed until the information is safely on disk. Transactions can continue to write redo information to the rest of the redo log buffer (the portion that isn’t being written to disk and therefore isn’t fenced off by Oracle). In a busy database, transactions may generate enough redo to fill the remaining unfenced portion of the redo log buffer before the I/O to the disks for the fenced area of the redo log buffer is complete. If this happens, the transactions will have to wait for the I/O to complete because there is no more space in the redo log buffer. This situation can impact performance. The statistic “redo buffer allocation
Oracle and Memory Resources | 179 retries” can be used to understand this situation. It is available through V$SYSSTAT and is an indication of how often a session waited for space in the redo log buffer. An example of the query you may use to obtain the statistic is:
SELECT name, value FROM V$SYSSTAT
WHERE name = 'redo buffer allocation retries';
Youwould monitor these statistics over a period of time to gain insight into the trend. The values at one point in time reflect the cumulative totals since the instance was started and aren’t necessarily meaningful as a single data point. Note that this is true for all statistics used for performance tuning. Ideally, the value of “redo buffer allocation retries” should be close to 0. If you observe the value rising during the monitoring period, you would increase the size of the redo log buffer by resetting the LOG_BUFFER initialization parameter.
Query results caching
One of the most significant performance features in Oracle Database 11gcan be used to help improve the performance of repeated queries. Oracle caches database and index blocks, eliminating the need to perform resource-intensive disk reads. Oracle caches SQL plans, eliminating the need to reparse and optimize queries. But prior to Oracle Database 11g, a cached SQL plan would still have to execute and assemble a result set.
The new feature allows Oracle Database 11gto cache the completed result set in the shared pool. This new functionality means that a repeated query requesting the same result set can simply take that result set completely from memory. Since the result sets have to be the same for this feature to work, the query results cache has the big-gest impact on situations like web page serving, where the same page is being retrieved repeatedly. This feature also works on the results of PL/SQL functions.
Oracle Database 11galso includes the ability to cache query result sets on the client, while automatically keeping the result set consistent with any changes that could affect it. This feature gives the performance benefits of query result set caching on the server while eliminating network roundtrips as an added benefit.