Tài liệu ORACLE8i- P17 doc

V$LIBRARY_CACHE Contains various statistics on the performance of the library cache.. moni-We recommend monitoring the following database information using the V$ views: • Various SGA hi

TABLE 15.3: COMMONLY USED EVENTS (CONTINUED)

10033 Provides details about sorts to disk ALTER SESSION SET EVENTS

‘10033 trace name context ever, level 4’;

‘10046 trace name context ever, level 4’;

‘10053 trace name context forever, level 1’;

‘10128 trace name context ever, level 1’;

for-10210 Provides table block checking EVENT=”102100 trace name

context forever, level 10”

10211 Provides index block checking EVENT=”10211 trace name

context forever, level 10”

10212 Provides index block checking EVENT=”10212 trace name

context forever, level 10”

10231 Skips corrupted blocks during table scans EVENT=”10231 trace name

context forever, level 10” Toturn off block checking oncethe database is up and run-ning, issue ALTER SYSTEM SETEVENTS ‘10231 trace namecontext off’;

10232 Dumps corrupted blocks to a trace file EVENT=”10232 trace name

context forever, level 10”

10240 Dumps the DBA of blocks that incur waits EVENT=”10240 trace name

context forever, level 10”

10391 Traces parallel query execution EVENT=”10391 trace name

context forever, level 10”

Provides details on partition elimination decisions Valid levels are 1, 2, and 4

Provides details on how the CBO decidedwhich execution plan to use Valid level is 1,which gives information on the CBO executiondecisions

Used to trace a session Valid levels are 1 (regular trace), 4 (dump bind variables), 8(dump wait information), and 12 (dump all)

As an example, suppose that you want to dump the control file header to see the lastcheckpoint SCN You can use the following command to do a control file header dump:

ALTER SESSION SET EVENTS ‘immediate trace name controlf level 10’;

This creates a trace file in the location defined by the init.ora parameterUSER_DUMP_DEST, which will contain the control file dump that you want to review

As another example, suppose that you want to trace your user session, dumpingthe bind variables as well as the wait events To enable this trace, you can use event

10046 set at level 4:

ALTER SESSION SET EVENTS ‘10046 trace name context forever, level 12’;

This creates a session trace file, just as you would get with the ALTER SESSION SETSQL_TRACE=TRUE command

If you want to set an event that always executes when the database starts, you canset it in the database init.ora file For example, if you want to trace session logonsand logoffs, you can set events 10029 and 10030:

EVENT=”10029 trace name context forever, level 10”

EVENT=”10030 trace name context forever, level 10”

In this case, the level 10 indicates tracing with additional detail The CONTEXT EVER parameter means that this event will continue to be reported If you want toturn this event off, use CONTEXT OFF instead

FOR-You can also set an event for a specific session by using DBMS_SYSTEM.SET_EV

This procedure takes five parameters, as shown in its description below:

PROCEDURE SET_EVArgument Name Type In/Out Default?

be NULL, but it may be blank Depending on the event (again, sometimes it’s a matter Beyond Simple Database Management

P A R T

III

of trial and error to get the right setting), you may need to enter the last parameter asempty quotation marks, as in this example:

EXEC SYS.DBMS_SYSTEM.SET_EV(9,407,10046,4,’’);

This sets event 10046 for session 9 (serial number 407), to level 4, sending '' as the name

TI P You can set regular error events so that they will cause trace files to be generatedwhen they occur For example, when a user tries to perform an action that he or she does nothave the rights to do, this will generally cause an ORA-1031 to occur You can set the 1031event to cause a trace file to be dumped each time that this event occurs: EVENT=”1031trace name errorstack forever, type increment” Although you can get more information from

a custom event trigger, being able to set the event and trap it is a handy tool

Using Oracle8i Dynamic Performance Views

Dynamic performance views generally start with a V$ prefix, and they are also

referred to as V$ views Dynamic performance views give a snapshot of the database’s

various performance statistics For the most part, all the information you will need totune and monitor your database will come from the V$ views As with any endeavor,

if you want to be an expert, you should know how the tools you use actually work

So, first we’ll look at how the V$ views are constructed Then you’ll learn about theV$ views that are useful for performance monitoring

NOTE One mistake DBAs commonly make is to expect dynamic performance views to

