Presentation is loading. Please wait.

Presentation is loading. Please wait.

SQL Tuning For Developers Brian Hitchcock OCP 8, 8i, 9i DBA Sun Microsystems DCSIT Technical Services DBA Brian.

Similar presentations


Presentation on theme: "SQL Tuning For Developers Brian Hitchcock OCP 8, 8i, 9i DBA Sun Microsystems DCSIT Technical Services DBA Brian."— Presentation transcript:

1 SQL Tuning For Developers Brian Hitchcock OCP 8, 8i, 9i DBA Sun Microsystems brian.hitchcock@sun.com brhora@aol.com DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 1 www.brianhitchcock.net

2 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 2 www.brianhitchcock.net SQL Tuning A very large and complex topic Lots of information available Cover commonly used tools – How to use, output of each for sample SQL Not covering GUI tools – Toad, enterprise manager

3 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 3 www.brianhitchcock.net Assumptions You can get the SQL statements – 3 rd party apps – User generated SQL – Forms – Web pages How will you get the SQL to test? – Tracing – Statspack You are using 9i

4 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 4 www.brianhitchcock.net SQL Statement Execution Parsing – Valid statement – Dictionary lookups, table and column definitions – Privileges on db objects – Optimal query plan Rule, fixed set of rules define access Cost, minimal blocks accessed – Load into shared pool (if not there already) – Bind variables Execution Return rows

5 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 5 www.brianhitchcock.net SQL Performance Factors Machine – OS resources for db and other apps on machine Init.ora parameters – Db_cache_size, many others Size of database – How much data does SQL have to look at – Performance varies from Dev, QA, Production Database version – Optimizer enhancements, compatibility=?

6 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 6 www.brianhitchcock.net SQL Performance Factors Client – Lots of data returned takes time to move to client User load – How many users, different SQLs running at once – Performance varies from Dev, QA, Production Optimizer – Cost based, rule based Hints – Influence the optimizer

7 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 7 www.brianhitchcock.net SQL Performance Factors Indexes – Best possible? – Can be used by optimizer? Statistics (for Cost Based Optimizer) – Accurate? SQL itself – Using indexes?

8 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 8 www.brianhitchcock.net Writing Better SQL? Better means faster How to make SQL faster? – Access fewer data blocks From disk From memory (db_cache) – Request less data More specific where clause Dont request data you wont use – Parse less often Reuse SQL Bind variables PL/SQL packages pinned in memory

9 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 9 www.brianhitchcock.net Achieving Better SQL? Access fewer data blocks – Reduce physical IO – Reduce logical IO – More selective index(es) Request less data – More specific where clause Select … from … where id= – Dont request data you wont use Siebel default configuration, requests large amounts of data to populate unused screens Overall SQL performance – All SQL for all users? For some users?

10 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 10 www.brianhitchcock.net Achieving Better SQL? Parse less often – Reuse SQL Application users send same set of SQL to db – Bind variables Oracle parses once, stores in library cache Supports SQL reuse – PL/SQL packages App SQL in packages App users all call same packages Pl/SQL packages pinned in memory

11 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 11 www.brianhitchcock.net Oracle Optimizer Decides how to execute a query What order tables are accessed Which indexes for each table When to re-write queries When table scan is better than index

12 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 12 www.brianhitchcock.net Oracle Optimizer Rule Based Optimizer (RBO) – Older, some say better – Not being enhanced anymore – optimal plan based on rigid rankings – Removed in 10g Cost Based Optimizer (CBO) – Optimal plan based on computed costs – Newer, officially better – All optimizer improvements are to CBO

13 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 13 www.brianhitchcock.net Rule Based Ranking – Single Row by Rowid – Single Row by Cluster Join – Single Row Hash Cluster Key with Unique or Primary Key – Single Row by Unique or Primary Key – Clustered Join – Hash Cluster Key – Indexed Cluster Key – Composite Index – Single-Column Indexes – Bounded Range Search on Indexed Columns – Unbounded Range Search on Indexed Columns – Sort Merge Join – MAX or MIN of Indexed Column – ORDER BY on Indexed Column – Full Table Scan

14 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 14 www.brianhitchcock.net Cost Based Optimizer Evaluates possible execution plans – Computes cost of each plan Number of blocks accessed Selectivity of indexes – Chooses lowest cost (do you believe?) Issues – Many possible plans to evaluate 20 table join, how many permutations? – How CBO works not always clear – Depends on good statistics

15 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 15 www.brianhitchcock.net CBO and Statistics CBO computes cost – Relies on the statistics it has Statistics – Tables, number of rows, average length of row – Indexes, number of entries per leaf block – Generated by Analyze table or dbms_stats Computing statistics affects performance – Old statistics, CBO makes poor choices – Computing statistics takes time

16 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 16 www.brianhitchcock.net Bind Variables Support shared SQL – Good for performance Optimizer doesnt know exact values – Cant determine cost of indexes etc. – Assumes a default data distribution – Can lead to sub-optimal execution plan Are they worth it overall? – Yes, most of the time

17 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 17 www.brianhitchcock.net Optimizer Modes Controlled by – Init.ora parameter optimizer_mode Choose (default) All_rows First_Rows_n First_Rows Rule

18 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 18 www.brianhitchcock.net Optimizer Modes Choose – Default – If statistics exist for at least one table Use CBO Guess data distribution for tables with no statistics If no statistics, use RBO Goal is best throughput

19 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 19 www.brianhitchcock.net Optimizer Modes All rows – Use CBO – Guess table statistics as needed – Goal is best throughput First_Rows_n – Use CBO – Guess table statistics as needed – Goal is best response time for first n rows

20 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 20 www.brianhitchcock.net Optimizer Modes First_Rows – Use mix of CBO and RBO – Guess table statistics as needed – Goal is best response time for first few rows – Provided for backward compatibility Rule – RBO used – Presence of statistics doesnt matter – Doesnt exist in 10g – Note, other factors can cause CBO even with Rule…

21 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 21 www.brianhitchcock.net CBO Required Even if optimizer_mode=rule – Partitioned tables and indexes – Index-organized tables – Reverse key indexes – Function-based indexes – Parallel query and parallel DML – Star transformations and star joins – Query rewrite with materialized views – Hash joins – Bitmap indexes and bitmap join indexes

22 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 22 www.brianhitchcock.net Hints Added to SQL statement Affect optimizer choices – Control execution plan selected Oracle docs tell us – Hints force optimizer to use specified behavior – Not always true – May only influence optimizer

23 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 23 www.brianhitchcock.net Hints You can use hints to specify the following: – The optimization approach for a SQL statement – The goal of the cost-based optimizer for a SQL statement – The access path for a table accessed by the statement – The join order for a join statement – A join operation in a join statement Hints are extra code that must be managed, checked, and controlled Taken from Oracle9i Database Performance Tuning Guide and Reference Release 2 (9.2) Part Number A96533-02

24 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 24 www.brianhitchcock.net Hints Hints provide a mechanism to direct the optimizer to choose a certain query execution plan based on the following criteria: – Join order – Join method – Access path – Parallelization Hints (except for the RULE hint) invoke the cost- based optimizer (CBO) If you have not gathered statistics, then defaults are used. Taken from Oracle9i Database Performance Tuning Guide and Reference Release 2 (9.2) Part Number A96533-02

