Tài liệu ORACLE8i- P17 doc

CHAPTER 15 • ORACLE8i PERFORMANCE MONITORING AND DATABASE-LEVEL TUNING 636 TABLE 15.3: COMMONLY USED EVENTS (CONTINUED) Event Code Description Example 10033 Provides details about sorts to disk. ALTER SESSION SET EVENTS ‘10033 trace name context for- ever, level 4’; 10046 ALTER SESSION SET EVENTS ‘10046 trace name context for- ever, level 4’; 10053 ALTER SESSION SET EVENTS ‘10053 trace name context forever, level 1’; 10128 ALTER SESSION SET EVENTS ‘10128 trace name context for- ever, level 1’; 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” To turn off block checking once the database is up and run- ning, issue ALTER SYSTEM SET EVENTS ‘10231 trace name context 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 decided which execution plan to use. Valid level is 1, which gives information on the CBO execution decisions. Used to trace a session. Valid levels are 1 (regular trace), 4 (dump bind variables), 8 (dump wait information), and 12 (dump all). C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 637 As an example, suppose that you want to dump the control file header to see the last checkpoint 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 parameter USER_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, dumping the 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 SET SQL_TRACE=TRUE command. If you want to set an event that always executes when the database starts, you can set it in the database init.ora file. For example, if you want to trace session logons and 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 FOR- EVER parameter means that this event will continue to be reported. If you want to turn this event off, use CONTEXT OFF instead. 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_EV Argument Name Type In/Out Default? SI BINARY_INTEGER IN SE BINARY_INTEGER IN EV BINARY_INTEGER IN LE BINARY_INTEGER IN NM VARCHAR2 IN The first parameter (SI) is the session identifier. The second parameter (SE) is the serial number of the session. The session identifier and the serial number of a session uniquely identify a given user session and can be discovered by querying the V$SES- SION view. The third parameter (EV) is the event number (see Table 15.3). The next parameter (LE) is the level that you wish to set the event to (see Table 15.2). Finally, the last parameter (NM) is the event name (see Table 15.1). This last parameter cannot be NULL, but it may be blank. Depending on the event (again, sometimes it’s a matter SETTING ORACLE EVENTS Beyond Simple Database Management PART III C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 15 • ORACLE8i PERFORMANCE MONITORING AND DATABASE-LEVEL TUNING 638 of trial and error to get the right setting), you may need to enter the last parameter as empty 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. TIP You can set regular error events so that they will cause trace files to be generated when they occur. For example, when a user tries to perform an action that he or she does not have the rights to do, this will generally cause an ORA-1031 to occur. You can set the 1031 event to cause a trace file to be dumped each time that this event occurs: EVENT=”1031 trace 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 to tune 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 the V$ 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 always true. In some cases, dynamic performance views may lag too far behind to provide the timely 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_$ views are the underlying views that you look at when querying the V$ views. C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 639 You might think that you could find the SQL text that comprises the V_$ view in DBA_VIEWS. However, because V$ views are really internal data dictionary views, the method by which they are implemented differs slightly from regular views. Rather than going to the DBA_VIEWS view to find the creation text of the view, you go to V$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 that the 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 system startup. 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 the underlying 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 structures from release to release, so a query that works in Oracle8i may not work in 8i release 2. The queries you see here (many of which were written using Oracle 8.1.6.3) may not work in later versions. Which V$ Views Are for Performance Monitoring? Table 15.4 lists the V$ views that pertain to performance monitoring, along with a brief description of each view. NOTE V$ view statistics are cumulative in nature. They will be reset when the database starts and will accumulate values as the database continues to function. Some of them will even roll over if the database has been running long enough. USING ORACLE8i DYNAMIC PERFORMANCE VIEWS Beyond Simple Database Management PART III C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 15 • ORACLE8i PERFORMANCE MONITORING AND DATABASE-LEVEL TUNING 640 TABLE 15.4: ORACLE V$ VIEWS FOR DATABASE PERFORMANCE MONITORING View Name Description V$DATABASE Describes database information derived from the database control file. You can use this view to join with dynamic perfor- mance views to report on the database name. V$DBFILE Resolves datafile numbers to the name/location of the datafile. You can use this view to join with other dynamic performance views 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 at object memory use, the number of times the object has been loaded, and other information that might indicate that the shared 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 data- base does not become I/O bound. 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 clear archived 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 or not 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 are being run by a specific session. C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 641 TABLE 15.4: ORACLE V$ VIEWS FOR DATABASE PERFORMANCE MONITORING (CONTINUED) View Name Description 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 processing. V$PX_PROCESS_SYSSTAT Contains information about sessions using parallel query processing. V$PX_SESSION Contains information about sessions using parallel query processing. V$RESOURCE_LIMIT Displays information about resource use for certain system resources. 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 is set appropriately. V$SESSION_LONGOPS Displays information on certain long-running database opera- tions. You can use this view to see if any long-running processes 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 being executed. USING ORACLE8i DYNAMIC PERFORMANCE VIEWS Beyond Simple Database Management PART III C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 15 • ORACLE8i PERFORMANCE MONITORING AND DATABASE-LEVEL TUNING 642 TABLE 15.4: ORACLE V$ VIEWS FOR DATABASE PERFORMANCE MONITORING (CONTINUED) View Name Description 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 moni- toring. For a comprehensive list of dynamic performance views, refer to Appendix H or query the Oracle8i V$FIXED_VIEW_DEFINITION table. We recommend monitoring the following database information using the V$ views: • Various SGA hit ratios, including the database buffer cache and the various shared 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 cer- tain structures can impact system performance (V$DB_OBJECT_CACHE, V$SGA, and V$SGASTAT) • Latching and waiting (V$LATCH, V$LATCH_CHILDERN, and V$LATCH_MISSES) • Efficiency of SQL statements, because inefficient SQL can cause performance problems (V$SQLAREA and V$SQL) • Potential internal database problems, such as a segment unable to extend or rollback segments that are not as efficient as they could be (V$ROLLSTAT) • Long-running database operations, which can negatively impact overall data- base operations such as index rebuilds and some SQL operations (V$SESSION_LONGOPS) C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 643 In this chapter, we’ll build scripts using several V$ performance views to monitor various 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-related statistics on various operations. Be aware that this collection effort has some overhead associated 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 for that release. Later releases don’t have the problem. If you are using release 8.1.5, make sure 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 the TIMED_STATISTICS parameter: • V$FILE_STAT • V$SESSION_EVENT • V$SESSION_WAIT • V$SYSTEM_EVENT • V$TEMPSTAT • V$WAITSTAT USING ORACLE8i DYNAMIC PERFORMANCE VIEWS Beyond Simple Database Management PART III C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 15 • ORACLE8i PERFORMANCE MONITORING AND DATABASE-LEVEL TUNING 644 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 C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 645 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 CHECKING THE SGA Beyond Simple Database Management PART III C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [...]... database and its results: 648 CHAPTER 15 • ORACLE8i PERFORMANCE MONITORING AND DATABASE-LEVEL TUNING Calculating the Hit Ratio for Any Buffer Pool An alternative to using the V$SYSSTAT view is to use two undocumented tables introduced 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... Management t.chncnt = 0 AND 670 CHAPTER 15 • ORACLE8i PERFORMANCE MONITORING AND DATABASE-LEVEL TUNING Here is the resulting output from the query: OWNER TABLE_NAME DENSITY POR_OWN SSEPDOCUMENT 74.56% POR_OWN SSEPMESSENGER 28.65% POR_OWN SSEPOBJECTREPOS 73.36% POR_OWN SSEPPROFILE 66.11% POR_OWN SSEPRELATIONSHIPS 72.05% POR_OWN SSEPTEMPLATELOOKUP 82.46% POR_OWN SSEPTRANSLOG 88.89% POR_OWN . 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