be truly dynamic—updated immediately all of the time Unfortunately, this isn’t alwaystrue In some cases, dynamic performance views may lag too far behind to provide thetimely information you need

How Are V$ Views Created?

The V$ views that you query, such as V$SYSSTAT, are actually synonyms that point to

views If you look up V$SYSSTAT in the SYNONYM_NAME column of DBA_SYNONYMS,

you’ll find that V$SYSSTAT is a synonym for a view called V_$SYSSTAT The V_$ viewsare the underlying views that you look at when querying the V$ views

You might think that you could find the SQL text that comprises the V_$ view inDBA_VIEWS However, because V$ views are really internal data dictionary views, themethod by which they are implemented differs slightly from regular views Ratherthan going to the DBA_VIEWS view to find the creation text of the view, you go toV$FIXED_VIEW_DEFINITION to find the SQL statements used to create the V$ views.

If you look at the view definitions in V$FIXED_VIEW_DEFINITION, you’ll find thatthe V_$ views are further based on a series of GV$ views These views are, in turn, based

on a series of tables called the X$ tables The X$ tables are often called fixed views

These tables represent various structures that the Oracle database populates at systemstartup The Oracle DBA does not normally need to access the X$ tables (although we

do refer to these and other underlying base tables in this book) The V$ views (and theunderlying X$ tables) get their information from various sources, including the data-base itself, the database control file, the data parameter files, and so on

NOTE Be careful if you choose to use the X$ views Oracle changes such structuresfrom release to release, so a query that works in Oracle8i may not work in 8i release 2 Thequeries you see here (many of which were written using Oracle 8.1.6.3) may not work inlater versions

Which V$ Views Are for Performance Monitoring?

Table 15.4 lists the V$ views that pertain to performance monitoring, along with abrief description of each view

NOTE V$ view statistics are cumulative in nature They will be reset when the databasestarts and will accumulate values as the database continues to function Some of them willeven roll over if the database has been running long enough

Beyond Simple Database Management

P A R T

III

TABLE 15.4: ORACLE V$ VIEWS FOR DATABASE PERFORMANCE MONITORING

V$DATABASE Describes database information derived from the database

control file You can use this view to join with dynamic mance views to report on the database name

perfor-V$DBFILE Resolves datafile numbers to the name/location of the datafile

You can use this view to join with other dynamic performanceviews to report the names and locations of datafiles This view

is similar to the DBA_DATA_FILES data dictionary view V$DB_OBJECT_CACHE Displays objects that are in the library cache, such as tables

and indexes You can use this view with others to look atobject memory use, the number of times the object has beenloaded, and other information that might indicate that theshared pool needs to be tuned

V$DISPATCHER Monitors dispatcher processes in a distributed environment.V$DISPATCHER_RATE Provides additional statistics on the dispatcher processes V$FILE_STAT Provides information on database file I/O You can use this

view to monitor database datafiles to make sure that the base does not become I/O bound

data-V$FIXED_TABLE Lists all dynamic performance views Note that some V$ tables

are actually real tables and will not be listed in this view.V$FIXED_VIEW_DEFINITION Lists the SQL text that comprises a V$ view

V$INSTANCE Lists the instance name, the startup date and time, and if the

instance is hung waiting for the ARCH process to cleararchived redo logs

V$LATCH Displays latching statistics for parent latches and summary

sta-tistics for child latches

V$LATCH_CHILDERN Displays latching statistics for child latches

V$LATCH_MISSES Contains statistics on latch acquisition failures

V$LIBRARY_CACHE Contains various statistics on the performance of the library

cache

V$LOG_HISTORY Contains information on redo log switches You can use this

view to determine if you are switching redo logs too often ornot often enough

V$OPEN_CURSOR Lists cursors that each user session has opened and parsed

You can use this view to identify SQL statements that arebeing run by a specific session

TABLE 15.4: ORACLE V$ VIEWS FOR DATABASE PERFORMANCE MONITORING (CONTINUED)

V$PARAMETER Lists database parameter settings

V$PQ_SESSTAT Shows session statistics for parallel queries

V$PQ_SLAVE Shows parallel query slave process statistics

V$PQ_SYSSTAT Shows system-level statistics for parallel query processing

V$PX_PROCESS Contains information about sessions using parallel query