25 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 25 www.brianhitchcock.net Hints and Their Usage Good – Can force specific execution Not really, they encourage… – Takes resources to determine the correct hint Is this worth it? Bad – If in place and things change DBMS version, compatibility=? Data volume, fragmentation Performance can suffer – Maintenance overhead Who knows they are there? Who knows why they are there?

26 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 26 www.brianhitchcock.net Hints Syntax must be exactly correct – {DELETE|INSERT|SELECT|UPDATE} /*+ hint [text] [hint[text]]... */ or – {DELETE|INSERT|SELECT|UPDATE} --+ hint [text] [hint[text]]... If syntax isn t correct – Optimizer ignores hint – Does not return an error – Can be very frustrating

27 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 27 www.brianhitchcock.net Hints Example SQL> alter session set optimizer_mode=choose; Session altered. SQL> truncate table plan_table; Table truncated. SQL> explain plan set Statement_Id = 'TEST' for select /*+ RULE */ count(*) from bigtable_1; Explained. SQL> select * from table(dbms_xplan.display); PLAN_TABLE_OUTPUT ----------------------------------------------------------------------------------------- | Id | Operation |Name | Rows | Bytes | Cost | ----------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | | | 1 | SORT AGGREGATE | | | | | | 2 | TABLE ACCESS FULL | BIGTABLE_1 | | | | | ----------------------------------------------------------------------------------------- Note: rule based optimization 10 rows selected.

28 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 28 www.brianhitchcock.net Specific Hints Available Hints for Optimization Approaches and Goals ALL_ROWS FIRST_ROWS(n) CHOOSE RULE Hints for Join Orders ORDERED STAR

29 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 29 www.brianhitchcock.net Specific Hints Available Hints for Access Paths FULL ROWID CLUSTER HASH INDEX INDEX_ASC INDEX_COMBINE INDEX_JOIN INDEX_DESC INDEX_FFS NO_INDEX AND_EQUAL

30 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 30 www.brianhitchcock.net Specific Hints Available Hints for Query Transformations – USE_CONCAT – NO_EXPAND – REWRITE – EXPAND_GSET_TO_UNION – NOREWRITE – MERGE – NO_MERGE – STAR_TRANSFORMATION – FACT – NO_FACT

31 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 31 www.brianhitchcock.net Specific Hints Available Hints for Join Operations – USE_NL – USE_MERGE – USE_HASH – DRIVING_SITE – LEADING – HASH_AJ, MERGE_AJ, and NL_AJ – HASH_SJ, MERGE_SJ, and NL_SJ

32 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 32 www.brianhitchcock.net Specific Hints Available Hints for Parallel Execution – PARALLEL – NOPARALLEL – PQ_DISTRIBUTE – PARALLEL_INDEX – NOPARALLEL_INDEX

33 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 33 www.brianhitchcock.net Specific Hints Available Additional Hints – APPEND – NOAPPEND – CACHE – NOCACHE – UNNEST – NO_UNNEST – PUSH_PRED – NO_PUSH_PRED – PUSH_SUBQ – NO_PUSH_SUBQ – ORDERED_PREDICATES – CURSOR_SHARING_EXACT – DYNAMIC_SAMPLING

34 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 34 www.brianhitchcock.net When Indexes Are Not Used I.e. not selected by the optimizer When this is correct – Retrieving more than 20% of table – Index is not very selective, needed rows are spread out When this isnt good – function prevents good index from being used – Bind variables, optimizer cant evaluate indexes correctly

35 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 35 www.brianhitchcock.net Function Based Index Creates index on function applied to column Why good – Normally, index on a column not used if SQL has function on the column Why bad – More indexes to maintain – Do you know which functions used in your SQL?

36 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 36 www.brianhitchcock.net Index Organized Table Table, but – Rows stored in order of primary key Dont have table and index – Just the IOT Why good – Faster for exact match or index range scan Why bad – Primary key ordering not optimal for all queries

37 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 37 www.brianhitchcock.net What We Need to Know SQL statements – That are executing – What resources are used – Measure performance Quantify affects of – SQL changes – Database changes Init.ora parameters New indexes Reorganization

38 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 38 www.brianhitchcock.net Tools for Developers SQL*Plus Explain Plan Trace Tkprof autotrace 10046 SQL trace (extended SQL tracing) Statspack OS monitoring Wait States SQL diagram-based tuning

39 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 39 www.brianhitchcock.net Tools for Developers Lots of overlap Get same data multiple ways Personal preference May depend on access level – SQL*Plus, only need app user access – Trace files, need OS access to db machine Dont have to use all of them

40 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 40 www.brianhitchcock.net SQL*Plus Set timing on Dont always trust this – If lots of rows returned to your screen – Time includes time to paint data to your screen – 10046 trace file timing info very accurate Show time for parse, fetch separate from all other parts of the processing Change SQL, execute, new timing data

41 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 41 www.brianhitchcock.net Explain Plan Shows the execution plan that will be used – Actual plan may be different Bind variables Data changes – 10046 trace file shows actual explain plan used – Generate with or without bind variable values Without, optimizer assumes a data distribution May not be optimal plan

42 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 42 www.brianhitchcock.net Trace While one or more queries executing Reports statistics on what the query is doing Output sent to a trace file – User_dump_dest – Trace file name can be cryptic Output hard to read Use tkprof to format trace file Can trace all activity in database – Not recommended

43 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 43 www.brianhitchcock.net tkprof Used to format trace files – Make them readable Sort trace file information by – CPU time – Disk reads – Number rows returned For each SQL executed – Reports statistics – Generates explain plan

44 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 44 www.brianhitchcock.net autotrace For each SQL executed – Shows logical and physical IO for the last SQL – Rows processed – Generates explain plan Use with set timing on – Timing info not accurate – Time to generate statistics included Combination of trace and tkprof – Easy way to document as you test changes

45 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 45 www.brianhitchcock.net Real World For tkprof, autotrace output First time executed – SQL may need data blocks not in memory Run SQL several times – Watch physical reads go down Elapsed time for initial run – Not typical of well tuned, stable database – Worst case

46 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 46 www.brianhitchcock.net 10046 Trace Flag For each statement executed – Generates trace file – Detailed statistics about each step of execution – Shows the explain plan actually used – Shows wait states during execution Generates lots of output Output can be hard to use – But very valuable

47 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 47 www.brianhitchcock.net STATSPACK Gathers performance data for whole database Captures SQL being executed Shows which SQL are – Using most IO – Executed most often – Taking most CPU time Shows overall performance Good way to document as you make changes

48 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 48 www.brianhitchcock.net OS Monitoring? OS level bottlenecks If you have very long running SQL UNIX utilities – Prstat –n 15 5 999 Shows top 15 processes – Iostat –xnp 5 999 IO statistics for all filesystems – Vmstat –S 5 999 Virtual memory, swap in/out – Mpstat 5 999 CPU usage of each individual CPU

49 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 49 www.brianhitchcock.net Wait States While SQL is running Look at wait states for active sessions Shows waits right now If SQL running slowly – See what it is waiting for Simple SQL to see current session waits STATSPACK provides cumulative wait data

