Oracle provides the ability to create a optional area in the SGA (System Global Area), called the Large Pool to provide large memory allocations for the following. By allocating session memory from the large pool for shared server, Oracle XA, or parallel query buffers, Oracle can use the shared pool primarily for caching shared SQL and avoid the performance overhead caused by shrinking the shared SQL cache.

Some of the uses of Large Pool are listed below:

• Session memory for the shared server and the Oracle XA interface
• I/O server processes (DBW0)
• Oracle backup and restore operations
• Parallel execution message buffers, if the initialization parameter PARALLEL_AUTOMATIC_TUNING is set to true (otherwise, these buffers are allocated to the shared pool)

(Source: Oracle Memory Architecture)

The counters that we should be watching are as followed:

• V$SGASTAT: Large Pool bytes

What we want to see of the counters are:

• Watch the value for free memory when the results returned. If high or increasing values for free memory, you have over allocated space to the Large Pool. If low or decreasing values for free memory, you may need to consider increasing the Large Pool size.

The following queries will be used to determine the hit-ratio:

• SELECT name, bytes FROM V$SGASTAT WHERE pool =’large pool’;

Real world scenario

When using the Recovery Manager feature in Oracle, RMAN will buffer its I/O activity in Shared Pool. If database activity is high during the time that the RMAN backup is running, “ORA-04031 unable to allocate x bytes of shared memory” errors can result. This error indicates that a large piece of contiguous memory was requested in the Shared Pool, but could not be obtained. If this request is coming from RMAN, errors in the backup and poor application performance can result.  When the Large Pool is present, RMAN will use the Large Pool to buffer this I/O instead of the Shared Pool. This will result in not only better RMAN performance but also in improved Shared Pool hit-ratios.

(Source: OCP Oracle 9i Performance Tuning Study Guide)

Oracle includes several application program interfaces and Java class libraries in order to facilitate the interaction of Java-based applications with Oracle databases.  Oracle also allows you to dedicate a portion of the SGA, called Java Pool, as the location where session-specified Java code and application variables reside during program execution.

Similarly, like the Large Pool, the V$SGASTAT is used to determined the amount of memory allocated to Java Pool.  The counters that we should be watching are as followed:

• V$SGASTAT: Java Pool bytes

What we want to see of the counters are:

• The value for free memory can be used to help tune the size of the Java Pool.  If V$SGASTAT shows high or increasing values for free memory when compared to memory in use, you have probably over allocated space to the Java Pool.  If you have low or decreasing values for free memory, you may need to consider increasing the Java Pool size.

The following queries will be used to determine the hit-ratio:

• SELECT name, bytes FROM V$SGASTAT WHERE pool = ‘java pool’;

(Source: OCP Oracle 9i Performance Tuning Study Guide)

For Oracle 10g, Oracle recommends the total required Java pool memory to range between 10 and 50MB for Dedicated Servers.  While for Shared Servers, this could as large as more than 100MB.

(Source: Oracle® Database Java Developer’s Guide 10g Release 1 (10.1),10 Oracle Database Java Application Performance)

On the other hand, there are also non-hit ratio measures of Database Buffer Cache effectiveness such as Free Buffer Inspected Waits, Buffer Busy Wait events and Free Buffer Wait events.  To find out about the hit-ratio for the Database Buffer Cache, we can use V$SYSSTAT, V$SYSTEM_EVENT and STATSPACK.

The counters that we should be watching are as followed:

• V$SYSSTAT: Buffer Cache Hit Ratio
• V$SYSSTAT & V$SYSTEM_EVENT: Free Buffer Inspected
• STATSPACK > Instance Efficiency Percentages (Target 100%): Buffer Hit %
• STATSPACK > Instance Activity Stats for DB: <instance>: Free Buffer Inspected
• STATSPACK > Buffer Pool Statistics for DB: <instance>: Buffer Busy Wait

What we want to see of the counters are:

• Buffer Cache Hit Ratio should be higher than 90% for OLTP system according to Oracle.

The following queries will be used to determine the hit-ratio:

• SELECT 1 – ((physical.value – direct.value -lobs.value) / logical.value) “Buffer Cache Hit Ratio” FROM V$SYSSTAT physical, V$SYSSTAT direct, V$SYSSTAT lobs, V$SYSSTAT logical WHERE physical.name = ‘physical reads’ AND direct.name = ‘physical reads direct’ AND lobs.name = ‘physical reads direct (lob)’ AND logical.name = ’session logical reads’;
• SELECT name, value FROM V$SYSSTAT WHERE name IN (‘free buffer inspected’) UNION SELECT event, total_waits FROM V$SYSTEM_EVENT
  WHERE event in (‘free buffer waits’, ‘buffer busy waits’);

To know more about the counters, read on.

[1] V$SYSSTAT

Out of the 200 different available statistics, the performance of Database Buffer Cache for hit-ratio is calculated and based on four statistics, namely, Physical Reads, Physical Reads Direct, Physical Reads Direct [LOB] and Session Logical Reads.   Based on the four statistics, we are trying to calculate the physical reads made unintentionally (or on normal circumstances) against the the total of hits made on the cache represented by Session Logical Reads.  The general formula for Database Buffer Cache is as followed:

1 – ((physical reads – physical reads direct – physical reads direct [LOB]) / session logical reads)

The syntax of the SQL is as followed:

SELECT 1 – ((physical.value – direct.value – lobs.value) / logical.value) “Buffer Cache Hit Ratio” FROM V$SYSSTAT physical, V$SYSSTAT direct, V$SYSSTAT lobs, V$SYSSTAT logical WHERE physical.name = ‘physical reads’ AND direct.name = ‘physical reads direct’ AND lobs.name = ‘physical reads direct (lob)’ AND logical.name = ’session logical reads’;

Physical Reads; This indicates the number of data blocks (i.e. tables, indexes, and rollback segments) read from disk into the Buffer Cache since instance startup.

Physical Reads Direct; This indicates the number of reads that bypassed the Buffer Cache because the data blocks were read directly from disk instead.  Because direct physical reads are done intentionally by Oracle when using certain features like Parallel Query, these reads are subtracted from the Physical Reads value when the Buffer Cache hit ratio is calculated.  Otherwise, including these direct reads in the Buffer Cache hit ratio calculation would result in an artificially low hit ratio.

Physical Reads Direct (LOB); This indicates the number of reads that bypassed the Buffer Cache because the data blocks were associated with a Large Object (LOB) data type.

Because direct physical reads are done intentionally by Oracle when accessing segments that contain LOB datatypes, these reads are also subtracted from the Physical Reads value when the Buffer Cache hit-ratio is calculated.  Including these direct reads in the Buffer Cache hit ratio calculation would also result in an artificially low hit ratio.

Session Logical Reads; This indicates the number of times a request for a data block was satisfied by using a buffer that was already cached in the Database Buffer cache.  For read consistency, some of these buffers may have contained data from rollback segments.

Hit-ratios are one effective measure of Database Buffer Cache performance.  However, there are also ways to measure performance of Database Buffer Cache through non-hit ratio. TIP: Because these statistics can help guide you towards the true tuning trouble-spot, using them as a starting point of Buffer Cache tuning is often more effective than calculating Buffer Cache hit ratios and blindly increasing the size of the Buffer Cache.  The V$SYSSTAT and V$SYSTEM_EVENT can be used to monitor these secondary indicators of Buffer Cache Performance.  The V$SYSSTAT contains statistics of the Free Buffer Inspected statistics and the V$SYSTEM_EVENT contains statistics on the Free Buffer Waits and Buffer Busy Waits.  All three of these can be combined into one query using the SQL below:

SELECT name, value FROM V$SYSSTAT WHERE name IN (‘free buffer inspected’) UNION SELECT event, total_waits FROM V$SYSTEM_EVENT
WHERE event in (‘free buffer waits’, ‘buffer busy waits’);

Free Buffer Inspected; Number of Buffer Cache buffers inspected by user Server Process before finding a buffer.  A closely related statistic is dirty buffer inspected, which represents the total number of dirty buffers a user process found while trying to find a free buffer.

Free Buffer Waits; Number of waits experienced by user Server Processes during Free Buffer Inspected activity,  These waits occur whenever the Server Process had to wait for Database Writer to write a dirty buffer to disk.

Buffer Busy Waits; Number of times user Server Processes waited for a free buffer to become available.  These waits occur whenever a buffer requested by user Server Processes is already in memory, but is in use by another process.  These waits can occur for rollback segment buffers as well as data and index buffers.

The SQL statement queries the state of the statistics and it is recommend to record a benchmark over a period of time before proceeding with a load test.  High or steadily increasing values for any of these statistics indicate that user Server Processes are spending too much time searching for, and wait for access to, free buffers in the Database Buffer Cache.

[2] STATSPACK

Unlike the V$SYSSTAT and V$SYSTEM_EVENT, STATSPACK does not require calculation of the statistics as it has been calculated before display.  In the Instance Efficiency Percentage section, look at “Buffer Hit %” for the Database Buffer Cache hit-ratio.  For non-hit ratio, look at Instance Activity Stats for DB: <instance>: Free Buffer Inspected for Free Buffer Statistics and Buffer Pool Statistics for DB: <instance>: Buffer Busy Wait provides statistics for Number of times user Server Processes waited for a free buffer to become available.

The primary indicator of the performance of the Shared Pool (both Library Cache and Data Dictionary Cache) is the Cache Hit Ratio. High cache-hit ratios indicate that the application users are frequently finding the SQL and PL/SQL statements they are issuing already in memory. Oracle recommends maximizing the Library Cache before the Database Buffer Cache because the Library Cache has a greater impact on performance thanan under performing cache hit ratio for the Database Buffer Cache. The performance of the Library Cache is measure by calculating its hit ratio. Through this article, we wil be showing how to use three tools, namely, V$LIBRARYCACHE, STATSPACK and OEM Performance Manager to analyze the hit ratio.

The following will be the counters associating with Library Cache.

• V$LIBRARYCACHE: GETHITRATIO column
• V$LIBRARYCACHE: GETPINRATIO column
• V$LIBRARYCACHE: INVALIDATION column
• V$LIBRARYCACHE: RELOAD ratio
• STATSPACK > Instance Efficiency Percentages (Target 100%): Library Hit %
• STATSPACK > Library Cache Activity: Invalidations: Pct Miss
• STATSPACK > Library Cache Activity: Reloads
• OEM  > Performance Manager > Database Instance Category > Library Cache Hit %

The actual threshold for the Library Cache is as followed:

• The higher the GETHITRATIO, the better is the application is performing. According to Oracle, well-tuned OLTP systems can expect to have GETHITRATIO of 90% or higher for the SQL Area portion of the Library Cache. DSS and data warehouse applications often have lower hit ratios because of the ad hoc nature of the queries against them.
• Oracle recommends that well-tuned OLTP systems strive for PINHITRATIO that exceeds 90% for the SQL Area portion. DSS and data warehouse applications are generally lower.
• Low reload ratio for PINS is good. Oracle considers well-tuned systems to be those with Reload Ratios of less than 1 percent.
• High values for INVALIDATIONS mean additional overhead for the application. Therefore, performing activities that might cause INVALIDATIONS should be weighed against the expected benefit of those activities.
• For STATSPACK, look at Library Hit % for the percentage of Library Cache hit-ratio. The Namespace, SQL AREA should have a 90% hit-ratio for the Library Cache.

Queries to be used for Library Cache:

• SELECT NAMESPACE,GETHITRATIO,PINHITRATIO FROM V$LIBRARYCACHE;
• SELECT SUM(RELOADS)/SUM(PINS) “Reload Ratio” FROM V$LIBRARYCACHE;

The explanation of the counters are discussed after the table and will be recommended to read through them if you are unsure what they mean.

[1] V$LIBRARYCACHE

A library cache miss can occur at either the Parse or Execute phases of SQL statement processing. The cache hit ratio related to the Parse Phase is shown in the GETHITRATIO column of V$LIBRARYCACHE while the Execute Phase is shown in the PINHITRATIO column of V$LIBRARYCACHE.  Other than GETHITRATIO and PINHITRATIO, the RELOADS and INVALIDATIONS columns of V$LIBRARYCACHE are also examined to uncovered behaviour of the Library Cache.

GETHITRATIO
Oracle uses the term “get” to refer to a type of lock, called a “Parse Lock”, that is taken out on an object during the Parse Phase for the statement that references that object. Each time a statement is parsed, the value for GETS in the V$LIBRARYCACHE view is incremented by 1. On the other hand, the column GETHIT stores the number of times that the SQL and PL/SQL statements issued by the application found a parsed copy of themselves already in memory. When this occurs, there is no parsing of the statement required and the user’s server process just executes the copy already in memory instead. The ratio of parsed statements (GETS) to those that did not required parsing (GETHITS) is calculated in the GETHITRATIO column of V$LIBRARYCACHE.

PINHITRATIO

PINs like GETS, are also related to locking. However, while GETS are associated with locks that occur at Parse time, PINS are related to locks that occur at Execution time. These locks are the short-term locks used when accessing an object. Therefore, each library cache GET also requires an associated PIN, in either Shared or Exclusive mode, before accessing the statement’s reference objects. Each time a statement is executed, the value for PINS is increments by 1. The PINHITRATIO column in V$LIBRARYCACHE indicates how frequently executed statements found the associated parsed SQL already in the Library Cache.

RELOADS

RELOADS column shows the number of times that an executed statement had to be re-parsed because the library cache had aged out or invalidated the parsed version of the statement.  Examining the RELOAD column individually will not tell much.  Reload activity can be monitored by comparing the number of statement that have been executed (PINS) to the number of those statements that required a reload (RELOADS), calculated based on the following SQL:

INVALIDATIONS

INVALIDATIONS occur when a cached SQL statement is marked as invalid and forced to parse even though it was already in the Library Cache. Cached statements are marked as invalid whenever the objects they referenced are modified in some way. For example, recompiling a view that was used by previously cached SQL statements will cause the those cached statements to be marked as invalid. Therefore, any subsequent statements that use this view will need to be parsed even though an exact copy of that statement may already be cached. High values for INVALIDATIONS mean additional overhead for the application. Therefore, performing activities that might cause invalidations should be weighed against the expected benefit of those activities.

[2] STATSPACK

The same cache hit-ratio information can be found in the results of STATSPACK. Library Cached performance statistics are included in the STATSPACK section headed Instance Efficiency Percentages (Target 100%). Look at Library Hit % for the percentage of Library Cache hit-ratio. Also, it is possible to look at the STATSPACK for INVALIDATIONS and RELOADS, under Library Cache Activity. Observe Pct Miss which conversely means that percentage that hits when minus off 100%.

[3] OEM Performance Manager

From OEM, access Performance Manager > Database Instance Category > Library Cache Hit %. This gives a runtime view of the Library Cache hit-ratio which eliminates the need to query V$LIBRARYCACHE. However, as this is a runtime view, you won’t be able to conduct analysing work after a load test.  Therefore, for analysing work after a load test, it is advisable to use Custom Query of Oracle Monitoring in LoadRunner to query V$LIBRARYCACHE from a load testing perspective.