V$ROLLNAME Displays rollback segment name information

V$ROLLSTAT Contains various rollback segment information

V$ROWCACHE Contains statistics for the data dictionary

V$RSRC_CONSUMER_GROUP Contains information on active resource consumer groups

V$SESSION Contains session-level database information

V$SESSION_CURSOR_CACHE Contains information on current cursor usage You can use this

view to determine if the OPEN_CURSORS setting parameter isset appropriately

V$SESSION_LONGOPS Displays information on certain long-running database

opera-tions You can use this view to see if any long-runningprocesses might have been started inadvertently

V$SESS_IO Lists I/O statistics for each user session

V$SESSTAT Contains specific session statistics

V$SGA Lists memory allocations of various SGA components

V$SGASTAT Contains memory allocation information for various SGA

components

V$SHARED_POOL_RESERVED Contains information on the reserved part of the shared pool

V$SQL Lists statistics on SQL in the shared pool

V$SQLAREA Contains information on the shared SQL area of the shared

pool You can use this view to see if inefficient SQL is beingexecuted Beyond Simple Database Management

P A R T

III

TABLE 15.4: ORACLE V$ VIEWS FOR DATABASE PERFORMANCE MONITORING (CONTINUED)

V$STATNAME Displays statistic names to allow for resolution when only the

statistic number is available from a V$ view

V$SYSSTAT Contains various system-level statistics You can use this view

to join with V$STATNAME to resolve the statistic names.V$TEMPSTAT Contains temporary datafile read/write statistics

V$THREAD Contains various instance information from the control file.V$TRANSACTION Contains transaction information You can use this view to

identify transactions that are using excessive resources

NOTE This chapter will not address V$ views that don’t pertain to performance toring For a comprehensive list of dynamic performance views, refer to Appendix H orquery the Oracle8i V$FIXED_VIEW_DEFINITION table

moni-We recommend monitoring the following database information using the V$ views:

• Various SGA hit ratios, including the database buffer cache and the variousshared pool hit ratios (V$SGA, V$SYSSTAT, and V$SGASTAT)

• I/O contention, because too much I/O can impact system performance(V$FILE_STAT and V$SESS_IO)

• Memory contention, because allocating too little or too much memory to tain structures can impact system performance (V$DB_OBJECT_CACHE,V$SGA, and V$SGASTAT)

cer-• Latching and waiting (V$LATCH, V$LATCH_CHILDERN, and V$LATCH_MISSES)

• Efficiency of SQL statements, because inefficient SQL can cause performanceproblems (V$SQLAREA and V$SQL)

• Potential internal database problems, such as a segment unable to extend orrollback segments that are not as efficient as they could be (V$ROLLSTAT)

• Long-running database operations, which can negatively impact overall base operations such as index rebuilds and some SQL operations(V$SESSION_LONGOPS)

data-In this chapter, we’ll build scripts using several V$ performance views to monitorvarious aspects of database performance Methods for monitoring latching, waiting,and long-running database operations are covered in Chapters 16 and 17

How Do You Get More Information from V$ Views?

Some of the V$ views provide more performance information if you enable the

TIMED_STATISTICS parameter in the database The TIMED_STATISTICS parameter

defaults to a FALSE setting When it is set to TRUE, the database gathers time-relatedstatistics on various operations Be aware that this collection effort has some overheadassociated with it, so you might want to measure the impact of enabling the parame-ter before forging ahead

NOTE Oracle8i release 8.1.5 had trouble enabling the TIMED_STATISTICS parameter,and this caused serious performance problems This was corrected in the 8.1.5.1 patch forthat release Later releases don’t have the problem If you are using release 8.1.5, makesure that you’ve installed the 8.1.5.1 patch

You can use one of several different methods to set the TIMED_STATISTICS parameter:

• Set it in the init.ora database parameter file, where the setting will take effect

on the next database reboot

• Dynamically enable it for a given session by using this command:

ALTER SESSION SET timed_statistics=TRUE

• Enable it for the entire system by using this command:

ALTER SYSTEM SET timed_statistics=TRUE

To disable the parameter, either for the session or system, reset it to FALSE

The following V$ views have columns that are affected by enabling theTIMED_STATISTICS parameter:

Enabling TIMED_STATISTICS before looking at these views will cause Oracle to pro-vide additional time-related information, such as how long the session waited and the total time that a particular event occurred For example, suppose that you issued the following query to see the total number of wait events in V$WAITSTAT:

SQL> SELECT * FROM v$waitstat;

CLASS COUNT TIME

-

-data block 22 0

sort block 0 0

save undo block 0 0

segment header 0 0

save undo header 0 0

free list 0 0

extent map 0 0

bitmap block 0 0

bitmap index block 0 0

unused 0 0

system undo header 0 0

CLASS COUNT TIME -

-system undo block 0 0

undo header 0 0

undo block 0 0

14 rows selected This query shows that you have 22 data block waits, but this number doesn’t really mean anything by itself What matters is how long the waits took This is where TIMED_STATISTICS comes in After enabling TIMED_STATISTICS and allowing the system to run for a while, you might come up with these numbers: CLASS COUNT TIME -

-data block 42 205

sort block 0 0

save undo block 0 0

segment header 0 0

save undo header 0 0

free list 0 0

extent map 0 0

bitmap block 0 0

bitmap index block 0 0

unused 0 0

system undo header 0 0

CLASS COUNT TIME -

-system undo block 0 0

undo header 1 1

undo block 0 0 Now the TIME column is populated This column represents the time (in hundredths

of a second) that these specific waits took, so the database has spent 2.05 seconds on data block waits If this number was generated over a period of just a few minutes (rather than a few weeks), you might need to consider some tuning

NOTE There seem to be three camps in regards to setting TIMED_STATISTICS One says

to never set it, because it has a huge performance impact Another camp says to always have it on, because it really is of no performance impact Finally, there is the group that says to enable it when you need it I tend to be a member of the group that says have it on all the time For your own system, I suggest turning it on and measuring its impact If the impact is insignificant, leave it on

Checking the SGA

One of the first things DBAs typically check in a database is the health of the SGA As

a critical database structure, it is rightly the subject of constant concern and scrutiny

You can monitor and tune the SGA from several vantage points The following struc-tures in the SGA should be monitored:

• The database buffer cache

• The library cache in the shared pool

• The data dictionary cache in the shared pool Beyond Simple Database Management

P A R T

III

In the following sections, we’ll look at the various ways to monitor the databaseinstance and improve the numbers you see, if necessary

WARNING Monitoring a database is not without cost Monitoring requires that youinteract with the database, and that interaction takes database resources Constant moni-toring can have a negative effect on the database at times, particularly if the database isalready struggling with performance You must carefully balance the impact of the moni-toring process against the benefits of that monitoring

Monitoring and Tuning the Database Buffer Cache

One of the most commonly referred to numbers in the Oracle DBA world is the base buffer cache hit ratio The database buffer cache is the area of the SGA that stores database data in memory blocks for access by user processes Prior to Oracle8,the database buffer cache consisted of one buffer pool area Starting with Oracle8,Oracle introduced multiple buffer pools The primary buffer pool is referred to as thedefault buffer pool, and you can allocate optional keep and recycle buffer pools Theadvent of multiple buffer pools also introduces the need to calculate the databasebuffer cache hit ratio for all three buffer pools, if you have allocated them

data-The database buffer cache hit ratio represents the percentage of block-read requeststhat were satisfied by a logical read to the database buffer cache A high ratio means thatmore reads from memory (logical reads) took place, and a low ratio means that morephysical reads (from the disk) are required Because logical reads involve reads tomemory and physical reads involve reading from disks, it stands to reason that onewould prefer that logical reads occur rather than physical ones

NOTE The database buffer cache hit ratio, along with the many other ratios touted formonitoring and tuning purposes, is perhaps given a bit too much importance in the overallscheme of things Granted, it is the classical method to use, but it is not the most effective.There are times when ratios can be incorrect For example, certain database operations(such as recursive SQL and rollback segment operations) can artificially increase or reducethe database buffer cache hit ratio Also, the nature of the database (data warehouse ver-sus OLTP) can affect the hit ratio In general, tuning and monitoring wait statistics (dis-cussed in Chapter 17) is a more effective approach

If you want to calculate the database buffer cache hit ratio of any of the bufferpools, you can use this fairly simple formula:

buffer cache hit ratio = 1 – (physical reads) / (memory reads)

To derive the numbers to use in this formula, you can use several methods:

• The V$SYSSTAT view to calculate the hit ratio of the default buffer pool only

• The X$KCBWS and X$KCBWBPD tables to calculate the hit ratio for any buffer pool

• The V$BUFFER_POOL_STATISTICS view to calculate the hit ratio for any buffer pool

The following sections describe how to use these views and tables, and then how

to tune the hit ratio if necessary

Calculating the Hit Ratio for the Default Buffer Pool

To calculate the hit ratio of the default buffer pool, you can use the V$SYSSTAT view

Use two of the V$SYSSTAT view’s columns: the NAME column, which contains thename of the statistic, and the VALUE column, which contains the value of the statistic

You are interested in three different statistics:

• Physical reads, which is the total number of physical reads to the databasedatafiles

• Db block gets, which is the number of blocks in the buffer cache that wereaccessed for INSERT, UPDATE, and DELETE operations

• Consistent gets, which is the number of blocks accessed, using the consistentget mechanism, in the database buffer cache for I/O

Here are a query that uses the V$SYSSTAT view to calculate the hit ratio of thedatabase and its results:

SELECT (1 - (sum(decode(name, ‘physical reads’, value, 0)) /(SUM(DECODE (name, ‘db block gets’, value, 0)) +

SUM(DECODE (name, ‘consistent gets’, value, 0))))) buffer_hit_ratioFROM v$sysstat;

BUFFER_HIT_RATIO -.91295284

So, the hit ratio for this database is 91 percent—not bad, but it probably could bebetter We’ll look at some ways to tune the database buffer hit ratio after exploring theother methods for calculating it

Beyond Simple Database Management

P A R T

III

Calculating the Hit Ratio for Any Buffer Pool

An alternative to using the V$SYSSTAT view is to use two undocumented tables intro-duced in Oracle8i: X$KCBWS and X$KCBWBPD As explained earlier in this chapter, V$ views are created from X$ tables When an appropriate V$ view is not available, you can sometimes use X$ tables

This method can be used to calculate the hit ratio of any of the buffer pools Here

is an example of a query that will provide the hit ratios for all the buffer pools (this particular query works in Oracle release 8.1.6.3 but not 8.1.7.0):

SELECT kcbwbpd.bp_name “Pool Name”, SUM(kcbwds.dbbget) “Block Gets”, SUM(kcbwds.conget) “Consistent Gets”, SUM(kcbwds.pread) “Physical Reads”, (1 - (SUM(kcbwds.pread)+1 ) / ( ( SUM(kcbwds.dbbget) + SUM(kcbwds.conget) + 1) ) ) “Hit Ratio”

FROM x$kcbwds kcbwds, x$kcbwbpd kcbwbpd WHERE kcbwds.set_id >= kcbwbpd.bp_lo_sid AND kcbwds.set_id <= kcbwbpd.bp_hi_sid AND kcbwbpd.bp_size != 0

GROUP BY kcbwbpd.bp_id, kcbwbpd.bp_name ORDER BY 1;

As another alternative, Oracle provides a script called catperf.sql that creates a view called V$BUFFER_POOL_STATISTICS, which will provide the same information

as the preceding query The V$BUFFER_POOL_STATISTICS table provides other buffer pool information in addition to hit ratio statistics, so it’s worth running this script in your database if you are using multiple buffer pools To calculate the hit ratio of your database using V$BUFFER_POOL_STATISTICS, use this query:

SELECT name, ( 1 - (physical_reads) / ( (db_block_gets + consistent_gets))) “Pool Hit Ratio”

FROM v$buffer_pool_statistics WHERE db_block_gets + consistent_gets > 0;

Which will result in the following output:

NAME Pool Hit Ratio

-

-KEEP 1

RECYCLE 1

DEFAULT 8465218

NOTE Due to bug 1491213, the X$KCBWDS table and V$BUFFER_POOL_STATISTICSview queries shown here will not work in Oracle release 8.1.7 This problem is supposed to

be corrected in later releases These queries do work in earlier versions

Tuning the Database Buffer Cache Hit Ratio

The hit ratio can be skewed, either up or down, depending on your database Forexample, if you are running a data warehouse environment, it would not be unusual

to see hit ratios significantly less than 90 percent, especially if a great deal of ad hocquery activity is occurring Still, the better you can tune the hit ratio, the better yourdatabase performance will be