50 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 50 www.brianhitchcock.net SQL Diagram Tuning Diagram SQL statement Compute the best execution plan Use to verify optimizer choice Use to determine hint(s) needed OReilly book SQL Tuning, Dan Tow Details of method beyond this presentation

51 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 51 www.brianhitchcock.net Making Things Better Overall – Reduce the amount of data you process – Eliminate as many rows as possible As soon as possible Earlier in explain plan More selective where clause More selective indexes

52 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 52 www.brianhitchcock.net Examples SQL*Plus Explain Plan Trace Tkprof autotrace 10046 SQL trace (extended SQL tracing) Statspack OS monitoring Wait States

53 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 53 www.brianhitchcock.net Example Tables, Indexes create table BIGTABLE_1 (x number); (10,000 values inserted) create index bigtable_ind_1 on bigtable_1 (x); create table BIGTABLE_2 (a VARCHAR2(2), x number); (100,000 values inserted) create index bigtable_ind_2 on bigtable_2 (a, x);

54 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 54 www.brianhitchcock.net SQL*Plus Gather timing data – Sqlplus / @ – Set timing on – – Timing data is displayed – Spool file Document affect of SQL and/or db changes ­Different index ­Change init.ora parameter(s)

55 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 55 www.brianhitchcock.net SQL*Plus SQL> set timing on SQL> select count(*) from bigtable_1; COUNT(*) ---------- 10000 Elapsed: 00:00:00.01 SQL> select count(*) from bigtable_2; COUNT(*) ---------- 100000 Elapsed: 00:00:00.11 SQL> select a from bigtable_2 where x=1000; A -------- A Elapsed: 00:00:00.14 SQL> select a from bigtable_2 where a='A' and x=1000; A -------- A Elapsed: 00:00:00.01

56 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 56 www.brianhitchcock.net Explain Plan Examples select * from bigtable_2; -------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost | -------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 100K| 488K| 7 | | 1 | TABLE ACCESS FULL | BIGTABLE_2 | 100K| 488K| 7 | -------------------------------------------------------------------- select a from bigtable_2 where x= 2 1000; ------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost | ------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 1 | 5 | 2 | |* 1 | INDEX FAST FULL SCAN| BIGTABLE_IND_2 | 1 | 5 | 2 | ------------------------------------------------------------------------

57 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 57 www.brianhitchcock.net Explain Plan Real Example PLAN_TABLE_OUTPUT --------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost | --------------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | | | | | 1 | SORT ORDER BY | | | | | | 2 | NESTED LOOPS OUTER | | | | | | 3 | NESTED LOOPS OUTER | | | | | | 4 | NESTED LOOPS OUTER | | | | | | 5 | NESTED LOOPS | | | | | | 6 | NESTED LOOPS | | | | | | 7 | NESTED LOOPS OUTER | | | | | | 8 | NESTED LOOPS OUTER | | | | | | 9 | NESTED LOOPS OUTER | | | | | | 10 | NESTED LOOPS OUTER | | | | | | 11 | NESTED LOOPS OUTER | | | | | | 12 | NESTED LOOPS OUTER | | | | | | 13 | NESTED LOOPS | | | | | | 14 | NESTED LOOPS OUTER | | | | | | 15 | NESTED LOOPS OUTER | | | | | | 16 | NESTED LOOPS OUTER | | | | | | 17 | NESTED LOOPS OUTER | | | | | | 18 | NESTED LOOPS OUTER | | | | |

58 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 58 www.brianhitchcock.net Explain Plan Real Example | 19 | NESTED LOOPS OUTER | | | | | | 20 | NESTED LOOPS OUTER | | | | | | 21 | NESTED LOOPS OUTER | | | | | | 22 | NESTED LOOPS OUTER | | | | | |* 23 | TABLE ACCESS BY INDEX ROWID| S_CONTACT | | | | |* 24 | INDEX RANGE SCAN | S_CONTACT_M14_BOTH | | | | |* 25 | INDEX UNIQUE SCAN | S_PARTY_P1 | | | | | 26 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | | | | |* 27 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | | | | | 28 | TABLE ACCESS BY INDEX ROWID | S_USER | | | | |* 29 | INDEX UNIQUE SCAN | S_USER_U2 | | | | |* 30 | INDEX UNIQUE SCAN | S_PARTY_P1 | | | | | 31 | TABLE ACCESS BY INDEX ROWID | S_CONTACT | | | | |* 32 | INDEX UNIQUE SCAN | S_CONTACT_U2 | | | | | 33 | TABLE ACCESS BY INDEX ROWID | S_ADDR_ORG | | | | |* 34 | INDEX UNIQUE SCAN | S_ADDR_ORG_P1 | | | | | 35 | TABLE ACCESS BY INDEX ROWID | S_ORG_GROUP | | | | |* 36 | INDEX UNIQUE SCAN | S_ORG_GROUP_U2 | | | | | 37 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | | | | |* 38 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | | | | | 39 | TABLE ACCESS BY INDEX ROWID | S_ADDR_ORG | | | | |* 40 | INDEX UNIQUE SCAN | S_ADDR_ORG_P1 | | | | | 41 | TABLE ACCESS BY INDEX ROWID | S_PARTY | | | |

59 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 59 www.brianhitchcock.net Explain Plan Real Example |* 42 | INDEX UNIQUE SCAN | S_PARTY_P1 | | | | | 43 | TABLE ACCESS BY INDEX ROWID | S_CONTACT | | | | |* 44 | INDEX UNIQUE SCAN | S_CONTACT_U2 | | | | | 45 | TABLE ACCESS BY INDEX ROWID | S_EMP_PER | | | | |* 46 | INDEX UNIQUE SCAN | S_EMP_PER_U1 | | | | | 47 | TABLE ACCESS BY INDEX ROWID | S_CONTACT | | | | |* 48 | INDEX UNIQUE SCAN | S_CONTACT_U2 | | | | | 49 | TABLE ACCESS BY INDEX ROWID | S_ORG_EXT | | | | |* 50 | INDEX UNIQUE SCAN | S_ORG_EXT_U3 | | | | | 51 | TABLE ACCESS BY INDEX ROWID | S_RESP | | | | |* 52 | INDEX UNIQUE SCAN | S_RESP_P1 | | | | |* 53 | INDEX UNIQUE SCAN | S_PARTY_P1 | | | | | 54 | TABLE ACCESS BY INDEX ROWID | S_POSTN_CON | | | | |* 55 | INDEX RANGE SCAN | S_POSTN_CON_M3 | | | | |* 56 | INDEX UNIQUE SCAN | S_PARTY_P1 | | | | | 57 | TABLE ACCESS BY INDEX ROWID | S_POSTN | | | | |* 58 | INDEX UNIQUE SCAN | S_POSTN_U2 | | | | | 59 | TABLE ACCESS BY INDEX ROWID | S_USER | | | | |* 60 | INDEX UNIQUE SCAN | S_USER_U2 | | | | | 61 | TABLE ACCESS BY INDEX ROWID | S_CONTACT_X | | | | |* 62 | INDEX RANGE SCAN | S_CONTACT_X_U1 | | | | ---------------------------------------------------------------------------------------------------------

