Tài liệu ORACLE8i- P19 docx

CHAPTER 16 • ORACLE8i SQL PERFORMANCE MONITORING AND TUNING 716 And here are the results: TABLE_NAME PCT_FREE PCT_USED EMPLOYEE 1 1 It’s pretty obvious that the problem is that the block storage settings have been very badly done indeed. 3. Let’s fix the block storage parameters with an ALTER TABLE command: ALTER TABLE employee PCTFREE 20 PCTUSED 40; Of course, you will set your PCTFREE and PCTUSED values based on the velocity and nature of changes to the table. 4. Having fixed the table’s block storage parameters, we now move the chained rows from the EMPLOYEE table to a temporary table called TEMP_EMP. (This temporary table is not a global temporary table, mind you, but one we’ll create simply to populate this data. Afterward, we’ll remove the table.) Here is the SQL statement for this operation: CREATE TABLE temp_emp AS SELECT * FROM employee WHERE rowid IN (select head_rowid from chained_rows); NOTE Note that we don’t use a “real” temporary table for this table because we don’t want to accidentally lose this data should the database crash or the session fail. Core dumps always happen when they are the most inconvenient, don’t you think? TIP Of course, in creating your own TEMP_ table, you may want to add STORAGE clauses, TABLESPACE clauses, and the like, but for our purposes here we’ve not done so. The CREATE TABLE…AS SELECT… command (CTAS) is very useful for operations such as this. It allows us to create a table using another table as a template, and then will even populate the table for us. Notice the subquery that selects from the EMPLOYEE table all the rows based on the ROWIDs stored in the CHAINED_ROWS table. 5. Before we continue, please raise your right hand and repeat after me: “I will back up my database, or at least the object I’m removing chained rows from, before I do the next step. I promise, so help me, Codd.” C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 717 6. Having done the necessary backup (you did keep your promise, didn’t you?), you’re ready to delete records. First clear the offending chained rows from the EMPLOYEE table: DELETE FROM employee WHERE rowid in (select head_rowid from chained_rows); COMMIT; 7. Insert the rows from the TEMP_EMP table to repopulate the EMPLOYEE table with the chained rows that were deleted: INSERT INTO employee SELECT * FROM temp_emp; 8. All that remains is to make sure the number of rows in the table is correct, and that there are no chained rows remaining. To do this, ANALYZE the table again, and then run the same checksum query as before (step 1): ANALYZE TABLE employee COMPUTE STATISTICS; SELECT a.table_name, a.chain_cnt, b.emp_count, a.chain_cnt/b.emp_count From user_tables a, (select count(*) emp_count from employee) b Where a.table_name=’EMPLOYEE’; The results of this query are: TABLE_NAME CHAIN_CNT EMP_COUNT A.CHAIN_CNT/B.EMP_COUNT EMPLOYEE 0 32014 0 9. It appears we still have 32,014 rows in the table, and our chain count is now 0. All systems go. Complete the process by dropping the temporary table you created. Histograms: Analyzing Data Distribution Sometimes column data in a table is skewed so that one or two values make up a sig- nificant percentage of the values in the column of the table. This may cause fluctuat- ing query performance on that table. When you access the table looking for a value (such as NO) that is present in a great percentage of the rows, using an index to do that lookup will not be very efficient. Likewise, if the value NO shows up only once in the column and the table is very large, an index lookup will certainly be preferable to a full table scan. Unfortunately, the normal statistics Oracle generates don’t provide a table data view that is wide enough that we can determine whether a specific query would bene- fit from an index or a full table scan. The normal statistics do track the number of dis- tinct values in the table, but they do not track the distribution of those values. In THE ORACLE OPTIMIZER 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 16 • ORACLE8i SQL PERFORMANCE MONITORING AND TUNING 718 Oracle 7.3, histograms were introduced in an effort to correct this omission. His- tograms are performance enhancers in cases where data values in a column are skewed and some imbalance exists. If the data is not skewed, histograms will likely not help performance. You create histograms via the ANALYZE command, for both tables and indexes. An example of creating a histogram on the DEPT column in the EMPLOYEE table would look something like this: ANALYZE TABLE EMPLOYEE COMPUTE STATISTICS FOR COLUMNS Deptno SIZE 10; A histogram has a fixed width, but variable height. The width of the histogram is measured in “buckets.” The histogram we just created, then, will be 10 buckets long and will remain 10 buckets long forever unless we re-create it. The height of the his- togram is balanced along the width of the bucket. Thus every bucket has an equal number of rows. TIP If you are using bind variables in your SQL (which is good), Oracle will not be able to use histograms when generating the execution plan. Now you can examine one of the data dictionary views and find information on the histograms you’ve created for the EMPLOYEE table. Table 16.3 lists the primary views that contain histogram information. TABLE 16.3: DATA DICTIONARY VIEWS THAT PERTAIN TO HISTOGRAMS View Name Histogram Information Provided *_PART_HISTOGRAMS Partitions in a partitioned table *_SUBPART_HISTOGRAMS Table subpartitions *_TAB_HISTOGRAMS Nonpartitioned tables INDEX_HISTOGRAM Any index analyzed with ANALYZE INDEX…VALIDATE STRUCTURE * These views will be prefixed with ALL, USER, or DBA. C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 719 Analyzing with Oracle Supplied Packages In addition to the ANALYZE command, you can use one of the Oracle-supplied pack- ages to analyze the database. Here we’ll briefly look at these Oracle packages that per- form the same actions as the ANALYZE command. For a complete listing of their parameters, see Appendix D. Using these packages in many cases can be easier than running the ANALYZE command. For example, you can analyze the entire database or an entire schema, a process that otherwise would require the issuance of a great num- ber of ANALYZE commands. DBMS_UTILITY.ANALYZE_DATABASE The DBMS_UTILITY.ANALYZE_DATABASE procedure analyzes the entire database, with the exception of data dictionary objects. Following is an example of a statement to run the procedure: Exec DBMS_UTILITY.ANALYZE_DATABASE(‘ESTIMATE’, estimate_rows=>1000); This example will analyze the entire database except for SYS objects. Each object in the database will be analyzed using 1000 as the number of rows to scan to generate esti- mated statistics. You can also compute database statistics when using this procedure. DBMS_UTILITY.ANALYZE_SCHEMA The DBMS_UTILITY.ANALYZE_SCHEMA procedure analyzes a specific schema in the database. In the following example: Exec DBMS_UTILITY.ANALYZE_SCHEMA (’SCOTT’,’ESTIMATE’, estimate_rows=>1000); the SCOTT schema is analyzed. The procedure does an ESTIMATE scan, using 1000 as the number of rows to scan to generate the estimated statistics. You can also choose to compute statistics for all objects in the schema. DBMS_DDL.ANALYZE_OBJECT The DBMS_DDL.ANALYZE_OBJECT procedure analyzes a specific object in the data- base. Note that this procedure allows you to analyze a partition in an object, whether that object is a partitioned table or a partitioned index. Here’s an example of running the DBMS_DDL.ANALYZE_OBJECT procedure: Exec DBMS_UTILITY.ANALYZE_OBJECT (‘TABLE’, ‘SCOTT’, ’EMPLOYEE’, ’ESTIMATE’, estimate_rows=>1000); This call will analyze the EMPLOYEE table in the SCOTT schema. It will use 1000 rows to estimate the table statistics. THE ORACLE OPTIMIZER 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 16 • ORACLE8i SQL PERFORMANCE MONITORING AND TUNING 720 DBMS_UTILITY.ANALYZE_PART_OBJECT The DBMS_UTILITY.ANALYZE_PART_OBJECT procedure analyzes a partition of a spe- cific partitioned object in the database. An example of running this procedure would be as follows: Exec DBMS_UTILITY.ANALYZE_PART_OBJECT (‘TABLE’, ‘PART_TAB’, ’T’, ’E’,sample_clause=>’SAMPLE 10 PERCENT’); This will analyze the partitioned table SCOTT, using the ESTIMATE method of analyz- ing the partitioned table, and using a sample of 10 percent of the rows when analyzing the partition. Oracle Execution Plans The “bottom line” output of the optimizer is the execution plan—the heart of a SQL statement’s operation. The execution plan is Oracle’s plan of attack for getting the data you request with your SELECT statements. In this section we show you how to get your hands on the execution plans of your SQL statements, and even those of other users’ SQL running in your system. You’ll learn how to read a SQL statement’s execution, so you can know how you’re getting your data. All of this is in preparation for tuning your SQL statement so it runs like a greased monkey on fire. (Apologies to PETA. No animals were injured in the making of this book.) Generating SQL Execution Plans Before you can read and interpret an execution plan, you must first generate the plan via any of the following methods: • Use TKPROF to analyze the session’s trace file and generate execution plans. • Use the AUTOTRACE command in SQL*Plus. • Use the EXPLAIN PLAN command to generate the execution path for a given SQL statement. Tracing Oracle Sessions and TKPROF One method of generating execution plans for SQL statements is to trace the user ses- sion in which the statement is running. Once you have traced the session, you use the Oracle utility TKPROF to format the trace file into a more readable format. You set a flag in TKPROF so that it will generate an execution plan for each SQL statement C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 721 that’s run. Let’s first look at the process for tracing your Oracle session, and then we’ll generate a report on the resulting trace file using TKPROF. Tracing Your Session To trace a session in which you’ll execute a SQL statement (including execution of any PL/SQL program units), issue the command ALTER SESSION SET SQL_TRACE=TRUE; Oracle will create a trace file in the user_dump_dest directory that is defined in the init.ora parameter file. Table 16.4 shows other database parameters that affect tracing. TABLE 16.4: INIT.ORA PARAMETERS THAT AFFECT TRACING Parameter Name Description USER_DUMP_DEST This is the directory for user-directed dumps on a database. You can change this parameter dynamically with either the ALTER SYSTEM or ALTER SESSION command. TIMED_STATISTICS Allows timing statistics to be enabled (see Chapter 15). MAX_DUMP_FILE_SIZE Defines the maximum size of the trace file. SQL_TRACE Enables the Oracle trace facility. Can be turned on for a session with ALTER SESSION or database-wide with ALTER DATABASE. WARNING Although it is possible to do so, setting TRACE on for the entire database can have negative effects on system performance. You can usually do what you need to do by tracing a session rather than the database. You can find the specific location of the user_dump_dest directory by querying V$PARAMETER: SELECT name, value FROM v$parameter WHERE name = ’user_dump_dest’; The name of the trace file on a Unix system is typically in this form: {db_name}_ora_{spid}.ora ORACLE EXECUTION PLANS 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 16 • ORACLE8i SQL PERFORMANCE MONITORING AND TUNING 722 where db_name is the name of the database, and spid is the operating system process identifier (SPID) value from V$PROCESS for the session being traced. Thus, a trace file’s name might look like ora8i_ora_1102.trc on Unix for a database called ora8i and for a session with a SPID of 1102. On NT the filename format is a bit different: {db_name}{spid}.ora where db_name is the name of the database, and spid is the SPID value from V$PROCESS for the session being traced. The SPID is zero filled to five digits. (Before Oracle8i you had to do some pretty wild conversions to get the right trace filename, but this is no longer true.) NOTE As always with Oracle, anything can change. The naming convention of trace files is not documented all that well, and may change in subsequent releases. Using TKPROF to Reformat the Trace File Once the trace file has been generated and you have completed the execution of the SQL statements on which you want to see the executions plans, you’ll run the TKPROF utility. TKPROF reads the trace file and formats and sorts it into a friendlier format. For the entire session traced, TKPROF output provides • Total counts for parse, execute, and fetch operations • Total CPU and elapsed time for parse, execute, and fetch operations • Cumulative disk I/O statistics for parse, execute, and fetch operations • Total number of rows processed by the session For each individual statement execution, TKPROF provides • Total counts for parse, execute, and fetch operations for that statement • Total CPU and elapsed time for parse, execute, and fetch operations for that statement • Cumulative disk I/O statistics for parse, execute, and fetch operations for that statement • Total number of rows processed for that session • Optimizer goal used for the query • Number of library cache misses encountered by the query C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 723 • An execution plan for each SQL statement executed (if the EXPLAIN parameter of TKPROF is used) Following is the syntax for the TKPROF command, and Table 16.5 lists its command- line parameters: TKPROF tracefile outputfile [explain= ] [table= ] [print= ] [insert= ] [sys= ] [sort= ] TABLE 16.5: TKPROF COMMAND-LINE PARAMETERS Parameter Description AGGREGATE={YES/NO} The default YES causes identical SQL statements to be shown only once in the report, and the overall run statistics are com- bined. Setting aggregate to NO causes identical SQL state- ments to be shown individually. EXPLAIN=USER/PASSWORD Creates an execution plan for each SQL statement executed, using the schema selected for the plan. Selected schema must have the CREATE SESSION system grant and have access to the objects accessed during SQL statement execution. FILENAME ONE The trace to be formatted. FILENAME TWO The output file that will contain the formatted TKPROF results. INSERT={filename} Causes TKPROF to create a SQL script called filename that contains commands to create a database table. TKPROF then populates the script with INSERT statements that will cause the trace file statistics to be INSERTed into the created table. PRINT={n} Lists only the first n SQL statements. The default is to print all statements. RECORD={file_name} Creates a SQL script that contains all nonrecursive SQL exe- cuted by the session so it is available for replay if desired. SORT {options} Sorts the SQL statements on the options specified. Valid options: EXECNT = By number of execute calls made EXECPU = By CPU execution time spent EXECU = By number of buffers for current read during execute EXEDSK = By number of disk reads during execute EXEELA = By elapsed execution time EXEMIS = By number of library cache misses during execute EXEQRY = By number of buffers for consistent read during execute ORACLE EXECUTION PLANS 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 16 • ORACLE8i SQL PERFORMANCE MONITORING AND TUNING 724 TABLE 16.5: TKPROF COMMAND-LINE PARAMETERS (CONTINUED) Parameter Description EXEROW = By number of rows processed during execute FCHCNT = By number of times fetch was called FCHCPU = By CPU fetch time spent FCHCU = By number of buffers for current read during fetch FCHDSK = By number of disk reads during fetch FCHELA = By elapsed fetch time FCHQRY = By number of buffers for consistent read during fetch FCHROW = By number of rows fetched PRSCNT = By number of times parse was called PRSCPU = By CPU parse time spent PRSCU = By number of buffers for the current read during parsing PRSDSK = By number of disk reads during parsing PRSELA = By elapsed parsing time PRSMIS = By number of misses in library cache during parsing PRSQRY = By number of buffers for consistent read during parsing USERID = Sort by the USERID of user who parsed the cursor SYS={YES/NO} Enables (default) and disables the inclusion of SQL state- ments that are issued by SYS in the TKPROF output file, including recursive SQL or any statement executed by SYS. This parameter has no effect on the output to the SQL file created by use of the INSERT parameter. TABLE={schema.table_name} Directs TKPROF to load execution plans temporarily into an alternate table. (By default, TKPROF uses PROF$PLAN_TABLE.) TKPROF will create, use, and remove the alternate table if it does not exist. If the alternate table does exist, TKPROF will delete any existing rows in that table and then populate it. C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 725 About Setting TIMED_STATISTICS You’ll notice that some information reported in trace files and in the ultimate TKPROF output from those trace files (as well as in execution plans generated using SET AUTO- TRACE ON) is dependent on the TIMED_STATISTICS parameter being enabled in the database init.ora file. This is because TIMED_STATISTICS provides elapsed-time infor- mation for each operation that is being traced. There is a great deal of contention over the advisability of leaving TIMED_STATISTICS enabled all the time. The truth is that there is not that much overhead associated with having it set this way. The benefits are significant, and leaving the parameter enabled provides the DBA with additional information for database tuning. Finally, note that TIMED_STATISTICS is a dynamic parameter; it can be turned on or off using either the ALTER SYSTEM or ALTER SESSION commands. Output Generated by TKPROF Let’s look at an example from the wealth of information provided by TKPROF. The trace file you use will be generated by a session that issued just one query: SELECT COUNT(*) FROM employee; Once you have the trace file, you process it with TKPROF. For this sample, we have used the following TKPROF command line: TKPROF ora00104.trc traceout.txt explain=scott/tiger sys=no This command causes TKPROF to process the trace file ora00104.trc and create an output file called traceout.txt. Using the EXPLAIN parameter, we instructed TKPROF to create execution plans (which is what we are after in this chapter). Finally, using SYS=NO, we instructed Oracle to remove all SYS queries, which includes any recursive SQL. Listing 16.1 shows the output trace file, including the execution plan. Listing 16.1: TKPROF Output File TKPROF: Release 8.1.6.0.0 - Production on Fri Dec 29 23:51:07 2000 (c) Copyright 1999 Oracle Corporation. All rights reserved. Trace file: ora00104.trc Sort options: default *********************************************************************** ORACLE EXECUTION PLANS 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.