Also, keep in mind that the statistics used to calculate the hit ratio are cumulative,having been gathered since the database was last started You might have an overallhigh hit ratio masking a very low hit ratio of a critical process Fortunately, both theOracle Statspack and the monitoring methodology we describe later in this chapter(in the “Using the Oracle Statspack” and “Introducing a Monitoring Methodology”

sections, respectively) provide a method of seeing the statistics between a specificstarting and ending time

You can do several things to address a low hit ratio The first is simply to add ory resources to the database buffer cache To add memory to the database buffercache, change the DB_BLOCK_BUFFERS parameter in the init.ora file

mem-WARNING Be careful not to increase memory to the point that the operating systemstarts paging memory in and out to disk Paging has serious negative implications on data-base performance To avoid paging, do not allocate more than 40 percent of overall avail-able memory to the SGA If you have multiple databases on the same system, thisbenchmark should be adjusted accordingly For example, if you have ten databases and alarge amount of memory installed on the system, it may be okay to use 50 percent of avail-able memory

If memory is a premium, what else can you do to improve the database buffer cachehit ratio? You can sometimes derive significant performance gains by tuning SQL state-ments, as explained in Chapter 16 By reducing I/O (which is the goal of SQL statementturning), you will reduce the need to access blocks in the SGA, thus reducing the need

to go to disk to collect those blocks Reducing I/O can also reduce latching issues andcontention for blocks by different sessions

Beyond Simple Database Management

P A R T

III

While tuning SQL statements can help, a common misconception is that full tablescans always seriously affect the hit ratio of a database This is only partially true Inreality, full table scans do cause a great deal of physical I/O, but they do not age outthat many blocks in the database buffer cache Therefore, it is unlikely that a hot block(a block that is used often) in a properly allocated SGA will need to be reread from diskbecause of the effects of a full table scan Full table scans are performance hogs for a lot

of reasons, but knocking blocks out of the SGA isn’t usually one of them

NOTE You might be familiar with the DB_BLOCK_LRU_STATISTICS parameter and itsassociated X$KCBRBH table, which allowed the DBA to “simulate” adding or removingmemory from the SGA While this was available in versions as recent as Oracle release8.0.6, it is not available in Oracle8i

Analyzing the Database Buffer Cache

While you’re considering hit ratios, you might want to analyze the database buffercache itself The X$BH view affords this opportunity There is an associated viewcalled V$BH, but there is more information in the X$BH view

TIP To access the X$ tables, you should be logged in a SYS or INTERNAL You can createsynonyms and grant access to these tables to other schemas if you need to

Using the X$BH view, you can determine how many of the allocated blocks arefree, how many are currently in use, and how many have been modified You mightuse this query to get the information:

SELECT decode(state, 0, ‘Unused’, 1, ‘Modified’, 2, ‘Not Modified’,3,’Being Read’,’Other’) dbbc_block_status, count(*)

FROM sys.x$bhGROUP BY DECODE(state, 0, ‘Unused’, 1, ‘Modified’, 2, ‘Not Modified’,3,’Being Read’,’Other’)

Which will result in the following output:

DBBC_BLOCK_S COUNT(*) - -Modified 1451Unused 597

This is just the tip of the iceberg in terms of the information you can derive fromX$BH in Oracle8i Let’s look at a few other ways that you can use this table, whichwill give you some ideas for you own queries.

WARN I NG Neverchange data in an X$ table (usually you can’t anyway) In fact, a

good rule of thumb is that you should never change anything in the SYS schema.

As explained in Chapter 5, midpoint insertion is Oracle’s new method of ling when a block is aged out of the SGA Internally, the aging of a block depends onthe touch count of each buffer As the buffer is used, its touch count is increased Oracleuses a formula to decide if the buffer should be aged out:

control-IF (touch count of buffer > _db_aging_hot_criteria) THENKeep the buffer and increment the touch count

IF (_db_aging_stay_count >= _db_aging_hot_criteria)THEN

half the touch count of the bufferELSE

set the buffer touch count to _db_aging_stay_count

END IF;

ELSEYou may use this bufferEND IF

Notice that the criteria for the hidden parameters used in the formula are _DB_