60 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 60 www.brianhitchcock.net Explain Plan Real Example Predicate Information (identified by operation id): --------------------------------------------------- 23 - filter(("T1"."LAST_NAME" LIKE 'lt%' OR "T1"."LAST_NAME" LIKE 'Lt%' OR "T1"."LAST_NAME" LIKE 'lT%' OR "T1"."LAST_NAME" LIKE 'LT%') AND "T1"."X_CONT_STATUS"<>'Deactivated') 24 - access("T1"."BU_ID"='1-GWD' AND "T1"."PRIV_FLG"='N') filter("T1"."PRIV_FLG"='N' AND UPPER("T1"."LAST_NAME") LIKE 'LTCONTACT09092004102013LAST%') 25 - access("T1"."BU_ID"="T21"."ROW_ID"(+)) 27 - access("T1"."PR_DEPT_OU_ID"="T20"."PAR_ROW_ID"(+)) 29 - access("T1"."PR_SYNC_USER_ID"="T18"."PAR_ROW_ID"(+)) 30 - access("T1"."PR_GRP_OU_ID"="T17"."ROW_ID"(+)) 32 - access("T1"."CON_MANAGER_PER_ID"="T16"."PAR_ROW_ID"(+)) 34 - access("T1"."PR_OU_ADDR_ID"="T11"."ROW_ID"(+)) 36 - access("T1"."PR_GRP_OU_ID"="T10"."PAR_ROW_ID"(+)) 38 - access("T1"."BU_ID"="T8"."PAR_ROW_ID"(+)) 40 - access("T1"."PR_OU_ADDR_ID"="T6"."ROW_ID"(+)) 42 - access("T5"."ROW_ID"="T1"."PAR_ROW_ID") 44 - access("T5"."CREATED_BY"="T22"."PAR_ROW_ID"(+)) 46 - access("T5"."ROW_ID"="T12"."PAR_ROW_ID"(+)) 48 - access("T5"."LAST_UPD_BY"="T9"."PAR_ROW_ID"(+)) 50 - access("T1"."BU_ID"="T4"."PAR_ROW_ID"(+)) 52 - access("T1"."PR_RESP_ID"="T3"."ROW_ID"(+)) 53 - access("T1"."PR_SYNC_USER_ID"="T2"."ROW_ID"(+))

61 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 61 www.brianhitchcock.net Explain Plan Real Example 55 - access("T1"."PR_POSTN_ID"="T19"."POSTN_ID" AND "T1"."ROW_ID"="T19"."CON_ID") 56 - access("T19"."POSTN_ID"="T15"."ROW_ID") 58 - access("T19"."POSTN_ID"="T14"."PAR_ROW_ID"(+)) 60 - access("T14"."PR_EMP_ID"="T13"."PAR_ROW_ID"(+)) 62 - access("T5"."ROW_ID"="T7"."PAR_ROW_ID"(+)) Note: rule based optimization 99 rows selected. SQL>

62 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 62 www.brianhitchcock.net Things to Look for Table access by index rowid – This means Oracle couldnt find everything it needed from the index it used in the previous step (indented next to the right) – Oracle has to retrieve all the rows identified by the previously used index from the base table – Lots more logical (and possible physical) IO

63 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 63 www.brianhitchcock.net Things to Look for SORT – Anytime you see sort in explain plan output – Oracle doesnt have index with the columns in needed order to satisfy the ORDER BY clause of the where clause – This causes more processing – Sorting may go to disk if it cant be done in memory – Alternate index can eliminate this sort step

64 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 64 www.brianhitchcock.net Trace alter session set SQL_TRACE true; alter session set tracefile_identifier='BRH_trace_file1'; select a from bigtable_2 where a='A' and x=1000; Dump file /brhoracle/db1/archive/ICHIPERF/udump/ichiperf_ora_2157_BRH_trace_file1.trc *** TRACE DUMP CONTINUED FROM FILE /brhoracle/db1/archive/ICHIPERF/udump/ichiperf_ora_2157.trc *** EXEC #1:c=0,e=55091,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=13267028210605 *** 2004-11-11 14:37:41.439 ===================== PARSING IN CURSOR #1 len=47 dep=0 uid=12154 oct=3 lid=12154 tim=13267051337109 hv=22533017 ad='62b7c718' select a from bigtable_2 where a='A' and x=1000 END OF STMT PARSE #1:c=0,e=15398,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=13267051337080 EXEC #1:c=0,e=125,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=13267051337753 FETCH #1:c=0,e=134,p=0,cr=2,cu=0,mis=0,r=1,dep=0,og=4,tim=13267051338207 FETCH #1:c=0,e=66,p=0,cr=1,cu=0,mis=0,r=0,dep=0,og=4,tim=13267051339305 STAT #1 id=1 cnt=1 pid=0 pos=1 obj=20864 op='INDEX RANGE SCAN BIGTABLE_IND_2 (cr=3 r=0 w=0 time=156 us)' =====================

65 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 65 www.brianhitchcock.net tkprof tkprof ichiperf_ora_2157_BRH_trace_file1.trc BRH_trace_file1_prf ichiban:/brhoracle/db1/archive/ICHIPERF/udump 14 % cat BRH_trace_file1_prf.prf TKPROF: Release 9.2.0.4.0 - Production on Thu Nov 11 14:42:12 2004 Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. Trace file: ichiperf_ora_2157_BRH_trace_file1.trc Sort options: default ******************************************************************************** count = number of times OCI procedure was executed cpu = cpu time in seconds executing elapsed = elapsed time in seconds executing disk = number of physical reads of buffers from disk query = number of buffers gotten for consistent read current = number of buffers gotten in current mode (usually for update) rows = number of rows processed by the fetch or execute call ********************************************************************************

66 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 66 www.brianhitchcock.net tkprof select a from bigtable_2 where a='A' and x=1000 call count cpu elapsed disk query current rows ------- ------ -------- ---------- ---------- ---------- ---------- ---------- Parse 1 0.00 0.01 0 0 0 0 Execute 2 0.00 0.05 0 0 0 0 Fetch 2 0.00 0.00 0 3 0 1 ------- ------ -------- ---------- ---------- ---------- ---------- ---------- total 5 0.00 0.07 0 3 0 1 Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 12154 Rows Row Source Operation ------- --------------------------------------------------- 1 INDEX RANGE SCAN BIGTABLE_IND_2 (cr=3 r=0 w=0 time=156 us)(object id 20864) ********************************************************************************

67 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 67 www.brianhitchcock.net autotrace SQL> set timing on SQL> set autotrace on SQL> SQL> select count(*) from bigtable_1; COUNT(*) ---------- 10000 Elapsed: 00:00:05.24 Execution Plan ---------------------------------------------------- 0 SELECT STATEMENT Optimizer=RULE 10 SORT (AGGREGATE) 21 TABLE ACCESS (FULL) OF 'BIGTABLE_1' Statistics --------------------------------------------------- 0 recursive calls 0 db block gets 23 consistent gets 0 physical reads 0 redo size 379 bytes sent via SQL*Net to client 503 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed SQL>