(Source: OCP Oracle 9i Performance Tuning Study Guide)

Before we are able to analyze and determine tuning areas, we need to understand Oracle Server Architecture and it’s underlying mechanism. Oracle Server Architecture consist of two main categories: logical (memory) structures and physical (or file) structures. The Oracle memory structure is collectively known as Oracle Instance. While the physical file structures are collectively known as Oracle database. Together, they are call an Oracle Server.

Oracle Instance

The Oracle Instance consist of the Oracle’s main memory structure, System Global Area (SGA) and the Oracle background processes. The SGA is made up of the following components: (a) Shared Pool, (b) Database Buffer Cache, (c) Java Pool and (d) Redo Log Buffer. In Oracle 9.2 and later, (e) Streams Pool was introduced into the SGA. Other components such as (f) Large Pool may also exist as it is dependent on the optional features from Oracle. The background processes, included (a) System Monitor (SMON), (b) Process Monitor (PMON), (c) Database Writer (DBW0), (d) Log Writer (LGWR) and the (e) Checkpoint Process (CKPT). Other optional processes maybe running as well such as Recoverer (RECO).

The following illustrates the entire System Global Area Components:

The components of the instance – the SGA and the required background processes – acquired space in the server’s memory immediately upon startup of the database. While the required background processes will always acquire the same amount of memory for their purposes, there are four init.ora parameters are the primary determinants of SGA’s memory requirements. They are:

• DB_CACHE_SIZE
• SHARED_POOL_SIZE
• LOG_BUFFER
• LARGE_POOL_SIZE

However, there is still one parameter in init.ora that determines the overall size of the System Global Area, which is SGA_MAX_SIZE.  Within this parameter contains two component, Shared Pool and Database Buffer Cache that can be dynamically resized using ALTER SYSTEM command. If the value for SGA_MAX_SIZE is less that the sum of the component at instance startup, Oracle will ignore the setting for SGA_MAX_SIZE and use the sum of the components as the value instead.

Oracle Database

An Oracle database is made up of physical files called (a) control files, (b) datafiles and (c) redo logs. Additional files associated with the database are (d) init.ora, trace and alert log files, password file, and any archived redo log files. The usage of the files are as followed:

Of all the files mentioned, the init.ora file have great importance in Oracle Server performance tuning with many parameters associated to improve the performance. The default location of init.ora on Windows is %ORACLE_HOME%\database while Unix is $ORACLE_HOME/dbs.

(Source: OCP Oracle 9i Performance Tuning Study Guide)

Following this article, we will be covering the following sections on the individual components that can be tuned in the Oracle Instance and the Database itself.

Let’s go through an overview for implementing the Oracle DB. Basically, we are doing in this sequence:

1. Get an account in Oracle and access to the V$ tables that contains the monitoring data.
2. Install 32-bit Oracle client on the Controller machine.
3. Ensuring that proper configuration is done to connect to the DB using TNSNAMES.ora and defining the Oracle path.
4. Login to the DB using SQL*PLUS and run a query to see if you can collect the statistics from the V$ tables.
5. Launch LoadRunner Controller, configure the monitor and start your load test!

Ok, let’s dive into the details!

1. Request for an account and password to be created in the database instance (unless you are the DBA). Example, loadtester, and grant them access to read the following table. These tables consist of the statistic of the database instance.

• V$SESSTAT
• V$SYSSTAT
• V$STATNAME
• V$INSTANCE
• V$SESSION

2. Ensure that Oracle client libraries are installed on the Controller. Remembered that in order to monitor, you need local installation of the client in order for LoadRunner to query the monitoring data. If you do not have the client libraries, download it from Oracle Downloads. Download only the 32-bit Oracle client.

3. If you have the client installed, ensure the 32-bit Oracle client is installed on the Controller, not the 16-bit client.

4. Verify that %OracleHome%\bin is included in the path environment. This can be done by going to START > My Computer > Properties > “Advanced Tab” > Enviromental Settings.