AGING_HOT_CRITERIA with a default value of 2 and _DB_AGING_STAY_COUNTwith a default value of 0

The advent of the touch count means that you can actually tell which object’s buffersare in the SGA and how often they are used Now you have a way of telling which blocks

of an object are hot and which are not Here is a query that will do just that:

COLUMN tch HEADING “Touch|Count”

SELECT a.owner, a.segment_name, c.file_name, b.dbablk “block”, b.tch FROM dba_extents a, x$bh b, dba_data_files c

WHERE b.file#=c.file_id andb.dbablk >= a.block_idAND b.dbablk <= a.block_id + a.blocksAND b.tch > 0

AND a.owner != ‘SYS’

ORDER BY 5 desc;

Beyond Simple Database Management

P A R T

III

Here are the partial results of this query:

Touch OWNER SEGMENT_NA FILE_NAME block Count

-SCOTT NEWTABLE D:\ORACLE\ORADATA\ORA816\SYSTEM01.DBF 2,240 18

SCOTT NEWTABLE D:\ORACLE\ORADATA\ORA816\SYSTEM01.DBF 2,350 18

SCOTT NEWTABLE D:\ORACLE\ORADATA\ORA816\SYSTEM01.DBF 2,356 18

SCOTT EMPLOYEE D:\ORACLE\ORADATA\ORA816\SYSTEM01.DBF 6,259 17

SCOTT NEWTABLE D:\ORACLE\ORADATA\ORA816\SYSTEM01.DBF 2,357 16

SCOTT NEWTABLE D:\ORACLE\ORADATA\ORA816\SYSTEM01.DBF 2,755 1

SCOTT NEWTABLE D:\ORACLE\ORADATA\ORA816\SYSTEM01.DBF 2,243 1

SCOTT NEWTABLE D:\ORACLE\ORADATA\ORA816\SYSTEM01.DBF 2,244 1

To find out how hot specific tables are, you might craft a query like this: SELECT a.owner, a.segment_name, sum(b.tch) “Sum Touches” FROM dba_extents a, x$bh b WHERE b.dbablk >= a.block_id AND b.dbablk <= a.block_id + a.blocks AND a.owner != ‘SYS’ GROUP BY a.owner, a.segment_name ORDER BY 3 desc; Which will result in the following output: OWNER SEGMENT_NA Sum Touches - -

-SCOTT NEWTABLE 739

SCOTT2 BONUS 520

SCOTT2 SALGRADE 399

SCOTT EMPLOYEE 237

SCOTT2 DUMMY 169

SCOTT2 EMP 46

SCOTT2 DEPT 45

SCOTT DUMMY 13

SCOTT SYS_C00767 5

SCOTT PAY_TABLE 4

SCOTT HOLD_EVENT 3

So, it appears that the NEWTABLE object in SCOTT is a hot table This might imply that you should concentrate on making the queries that access this table more efficient

Monitoring and Tuning the Data Dictionary Cache

In Chapter 5, we reviewed the structures that comprise the SGA One such structure isthe shared pool A component of the shared pool is the data dictionary cache, which

is used to store data dictionary rows in the SGA Much like the database buffer cache,the shared pool has various hit ratios that can be calculated to determine its perfor-mance Here, we will look at the data dictionary cache hit ratio and the dictionarycache miss ratio

Calculating the Data Dictionary Cache Hit Ratio

The formula for calculating the data dictionary cache hit ratio is a bit different fromthat used for the database buffer cache hit ratio Here, you are looking for the ratio ofattempts to get an object from the cache to the number of times you were not able toget the object (and thus, needed to read it from disk) The formula to calculate theratio is as follows:

dictionary cache hit ratio = 1 – ( (# failed attempts to get object) / (# successful block gets + # failed attempts to get block) )

You can get these numbers from the V$ROWCACHE view Use two of this view’scolumns: the GETMISSES column, which represents the number of failed attempts toget the object, and the GETS column, which represents the number of successful gets

This leads to a query and results that look like this:

SELECT (( 1 - (sum(getmisses) / (sum(gets) + sum(getmisses)))) * 100) “Hit Ratio”

FROM v$rowcacheWHERE gets + getmisses <> 0;

Hit Ratio -90.341686

If the hit ratio is less than 95 percent, you probably need to add memory to the

shared pool To do so, increase the SHARED_POOL_SIZE parameter in the database

parameter file (init.ora) Unfortunately, doing so will add memory to the entireshared pool, so it is difficult to the gauge the impact of adding a specific amount ofmemory Note that this ratio will be 0 when the system has started, because there will

be nothing in the data dictionary cache to get

Beyond Simple Database Management

P A R T

III

Calculating the Dictionary Cache Miss Ratios

The dictionary cache miss ratio tells you how often the system went into the nary cache and found what it was looking for You can use the following formula tocalculate the dictionary cache miss ratio:

dictio-dictionary cache miss ratio = dictio-dictionary cache get misses / dictio-dictionary cache gets

To get these numbers, use the GETMISSES and GETS columns in the CACHE view The query to monitor the dictionary cache miss ratio and its resultslook like this:

V$ROW-SELECT (SUM(getmisses)/SUM(gets))*100 “Dict Cache Miss Ratio”

FROM v$rowcache;

Dict Cache Miss Ratio -

17.877095What you want to see for the dictionary cache miss ratio here is a big, fat zero If youare seeing a number more than 10 percent or so, as in the example here, considerincreasing the shared pool There isn’t much more you can do to tune this performance

Monitoring and Tuning the Library Cache

The library cache is where Oracle stores object definitions, SQL statements, and

PL/SQL objects for use in areas called namespaces For monitoring purposes, you’re

interested in the efficiency of the use of the library cache

Library cache misses can occur in either the parse or execute phase of a SQL tion If a parse call is made by an application, and the parsed statement is not already

opera-in the shared pool, Oracle will need to parse the statement, and a library cache misswill result If an application makes an execute call for a SQL statement, it is possiblethat the parsed representation of that statement will have been aged out of the librarycache by another operation In this case, Oracle will reparse the statement before exe-cuting it The first solution to both of these problems is to make sure that you havesufficient memory allocated to the shared pool This is done using the SHARED_POOL_SIZE parameter in init.ora If you are having problems with misses on theparse calls, review your SQL statements for reusability (see Chapter 16 for more onSQL statement tuning)

To monitor the library cache, you are interested in three statistics: the cache hitratio, the cache reload ratio, and the library cache pin hit ratio The queries to retrievethis information use the V$LIBRARYCACHE view As with most dynamic performanceviews, this view provides statistics about the library cache since system startup The

view contains several rows, each of which contains statistics for a type of item kept inthe library cache (SQL, triggers, procedures, and so on)

You also want to monitor the shared pool to determine if the shared pool reservedsize is allocated properly You can find shared pool information in the

V$SHARED_POOL_RESERVED view

Calculating the Library Cache Hit Ratio

The library cache hit ratio is a measure of how often the system finds the librarycache objects already loaded in the cache and how many times the system needs toget them off the disk The formula for calculating the library cache hit ratio is:

library cache hit ratio = # times object found in cache / (# times object found in cache

+ # times object needed to be reloaded from disk)

To calculate the hit ratio, use the V$LIBRARYCACHE view The RELOADS columnrepresents the number of times Oracle went looking for a statement in the librarycache, didn’t find it (or a part of it), and therefore needed to reload it The PINS col-

umn represents the number of times that Oracle tried to pin the object An item must

be pinned in order to be used, and an item can be pinned several times after beinglooked up You want to see that library cache objects are pinned without needing to

be reloaded

The query to monitor the library cache hit ratio and its results look like this:

SELECT SUM(pins) / ( SUM(pins) + SUM(reloads) )

“Lib Cache Hit Ratio”

FROM v$librarycache;

Lib Cache Hit Ratio -

.97988166What you are looking for here is a number close to 100 percent Anything greaterthan 94 percent is fine

Calculating the Library Cache Reload Ratio

The library cache hit ratio measures the overall hit ratio of the library cache Thelibrary cache reload ratio differs from the hit ratio in that it measures the reuse of SQLobjects that have already been in the library cache, aged out, and then reloaded

The library cache reload ratio should be as near to 0 as possible A low cache reloadratio indicates that Oracle did not need to reload any previously loaded library cacheitems (say, for example, a piece of PL/SQL code) If the library cache reload ratio ishigh (say greater than 0.5 to 1 percent, depending on your database), you should

Beyond Simple Database Management

P A R T

III