68 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 68 www.brianhitchcock.net autotrace SQL> select count(*) from bigtable_2; COUNT(*) ---------- 100000 Elapsed: 00:00:05.35 Execution Plan ---------------------------------------------------- 0 SELECT STATEMENT Optimizer=RULE 10 SORT (AGGREGATE) 21 TABLE ACCESS (FULL) OF 'BIGTABLE_2' Statistics ----------------------------------------------------- 0 recursive calls 0 db block gets 168 consistent gets 0 physical reads 0 redo size 379 bytes sent via SQL*Net to client 503 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed SQL>

69 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 69 www.brianhitchcock.net autotrace SQL> select a from bigtable_2 where x=1000; A -------- A Elapsed: 00:00:05.35 Execution Plan -------------------------------------------------- 0 SELECT STATEMENT Optimizer=RULE 10 TABLE ACCESS (FULL) OF 'BIGTABLE_2' Statistics ------------------------------------------------------- 0 recursive calls 0 db block gets 169 consistent gets 0 physical reads 0 redo size 371 bytes sent via SQL*Net to client 503 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed SQL>

70 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 70 www.brianhitchcock.net autotrace SQL> select a from bigtable_2 where a='A' and x=1000; A -------- A Elapsed: 00:00:05.25 Execution Plan ----------------------------------------------------- 0 SELECT STATEMENT Optimizer=RULE 10 INDEX (RANGE SCAN) OF 'BIGTABLE_IND_2' (NON-UNIQUE) Statistics ------------------------------------------------------ 0 recursive calls 0 db block gets 3 consistent gets 0 physical reads 0 redo size 371 bytes sent via SQL*Net to client 503 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed SQL>

71 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 71 www.brianhitchcock.net autotrace SQL> alter session set optimizer_mode=choose; SQL> select a from bigtable_2 where x=1000; A -------- A Elapsed: 00:00:05.38 Execution Plan ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=5) 10 INDEX (FAST FULL SCAN) OF 'BIGTABLE_IND_2' (NON-UNIQUE) (C ost=2 Card=1 Bytes=5) Statistics ------------------------------------------------------ 0 recursive calls 0 db block gets 258 consistent gets 0 physical reads 0 redo size 371 bytes sent via SQL*Net to client 503 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed SQL>

72 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 72 www.brianhitchcock.net autotrace SQL> select a from bigtable_2 where a='A' and x=1000; A -------- A Elapsed: 00:00:05.23 Execution Plan ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=1 Bytes=5) 10 INDEX (RANGE SCAN) OF 'BIGTABLE_IND_2' (NON-UNIQUE) (Cost= 1 Card=1 Bytes=5) Statistics ------------------------------------------------------ 0 recursive calls 0 db block gets 3 consistent gets 0 physical reads 0 redo size 371 bytes sent via SQL*Net to client 503 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed SQL>

73 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 73 www.brianhitchcock.net Autotrace Summary autotrace results select count(*) from bigtable_1; full table scan 23 consistent gets select count(*) from bigtable_2; full table scan 168 consistent gets select a from bigtable_2 where x=1000; full table scan 169 consistent gets select a from bigtable_2 where a='A' and x=1000; index range scan 3 consistent gets

74 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 74 www.brianhitchcock.net 10046 Trace File sqlplus sqltuner/sqltuner set timing on alter session set timed_statistics=true; alter session set max_dump_file_size=unlimited; alter session set tracefile_identifier='BRH_10046_trace_1'; alter session set events '10046 trace name context forever, level 12'; select a from bigtable_2 where x=1000; exit sqlplus sqltuner/sqltuner set timing on alter session set timed_statistics=true; alter session set max_dump_file_size=unlimited; alter session set tracefile_identifier='BRH_10046_trace_2'; alter session set events '10046 trace name context forever, level 12'; select a from bigtable_2 where a='A' and x=1000; exit

75 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 75 www.brianhitchcock.net 10046 Trace File cd ls -l *BRH_10046_trace_* 53 % ls -lrt total 1160 -rw-r----- 1 oracle dba 2107 Nov 11 16:16 ichiperf_ora_2307_BRH_10046_trace_1.trc -rw-r----- 1 oracle dba 2094 Nov 11 16:17 ichiperf_ora_2309_BRH_10046_trace_2.trc

76 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 76 www.brianhitchcock.net 10046 Trace File cat ichiperf_ora_2307_BRH_10046_trace_1.trc *** TRACE DUMP CONTINUED FROM FILE bÝ=W Ü õ ½, *** Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options JServer Release 9.2.0.4.0 - Production ORACLE_HOME = /brhoracle/app/oracle/product/9.2.0.2 System name: SunOS Node name: ichiban Release: 5.8 Version: Generic_108528-19 Machine: sun4u Instance name: ICHIPERF Redo thread mounted by this instance: 1 Oracle process number: 11 Unix process pid: 2307, image: oracle@ichiban (TNS V1-V3) *** 2004-11-11 16:16:32.772 *** SESSION ID:(14.6010) 2004-11-11 16:16:32.772 APPNAME mod='SQL*Plus' mh=3669949024 act='' ah=4029777240 =====================

77 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 77 www.brianhitchcock.net 10046 Trace File PARSING IN CURSOR #1 len=69 dep=0 uid=12154 oct=42 lid=12154 tim=13272843655255 hv=2004533713 ad='6369c47c' alter session set events '10046 trace name context forever, level 12' END OF STMT EXEC #1:c=0,e=331,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=3,tim=13272843654199 WAIT #1: nam='SQL*Net message to client' ela= 9 p1=1650815232 p2=1 p3=0 WAIT #1: nam='SQL*Net message from client' ela= 5376632 p1=1650815232 p2=1 p3=0 ===================== PARSING IN CURSOR #1 len=37 dep=0 uid=12154 oct=3 lid=12154 tim=13272849036779 hv=827374562 ad='62ba1b84' select a from bigtable_2 where x=1000 END OF STMT PARSE #1:c=10000,e=3644,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=3,tim=13272849036755 BINDS #1: EXEC #1:c=0,e=157,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=3,tim=13272849037277 WAIT #1: nam='SQL*Net message to client' ela= 9 p1=1650815232 p2=1 p3=0 FETCH #1:c=0,e=2039,p=0,cr=5,cu=0,mis=0,r=1,dep=0,og=3,tim=13272849039622 WAIT #1: nam='SQL*Net message from client' ela= 1306 p1=1650815232 p2=1 p3=0 FETCH #1:c=180000,e=174565,p=0,cr=164,cu=0,mis=0,r=0,dep=0,og=3,tim=13272849215810 WAIT #1: nam='SQL*Net message to client' ela= 10 p1=1650815232 p2=1 p3=0 WAIT #1: nam='SQL*Net message from client' ela= 1957094 p1=1650815232 p2=1 p3=0 XCTEND rlbk=0, rd_only=1 STAT #1 id=1 cnt=1 pid=0 pos=1 obj=20861 op='TABLE ACCESS FULL OBJ#(20861) (cr=169 r=0 w=0 time=176563 us)'

