SQL Tuning For Developers Brian Hitchcock OCP 8, 8i, 9i DBA Sun Microsystems [email protected] [email protected] DCSIT Technical Services DBA Brian

SQL Tuning For Developers

Brian HitchcockOCP 8, 8i, 9i DBA

Sun Microsystems

[email protected]

[email protected] Technical Services DBA

Brian Hitchcock November 18, 2004 Page 1

www.brianhitchcock.net

mailto:[email protected]

mailto:[email protected]

DCSIT Technical Services DBA



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




Assumptions

You can get the SQL statements– 3rd party apps– User generated SQL– Forms– Web pages

How will you get the SQL to test?– Tracing– Statspack

You are using 9i




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




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=?





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





Indexes– Best possible?– Can be used by optimizer?

Statistics (for Cost Based Optimizer)– Accurate?

SQL itself– Using indexes?




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 Don’t request data you won’t use

– Parse less often Reuse SQL Bind variables PL/SQL packages pinned in memory




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=<specific value>– Don’t request data you won’t use

Siebel default configuration, requests large amounts of data to populate unused screens

Overall SQL performance– All SQL for all users? For some users?




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




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




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




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




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




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




Bind Variables

Support shared SQL– Good for performance

Optimizer doesn’t know exact values– Can’t 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




Optimizer Modes

Controlled by– Init.ora parameter optimizer_mode

Choose (default) All_rows First_Rows_n First_Rows Rule




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




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




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 doesn’t matter– Doesn’t exist in 10g– Note, other factors can cause CBO even with Rule…




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




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




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




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




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?




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




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.




Specific Hints Available

Hints for Optimization Approaches and Goals ALL_ROWS FIRST_ROWS(n) CHOOSE RULE

Hints for Join Orders ORDERED STAR




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





Hints for Query Transformations– USE_CONCAT – NO_EXPAND – REWRITE – EXPAND_GSET_TO_UNION – NOREWRITE – MERGE – NO_MERGE – STAR_TRANSFORMATION – FACT – NO_FACT





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





Hints for Parallel Execution– PARALLEL – NOPARALLEL – PQ_DISTRIBUTE – PARALLEL_INDEX – NOPARALLEL_INDEX




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




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 isn’t good– function prevents good index from being used– Bind variables, optimizer can’t evaluate indexes

correctly




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?




Index Organized Table

Table, but– Rows stored in order of primary key

Don’t 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




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




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




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

Don’t have to use all of them




SQL*Plus

Set timing on Don’t 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




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




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




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




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




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




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




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




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




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




SQL Diagram Tuning

Diagram SQL statement Compute the best execution plan Use to verify optimizer choice Use to determine hint(s) needed O’Reilly book SQL Tuning, Dan Tow Details of method beyond this presentation




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




Examples

SQL*Plus Explain Plan Trace Tkprof autotrace 10046 SQL trace (extended SQL tracing) Statspack OS monitoring Wait States




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);




SQL*Plus

Gather timing data– Sqlplus <user>/<password>@<SID>– Set timing on– <execute SQL>– Timing data is displayed– Spool file

Document affect of SQL and/or db changes

Different index

Change init.ora parameter(s)




SQL*PlusSQL> 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




Explain Plan Examplesselect * from bigtable_2;

--------------------------------------------------------------------


--------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 100K| 488K| 7 |

| 1 | TABLE ACCESS FULL | BIGTABLE_2 | 100K| 488K| 7 |

--------------------------------------------------------------------

select a from bigtable_2 where x= 2 1000;

------------------------------------------------------------------------


------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 1 | 5 | 2 |

|* 1 | INDEX FAST FULL SCAN| BIGTABLE_IND_2 | 1 | 5 | 2 |

------------------------------------------------------------------------




Explain Plan Real ExamplePLAN_TABLE_OUTPUT

---------------------------------------------------------------------------------------------------------


---------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | | | |

| 1 | SORT ORDER BY | | | | |

| 2 | NESTED LOOPS OUTER | | | | |



| 5 | NESTED LOOPS | | | | |

| 6 | NESTED LOOPS | | | | |







| 13 | NESTED LOOPS | | | | |









Explain Plan Real Example| 19 | 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 | | | |


| 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 | | | |



| 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 | | | |




Explain Plan Real Example|* 42 | INDEX UNIQUE SCAN | S_PARTY_P1 | | | |



| 45 | TABLE ACCESS BY INDEX ROWID | S_EMP_PER | | | |

|* 46 | INDEX UNIQUE SCAN | S_EMP_PER_U1 | | | |





| 51 | TABLE ACCESS BY INDEX ROWID | S_RESP | | | |

|* 52 | INDEX UNIQUE SCAN | S_RESP_P1 | | | |


| 54 | TABLE ACCESS BY INDEX ROWID | S_POSTN_CON | | | |

|* 55 | INDEX RANGE SCAN | S_POSTN_CON_M3 | | | |


| 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 | | | |

---------------------------------------------------------------------------------------------------------




Explain Plan Real ExamplePredicate 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"(+))




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>




Things to Look for