5. Configure the TNSNAMES.ora file on the Controller. TNSNAMES.ora file is a SQL*Net configuration file that defines databases addresses for establishing connections to them. This file normally resides in the ORACLE_HOME\NETWORK\ADMIN directory. (Source: OraFaq)

Attached is an example of the TNSNAMES.ora file. Click here to download.

6. Ensure login successful with the created account (e.g. loadtester) with SQL*Plus from the Controller machine.

7. Ensure the privileges are given properly by typing the following command. If they don’t return results or return access rights issues, most probably the steps for prior to this one has not been configured properly. Therefore, approach the Database Administrator for assistance or go back to the previous steps to ensure they are properly configured.

• SELECT * FROM V$SESSTAT
• SELECT * FROM V$SYSSTAT
• SELECT * FROM V$STATNAME
• SELECT * FROM V$INSTANCE
• SELECT * FROM V$SESSION

8. Launch LoadRunner Controller as per norm and add the Oracle Database Monitor. When prompt, enter the account name (e.g. loadtester), it’s corresponding password and the destination server name. Statistics should be drawn from the V$ table and displayed in Controller.

With the above, you should be able to successfully configure the monitoring environment and the Controller with minimal difficulty.

Note:
You can change the sampling interval for the monitor using the vmon.cfg file located in {loadrunner-installed-dir}\monitors\vmon.cfg

The counters that we should be watching are as followed:

• V$ROWCACHE: Data Dictionary Hit Ratio
• STATSPACK > Dictionary Cache Stats  DB/Inst: Pct Miss: 1- dc_xxxxxxxxxx

What we want to see of the counters are:

• Break the Data Dictionary Cache to its individual component, dc_xxxxxxxx (e.g. dc_free_extents, dc_object_ids).  Examine cache activity by monitoring the GETS and GETMISSES columns.  For frequently accessed dictionary caches, the ratio of total GETMISSES to total GETS should be less than 10% or 15%, depending on the applicatio.  Else it warrants tuning on the Oracle recommends that consideration should be given to tuning the Shared Pool. (Source: Oracle9i Database Performance Tuning Guide and Reference Release 2 (9.2))

The following queries will be used to determine the hit-ratio:

• SELECT parameter, 1 – (SUM(getmisses)/SUM(gets)) “Data Dictionary Hit Ratio” FROM V$ROWCACHE;
• SELECT parameter, (SUM(getmisses)/SUM(gets)) “Data Dictionary Hit Ratio” FROM V$ROWCACHE;

To know more about the counters, read on.

[1] V$ROWCACHE

Two of the columns contained in the V$ROWCACHE view, GETS and GETMISSES, can be used to calculate the Data Dictionary Cache hit ratio. The statistics in this view are not generally examined individually, but as a combined equation query shown below.  In the below query, we are calculating the hit-ratio of successful GETS from the Data Dictionary Cache by subtracting the value of the total GETMISSES over total of GETS by 1.  Not subtracting by 1 will result in the GETMISSES ratio.  The first SQL gives the ratio for GETS and the latter gives the ratio for GETMISSES.

SELECT 1 – (SUM(getmisses)/SUM(gets)) “Data Dictionary Hit Ratio” FROM V$ROWCACHE;

SELECT parameter, 1 – (SUM(getmisses)/SUM(gets)) “Data Dictionary Hit Ratio” FROM V$ROWCACHE;

[2] STATSPACK

Under the Dictionary Cache Stats of the DB Instance section of the STATSPACK output, look at Pct Miss which represent the miss ratio.  For each components of the Data Dictionary Cache, minus the value shown in STATSPACK (Pct Miss) will result in the hit-ratio for the component of the Data Dictionary Cache. Threshold fo the Pct Miss will still be the same for V$ROWCACHE.

(Source: OCP Oracle 9i Performance Tuning Study Guide)