78 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 78 www.brianhitchcock.net 10046 Trace File cat ichiperf_ora_2309_BRH_10046_trace_2.trc *** TRACE DUMP CONTINUED FROM FILE bÝ=W Ü õ ½, *** Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options JServer Release 9.2.0.4.0 - Production ORACLE_HOME = /brhoracle/app/oracle/product/9.2.0.2 System name: SunOS Node name: ichiban Release: 5.8 Version: Generic_108528-19 Machine: sun4u Instance name: ICHIPERF Redo thread mounted by this instance: 1 Oracle process number: 11 Unix process pid: 2309, image: oracle@ichiban (TNS V1-V3) *** 2004-11-11 16:17:15.148 *** SESSION ID:(14.6012) 2004-11-11 16:17:15.148 APPNAME mod='SQL*Plus' mh=3669949024 act='' ah=4029777240 =====================

79 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 79 www.brianhitchcock.net 10046 Trace File PARSING IN CURSOR #1 len=69 dep=0 uid=12154 oct=42 lid=12154 tim=13272885038136 hv=2004533713 ad='6369c47c' alter session set events '10046 trace name context forever, level 12' END OF STMT EXEC #1:c=0,e=346,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=3,tim=13272885037012 WAIT #1: nam='SQL*Net message to client' ela= 8 p1=1650815232 p2=1 p3=0 WAIT #1: nam='SQL*Net message from client' ela= 4922601 p1=1650815232 p2=1 p3=0 ===================== PARSING IN CURSOR #1 len=47 dep=0 uid=12154 oct=3 lid=12154 tim=13272889966267 hv=22533017 ad='62b7c718' select a from bigtable_2 where a='A' and x=1000 END OF STMT PARSE #1:c=0,e=4092,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=3,tim=13272889966241 BINDS #1: EXEC #1:c=0,e=190,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=3,tim=13272889966824 WAIT #1: nam='SQL*Net message to client' ela= 9 p1=1650815232 p2=1 p3=0 FETCH #1:c=0,e=137,p=0,cr=2,cu=0,mis=0,r=1,dep=0,og=3,tim=13272889967283 WAIT #1: nam='SQL*Net message from client' ela= 1330 p1=1650815232 p2=1 p3=0 FETCH #1:c=0,e=103,p=0,cr=1,cu=0,mis=0,r=0,dep=0,og=3,tim=13272889969045 WAIT #1: nam='SQL*Net message to client' ela= 6 p1=1650815232 p2=1 p3=0 WAIT #1: nam='SQL*Net message from client' ela= 1366032 p1=1650815232 p2=1 p3=0 XCTEND rlbk=0, rd_only=1 STAT #1 id=1 cnt=1 pid=0 pos=1 obj=20864 op='INDEX RANGE SCAN OBJ#(20864) (cr=3 r=0 w=0 time=201 us)'

80 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 80 www.brianhitchcock.net 10046 Trace File Summary What each output means c -- CPU time in microseconds e -- elapsed wall time in microseconds p -- physical reads (may be cached by OS IO system) cr -- consistent reads (from db buffer cache) cu -- current mode read (current content of db block) mis -- library cache miss, caused hard parse r -- number of rows returned dep -- recursive depth of cursor og -- optimizer goal, 3 is RULE tim -- if 0, timed statistics is FALSE FETCH #1:c=0,e=2039,p=0,cr=5,cu=0,mis=0,r=1,dep=0,og=3,tim=13272849039622 FETCH #1:c=0,e= 137,p=0,cr=2,cu=0,mis=0,r=1,dep=0,og=3,tim=13272889967283

81 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 81 www.brianhitchcock.net STATSPACK How to gather for a db you control How to request data for db you dont control – Perfstat tablespace, user, install STATSPACK – Get password for PERFSTAT user – Make snapshots – Run reports

82 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 82 www.brianhitchcock.net STATSPACK Example CRM perf issue STATSPACK gathers data while app used Identify worst SQL Dev team sees that this SQL is populating app screens that our users dont look at – Change Siebel configuration – SQL (and app) perf improve Didnt need to tune SQL Didnt need more hardware

83 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 83 www.brianhitchcock.net Snapshots, Report sqlplus perfstat/perfstat execute statspack.snap exit sqlplus sqltuner/sqltuner select a from bigtable_2 where x=1000; (execute 100 times) select a from bigtable_2 where a='A' and x=1000; (execute 100 times) sqlplus perfstat/perfstat execute statspack.snap @$ORACLE_HOME/rdbms/admin/spreport.sql Enter value for begin_snap: 2 Enter value for end_snap: 3 Enter value for report_name: ICHIPERF_2_3_sql_tuning_11112004.txt

84 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 84 www.brianhitchcock.net STATSPACK Report SQL ordered by Gets for DB: Instance: Snaps: 2 -3 -> End Buffer Gets Threshold:10000 -> Note that resources reported for PL/SQL includes the resources used by all SQL statements called within the PL/SQL code. As individual SQL statements are also reported, it is possible and valid for the summed total % to exceed 100 CPU Elapsd Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value --------------- ------------ -------------- ------ -------- --------- ---------- 16,571 97 170.8 50.3 12.9312.71 827374562 Module: SQL*Plus select a from bigtable_2 where x=1000 … 303 1013.0 0.9 0.03 0.0522533017 Module: SQL*Plus select a from bigtable_2 where a='A' and x=1000

85 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 85 www.brianhitchcock.net OS Monitoring mpstat 5 999 – Shows CPU load (idl) for each of multiple CPUs – 5 999, 999 runs, once every 5 seconds iostat -xnp 5 999 – Shows disk activity – asvc_t (less than 20ms?) vmstat -S 5 999 – Shows memory use – W, swap out, should be 0 – Sr, scan rate, very low, should be man vmstat 0

86 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 86 www.brianhitchcock.net CPU Usage mpstat 5 999 CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl 6 0 0 501 400 300 1 0 0 0 0 17 0 2 0 98 7 1 0 0 101 101 11 0 0 0 0 9 0 0 0 100 10 0 0 0 100 100 11 0 0 0 0 10 0 0 0 100 11 0 0 0 111 111 17 0 0 0 0 10 0 0 0 100 18 0 0 1 101 101 10 0 0 0 0 3 0 0 0 100 19 0 0 1 100 100 11 0 0 0 0 2 0 0 0 100

87 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 87 www.brianhitchcock.net IO Stats iostat -xnp 5 999 extended device statistics r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 c1t6d0 0.0 7.6 0.0 59.2 0.3 0.5 35.1 61.0 2 4 c0t0d0 0.0 7.6 0.0 59.2 0.3 0.5 35.1 61.0 2 4 c0t0d0s0 0.0 1.0 0.0 7.4 0.0 0.0 0.0 13.2 0 1 c0t3d0 0.0 1.0 0.0 7.4 0.0 0.0 0.0 13.2 0 1 c0t3d0s0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 c0t3d0s2 18.8 3.2 150.4 25.6 0.0 0.2 0.0 7.9 0 16 c0t2d0 18.8 3.2 150.4 25.6 0.0 0.2 0.0 7.9 0 16 c0t2d0s0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 c0t2d0s2 0.0 0.4 0.0 3.2 0.0 0.0 0.0 9.1 0 0 c3t5d0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 c3t5d0s0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 c3t5d0s2 0.0 0.4 0.0 3.2 0.0 0.0 0.0 9.1 0 0 c3t5d0s4 0.0 4.2 0.0 33.6 0.0 0.1 0.0 29.4 0 4 c3t6d0 0.0 2.8 0.0 22.4 0.0 0.1 0.0 28.0 0 4 c3t6d0s0 0.0 1.4 0.0 11.2 0.0 0.0 0.0 32.1 0 3 c3t6d0s1 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 c3t6d0s2 0.0 7.4 0.0 57.8 0.1 0.4 19.6 53.8 2 4 c3t7d0 0.0 6.6 0.0 51.4 0.1 0.4 22.0 55.6 2 4 c3t7d0s0