Table access by index rowid– This means Oracle couldn’t 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




Things to Look for

SORT– Anytime you see sort in explain plan output– Oracle doesn’t 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 can’t be done in

memory– Alternate index can eliminate this sort step




Tracealter 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


FETCH #1:c=0,e=134,p=0,cr=2,cu=0,mis=0,r=1,dep=0,og=4,tim=13267051338207


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)'

=====================




tkproftkprof 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

********************************************************************************




tkprofselect 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)

********************************************************************************




autotraceSQL> 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

1 0 SORT (AGGREGATE)

2 1 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>




autotraceSQL> select count(*) from bigtable_2;

COUNT(*)

----------

100000

Elapsed: 00:00:05.35

Execution Plan

----------------------------------------------------


1 0 SORT (AGGREGATE)


Statistics

-----------------------------------------------------

0 recursive calls

0 db block gets

168 consistent gets

0 physical reads

0 redo size




0 sorts (memory)

0 sorts (disk)

1 rows processed

SQL>




autotraceSQL> select a from bigtable_2 where x=1000;

A

--------

A

Elapsed: 00:00:05.35

Execution Plan

--------------------------------------------------



Statistics

-------------------------------------------------------

0 recursive calls

0 db block gets

169 consistent gets

0 physical reads

0 redo size




0 sorts (memory)

0 sorts (disk)

1 rows processed

SQL>




autotraceSQL> select a from bigtable_2 where a='A' and x=1000;

A

--------

A

Elapsed: 00:00:05.25

Execution Plan

-----------------------------------------------------


1 0 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




0 sorts (memory)

0 sorts (disk)

1 rows processed

SQL>




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)

1 0 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




0 sorts (memory)

0 sorts (disk)

1 rows processed

SQL>




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)

1 0 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




0 sorts (memory)

0 sorts (disk)

1 rows processed

SQL>




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




10046 Trace Filesqlplus 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




10046 Trace File

cd <user_dump_dest>

ls -l *BRH_10046_trace_*

<user_dump_dest> 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




10046 Trace Filecat 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

=====================




10046 Trace FilePARSING 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


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


BINDS #1:








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)'




10046 Trace Filecat 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

=====================




10046 Trace FilePARSING 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




=====================

PARSING IN CURSOR #1 len=47 dep=0 uid=12154 oct=3 lid=12154 tim=13272889966267 hv=22533017 ad='62b7c718'


END OF STMT


BINDS #1:








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)'




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= 137,p=0,cr=2,cu=0,mis=0,r=1,dep=0,og=3,tim=13272889967283




STATSPACK

How to gather for a db you control How to request data for db you don’t control

– Perfstat tablespace, user, install STATSPACK– Get password for PERFSTAT user– Make snapshots– Run reports




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 don’t look at– Change Siebel configuration– SQL (and app) perf improve

Didn’t need to ‘tune’ SQL Didn’t need more hardware




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




STATSPACK ReportSQL ordered by Gets for DB: <SID> Instance: <SID> 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.93 12.71 827374562

Module: SQL*Plus

select a from bigtable_2 where x=1000

…

…

…

303 101 3.0 0.9 0.03 0.05 22533017

Module: SQL*Plus





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




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




IO Statsiostat -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




Memory Usagevmstat -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




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';




Wait StatesSQL> 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






12 27315 i/o slave wait



849 3631 db file sequential read

5 5053 smon timer

211 605 SQL*Net message to client




19 604 SQL*Net more data from client

35 rows selected.

SQL>




SQL Diagram Tuning

Diagram SQL statement Compute the best execution plan Use to verify optimizer choice Use to determine hint(s) needed O’Reilly book SQL Tuning, Dan Tow Details of method beyond this presentation




SQL Diagram TuningSELECT

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,




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_PROD_INT T6,



SIEBEL.S_SRV_REQ_BU T9,




SIEBEL.S_PROD_DEFECT T13,

SIEBEL.S_USER T14,

SIEBEL.S_SRV_REQ T15,




SQL Diagram Tuning SIEBEL.S_CONTACT T16,


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



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;




SQL Diagram TuningT20

T2

T17

T10

T3

T5

T12

T4T6T7T8

T16T18

T13T14

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 rowsS_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_CONTACT 1407 rows

S_SRV_REQ 50K rows

S_CONTACT 1407 rows

S_USER 1407 rows

S_ORG_EXT 260 rows

S_ORG_EXT 260 rows

S_ORG_EXT 260 rows

S_PARTY 1923 rows




Books

Oracle SQL High Performance Tuning (8i)– Guy Harrison, Prentice Hall, 2000

Optimizing Oracle Performance– Milsap, Holt, O’Reilly, 2003

SQL Tuning– Dan Tow, O’Reilly, 2004

Oracle 9i Performance Tuning– Rich Niemiec, Oracle Press, 2003




Class

Reactive Performance Management– Craig A. Shallahamer– OraPub, Inc, www.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

Documents

SQL Tuning For Developers Brian Hitchcock OCP 8, 8i, 9i DBA Sun Microsystems [email protected] [email protected] DCSIT Technical Services DBA Brian