88 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 88 www.brianhitchcock.net Memory Usage vmstat -S 5 999 procs memory page disk faults cpu r b w swap free si so pi po fr de sr s3 sd sd sd in sy cs us sy id 0 0 0 12892712 2725712 0 0 174 0 0 0 0 0 1 0 0 848 784 235 6 1 93 0 0 0 13046744 2657032 0 0 0 0 0 0 0 0 0 0 0 814 24 62 0 0 100 0 0 0 13046744 2657032 0 0 0 0 0 0 0 0 0 0 0 813 33 62 0 0 100 0 0 0 13046744 2657032 0 0 0 0 0 0 0 0 0 0 0 815 34 73 0 0 100 0 0 0 13046744 2657032 0 0 0 0 0 0 0 0 0 0 0 817 61 79 0 0 100 0 0 0 13046744 2657032 0 0 0 0 0 0 0 0 2 1 0 826 185 102 1 2 97 0 0 0 13046448 2656848 0 0 0 0 0 0 0 0 0 0 0 838 355 104 1 1 98 0 0 0 13046552 2656960 0 0 0 0 0 0 0 0 0 0 0 819 168 78 0 1 99 0 0 0 13046744 2657040 0 0 0 0 0 0 0 0 0 0 0 817 37 63 0 0 100 0 0 0 13046592 2656896 0 0 0 1 1 0 0 0 1 0 0 817 1350 158 1 2 97 0 0 0 13046232 2656648 0 0 0 1 1 0 0 0 0 0 0 824 2567 244 2 5 93 0 0 0 13046744 2657032 0 0 0 0 0 0 0 0 8 1 0 828 38 65 0 1 99 0 0 0 13046744 2657032 0 0 0 0 0 0 0 0 0 1 0 817 38 69 0 0 100 0 0 0 13046744 2657032 0 0 0 0 0 0 0 0 0 0 0 815 42 66 0 0 100 0 0 0 13046744 2657032 0 0 0 0 0 0 0 0 0 0 0 812 98 74 0 0 100 0 0 0 13046744 2657032 0 0 0 0 0 0 0 0 0 0 0 816 34 70 0 0 100 0 0 0 13046744 2657032 0 0 0 0 0 0 0 0 0 0 0 815 27 60 0 0 100 0 0 0 13046744 2657032 0 0 0 0 0 0 0 0 1 1 0 814 32 63 0 2 98 0 0 0 13046744 2657032 0 0 0 0 0 0 0 0 0 1 0 825 232 84 0 1 99

89 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 89 www.brianhitchcock.net Wait States While CPU usage was high Select wait events that are happening now Look for non-idle wait events select sid, seq#, event from v$session_wait where event !='SQL*Net message from client';

90 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 90 www.brianhitchcock.net Wait States SQL> select sid, seq#, event from v$session_wait where event !='SQL*Net message from client'; SID SEQ# EVENT ---------- ---------- ------------------ 207 3868 latch free 566 831 latch free 571 627 latch free 617 3686 latch free 680 616 latch free 732 638 latch free 798 645 latch free 875 572 latch free 912 601 latch free 983 3535 latch free 919 550 latch free 892 704 latch free 853 2306 latch free 735 813 latch free 682 572 latch free 679 3750 latch free 658 770 latch free 620 625 latch free 1 28982 pmon timer 2 30504 rdbms ipc message 3 15711 rdbms ipc message 6 373 rdbms ipc message 8 12509 rdbms ipc message 7 19310 rdbms ipc message 4 13827 rdbms ipc message 12 27315 i/o slave wait 22 4058 i/o slave wait 21 3959 i/o slave wait 849 3631 db file sequential read 5 5053 smon timer 211 605 SQL*Net message to client 245 485 SQL*Net message to client 603 489 SQL*Net message to client 820 474 SQL*Net message to client 19 604 SQL*Net more data from client 35 rows selected. SQL>

91 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 91 www.brianhitchcock.net SQL Diagram Tuning Diagram SQL statement Compute the best execution plan Use to verify optimizer choice Use to determine hint(s) needed OReilly book SQL Tuning, Dan Tow Details of method beyond this presentation

92 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 92 www.brianhitchcock.net SQL Diagram Tuning SELECT T20.LAST_UPD_BY, T20.ROW_ID, T20.CONFLICT_ID, T20.CREATED_BY, T20.CREATED, T20.LAST_UPD, T20.MODIFICATION_NUM, T20.INIT_COMMIT_TS, T4.FST_NAME, T20.X_SUN_ESC_MCE_FLG, T20.ACTL_RESOLVED_TS, T20.X_SUN_ESC_PROD_DEF_DT, T15.X_SUN_SR_CTE_CONT, T13.SUB_STATUS_CD, T15.X_SUN_SR_MGR_FLG, T9.SR_SUB_STAT_ID, T20.X_SUN_ESC_TECH_AREA_ID, T15.X_SUN_SR_CONT_EMAIL_ADDR, T5.PAR_DIVN_ID, T19.ROW_ID, T20.OWNER_EMP_ID, T20.ACTL_RESP_TS, T20.X_SUN_ESC_TASK_ID, T17.NAME, T15.ASGN_DT, T4.LAST_NAME, T20.CST_CON_ID, T20.X_SUN_ESC_MGMT_ALERT, T13.X_SUN_BUG_MGR, T19.ROW_ID, T3.NAME, T20.SR_REPRODUCE, T20.SR_SUB_STAT_ID, T15.X_SUN_SR_CONT_ZIP, T15.X_SUN_SR_ACCT, T20.X_SUN_ESC_VENDOR_REF, T20.X_SUN_ESC_VENDOR_NAME, T8.LAST_NAME, T15.X_SUN_SR_OS_VER, T16.LAST_NAME, T20.EXP_CLOSE_DT, T2.ALIAS_NAME, T15.X_SUN_SR_CONT_STATE, T20.X_SUN_ESC_CE_FLG, T20.REOPENED_TS, T20.OWNER_OU_ID, T15.X_SUN_SR_CONT, T20.PAR_SR_ID, T20.SR_SEV_CD, T15.X_SUN_SR_CONT_ADDR, T10.NAME, T13.STATUS_CD, T6.ALIAS_NAME, T18.LOGIN, T20.X_SUN_ESC_DI_FLG, T20.X_SUN_BUSCOMP_TYPE, T15.X_SUN_SR_PRODUCT, T15.SR_NUM, T20.BU_ID, T12.NAME, T1.NAME, T20.X_SUN_ESC_REL_DELV_NUM, T9.ROW_ID, T9.SR_NUM, T9.SR_AREA, T2.X_SUN_PROD_OWNER, T20.X_SUN_ESC_STATUS, T9.SR_TITLE,

93 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 93 www.brianhitchcock.net SQL Diagram Tuning T20.X_SUN_ESC_ROOT_CAUSE, T20.X_SUN_ESC_SEE_ALSO, T20.X_SUN_ESC_ARCHITECTURE, T20.SR_SUB_AREA, T20.X_SUN_ESC_VERSION_ID, T15.X_SUN_SR_SAS_CUSTOMER_FLG, T20.X_SUN_ESC_ROOT_CAUSE_2, T20.X_SUN_ESC_VENDOR_VERSION, T11.NAME, T20.X_SUN_ESC_FIX_WORKED, T20.X_SUN_ESC_RESOLVED_BY, T20.X_SUN_ESC_MGR_ID, T20.ROW_STATUS, T20.X_SUN_ESC_TRANSFER_DT, T20.X_SUN_ESC_NOTIFY, T20.SR_TITLE, T13.DEFECT_NUM, T14.LOGIN, T20.X_SUN_ESC_VENDOR_PRODUCT, T15.X_SUN_SR_ENG_NAME, T20.WRNTY_LAST_UPD_DT, T20.SR_NUM, T9.BU_ID, T20.X_SUN_ESC_ROOT_CAUSE_3, T20.X_SUN_ESC_TASK_GROUP, T8.FST_NAME, T20.ACT_CLOSE_DT, T16.FST_NAME, T20.X_SUN_SRS_FLG, T20.SR_AREA, T7.FST_NAME, T20.X_SUN_OLD_BUG_ID, T5.NAME, T15.X_SUN_SR_CC_LIST, T17.PAR_DIVN_ID, T20.PRDINT_ID, T13.X_SUN_BUG_ENG, T20.X_SUN_PROD_OWNER, T20.X_SUN_ESC_CTE_MGR_ID, T20.X_SUN_ESC_ACCESS, T7.LAST_NAME, T3.PAR_DIVN_ID, T15.X_SUN_SR_ENG_GEO, T20.X_SUN_ESC_OS_VERSION, T20.RESOLUTION_CD, T20.X_SUN_PR_BUG_ID, T8.LOGIN, T20.SR_SUBTYPE_CD, T15.X_SUN_SR_CONT_WORK_PH_NUM, T20.PR_SYMPTOM_CD, T15.X_SUN_SR_CONT_COUNTRY, T20.X_SUN_ESC_OWNER_GEO, T9.SR_SEV_CD FROM SIEBEL.S_PROD_LN T1, SIEBEL.S_PROD_INT T2, SIEBEL.S_ORG_EXT T3, SIEBEL.S_CONTACT T4, SIEBEL.S_ORG_EXT T5, SIEBEL.S_PROD_INT T6, SIEBEL.S_CONTACT T7, SIEBEL.S_CONTACT T8, SIEBEL.S_SRV_REQ_BU T9, SIEBEL.S_ORG_EXT T10, SIEBEL.S_ORG_EXT T11, SIEBEL.S_ORG_EXT T12, SIEBEL.S_PROD_DEFECT T13, SIEBEL.S_USER T14, SIEBEL.S_SRV_REQ T15,

94 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 94 www.brianhitchcock.net SQL Diagram Tuning SIEBEL.S_CONTACT T16, SIEBEL.S_ORG_EXT T17, SIEBEL.S_USER T18, SIEBEL.S_PARTY T19, SIEBEL.S_SRV_REQ T20 WHERE T2.X_SUN_PROD_OWNER = T17.PAR_ROW_ID (+) AND T17.PAR_DIVN_ID = T10.PAR_ROW_ID (+) AND T20.PAR_SR_ID = T15.ROW_ID (+) AND T20.LAST_UPD_BY = T16.PAR_ROW_ID (+) AND T20.CREATED_BY = T18.PAR_ROW_ID (+) AND T20.OWNER_EMP_ID = T14.PAR_ROW_ID (+) AND T20.OWNER_EMP_ID = T8.PAR_ROW_ID (+) AND T20.OWNER_OU_ID = T3.PAR_ROW_ID (+) AND T20.PRDINT_ID = T6.ROW_ID (+) AND T20.X_SUN_PR_BUG_ID = T13.ROW_ID (+) AND T3.PAR_DIVN_ID = T5.PAR_ROW_ID (+) AND T5.PAR_DIVN_ID = T12.PAR_ROW_ID (+) AND T20.X_SUN_ESC_CTE_MGR_ID = T7.PAR_ROW_ID (+) AND T20.X_SUN_ESC_MGR_ID = T4.PAR_ROW_ID (+) AND T20.X_SUN_ESC_TECH_AREA_ID = T1.ROW_ID (+) AND T20.X_SUN_ESC_VERSION_ID = T2.ROW_ID (+) AND T20.BU_ID = T9.BU_ID (+) AND T20.ROW_ID = T9.SRV_REQ_ID (+) AND T9.BU_ID = T19.ROW_ID (+) AND T9.BU_ID = T11.PAR_ROW_ID (+) AND (T20.CREATED >= TO_DATE('01/01/1970','MM/DD/YYYY HH24:MI:SS') AND T20.CREATED <= TO_DATE('12/31/2037','MM/DD/YYYY HH24:MI:SS')) ORDER BY T12.NAME, T5.NAME, T3.NAME, T20.SR_NUM;

95 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 95 www.brianhitchcock.net SQL Diagram Tuning T20 T2 T17 T10 T3 T5 T12 T4 T6 T7 T8 T16 T18 T13 T14 T9 T15 T11 T19 S_SRV_REQ 50K rows T1 Outer Join Inner Join S_PROD_LN 94 rows S_ORG_EXT 260 rows S_PROD_INT 8410 rows S_SRV_REQ_BU 50K rows S_USER 1407 rows S_PROD_DEFECT 15399 rows S_ORG_EXT 260 rows S_CONTACT 1407 rows S_ORG_EXT 260 rows S_PROD_INT 8410 rows S_CONTACT 1407 rows S_SRV_REQ 50K rows S_CONTACT 1407 rows S_USER 1407 rows S_ORG_EXT 260 rows S_PARTY 1923 rows

96 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 96 www.brianhitchcock.net Books Oracle SQL High Performance Tuning (8i) – Guy Harrison, Prentice Hall, 2000 Optimizing Oracle Performance – Milsap, Holt, OReilly, 2003 SQL Tuning – Dan Tow, OReilly, 2004 Oracle 9i Performance Tuning – Rich Niemiec, Oracle Press, 2003

97 DCSIT Technical Services DBA Brian Hitchcock November 18, 2004Page 97 www.brianhitchcock.net Class Reactive Performance Management – Craig A. Shallahamer – OraPub, Inc, www.orapub.comwww.orapub.com Covers OS, App and database tuning I took this class September 2004 – Detailed review of class http://www.orapub.com/info/NoCOUG-OraPub-RPM.pdf – NoCOUG Journal November 2004, p22-27 – www.nocoug.org


Download ppt "SQL Tuning For Developers Brian Hitchcock OCP 8, 8i, 9i DBA Sun Microsystems DCSIT Technical Services DBA Brian."

Similar presentations


Ads by Google