Oracle Performance

Tools

-1-
Lesson Objectives

To understand the following topics:

 Overview of Data Gathering
 Measuring SQL Performance using tools
• The SQL Trace Facility
• The TKPROF Utility
• The Explain Plan Facility
• The AUTOTRACE Utility
• SQL Tuning Information in STATSPACK Output
 Automatic Workload Repository (AWR)
 Automatic Database Diagnostic Monitor
(ADDM)
 V$ Performance Views

-2-
Overview of Data Gathering

– Cumulative values for statistics are generally available through dynamic

performance views, such as the V$SESSTAT and V$SYSSTAT views.

• Database Statistics
• Operating System Statistics
• Interpreting Statistics

– Database statistics provide information on the type of load on the

database, as well as the internal and external resources used by the
database.
• Wait Events
• Time Model Statistics
• Active Session History (ASH)
• System and Session Statistics

-3-
Oracle Optimizer: Overview

The Oracle optimizer determines the most efficient execution

plan and is the most important step in the processing of any SQL
statement.
The optimizer:
– Evaluates expressions and conditions
– Uses object and system statistics
– Decides how to access the data
– Decides how to join tables
– Determines the most efficient path

-4-
Optimizer Statistics

Optimizer statistics are:

– A snapshot at a point in time
– Persistent across instance restarts
– Collected automatically

SQL> SELECT COUNT(*) FROM hr.employees;

COUNT(*)
----------
214
SQL> SELECT num_rows FROM dba_tables
2 WHERE owner='HR' AND table_name = 'EMPLOYEES';
NUM_ROWS
----------
107

-5-
Using the Manage Optimizer
Statistics Page

-6-
Gathering Optimizer Statistics Manually

-7-
Statistic Levels

STATISTICS_LEVEL

BASIC TYPICAL ALL

Additional statistics
Self-tuning Recommended
for manual
capabilities disabled default value
SQL diagnostics

-9-
X.3: Breadcrumb

Operating System Statistics

 Operating system statistics include the following:

– CPU Statistics
– Virtual Memory Statistics
– Disk Statistics
– Network Statistics

- 11 -
Measuring SQL Performance using
Diagnostic Tools

 The SQL Trace Facility

 The TKPROF Utility
 The Explain Plan Facility
 The AUTOTRACE Utility
 SQL Tuning Information in STATSPACK Output

- 12 -
The SQL Trace Facility

 Set at the instance or session level

 Gathers statistics for SQL statements
 Produces output that can be formatted by TKPROF

Trace
SQL Trace file

Report
TKPROF file
Database

- 13 -
Using the SQL Trace Facility

 Set the initialization parameters.

 Switch on tracing.
 Run the application.
 Format the trace file.
 Interpret the output.

Trace
SQL Trace file

Report
TKPROF file
Database

- 14 -
The TKPROF (Transient Kernel Profiling) Command Options

 SORT = option
 PRINT = n
 EXPLAIN = user/password
 INSERT = filename
 SYS = NO
 AGGREGATE = NO
 RECORD = filename
 TABLE = schema.tablename

- 18 -
Formatting Trace Files using TKPROF

tkprof tracefile outputfile

[options]
TKPROF command examples:
tkprof ora_804.trc run1.txt

C:\oracle\product\10.2.0\db_1\admin\orcl\udump>tkprof
orcl_ora_6492.trc a.txt

TKPROF: Release 10.2.0.1.0 - Production on Mon Feb 3

10:14:32 2014

Copyright (c) 1982, 2005, Oracle. All rights reserved.

- 20 -
Output of the TKPROF Command

 Text of the SQL statement

 Trace statistics (for statement and recursive calls) separated into
three SQL processing steps:

Parse Translates the SQL statement into an execution plan

Execute Executes the statement

(For INSERT, UPDATE, and DELETE statements,
this step modifies the data.)
Fetch Retrieves the rows returned by a query (Fetches
are performed only for SELECT statements.)

- 21 -
Output of the TKPROF Command

Trace statistics listed by seven categories:

count Number of times procedure was executed

CPU Number of seconds to process

elapsed Total number of seconds to execute

disk Number of physical blocks read

query Number of logical buffers read for consistent read

(usually SELECT statements)
current Number of logical buffers read in current mode
(usually Insert, Update, Or Delete statements)
rows Number of rows processed by the fetch or execute

- 22 -
 Row source operations provide
– the number of rows processed for each operation executed on the rows
and additional row source information, such as physical reads and
writes
 In this sample TKPROF output, note the following under the Row
Source Operation column:
– cr specifies consistent reads performed by the row source
– r specifies physical reads performed by the row source
– w specifies physical writes performed by the row source
– time specifies time in microseconds

- 23 -
Output of the TKPROF Command

The TKPROF output also includes the

following:
 Recursive SQL statements
 Library cache misses
 Parsing user ID
 Execution plan
 Optimizer mode or hint

- 24 -
TKPROF Output Example: No Index

select status from registrations

where class_id = 155801 and stud_id = 7586

call count cpu elapsed disk query current rows

------------ ---- ------- ---- ----- ------- ----
Parse 1 0.54 0.56 1 0 0 0
Execute 1 0.01 0.01 0 0 0 0
Fetch 1 0.52 1.47 1159 1160 0 1
------------ ---- ------- ---- ---- ------- ----
total 3 1.07 2.04 1160 1160 0 1

Misses in library cache during parse: 1

Optimizer goal: CHOOSE
Parsing user id: 75

- 25 -
TKPROF Output Example: Unique Index

select status from registrations

where class_id = 155801 and stud_id = 7586

call count cpu elapsed disk query current rows

------------ ---- ------- ---- ----- ------- ----
Parse 1 0.10 0.10 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 0 4 0 1
------------ ---- ------- ---- ---- ------- ----
total 3 0.10 0.10 0 4 0 1

Misses in library cache during parse: 1

Optimizer goal: CHOOSE
Parsing user id: 75

- 26 -
TKPROF Example …Contd

 If you are processing a large trace file using a combination of

SORT parameters and the PRINT parameter, then you can
produce a TKPROF output file containing only the highest
resource-intensive statements.
– For example, the following statement prints the 10 statements in the
trace file that have generated the most physical I/O:
– TKPROF ora53269.trc ora53269.prf SORT = (PRSDSK, EXEDSK, FCHDSK) PRINT =
10
• PRSDSK Number of physical reads from disk during parse.
• EXEDSK Number of physical reads from disk during execute.
• FCHDSK Number of physical reads from disk during fetch.

- 27 -
TKPROF Example …Contd

 To get (TKPROF) sorted by longest running queries first and

limits the results to the “Top 10″ long running queries
 tkprof raw_trace_file.trc output_file sys=no sort=’(prsela,exeela,fchela)’ print=10
– PRSELA Elapsed time spent parsing.
– EXEELA Elapsed time spent executing.
– FCHELA Elapsed time spent fetching.

- 28 -
Analyzing tkprof Results

 So what should DBAs be looking for? Here’s a small checklist of items to

watch for in tkprof formatted files:
– Compare the number of parses to number of executions. A well-tuned system will
have one parse per n executions of a statement and will eliminate the re-parsing
of the same statement.
– Search for SQL statements that do not use bind variables (:variable). These
statements should be modified to use bind variables.
– Identify those statements that perform full table scans, multiple disk reads, and
high CPU consumption. These performance benchmarks are defined by the DBA
and need to be tailored to each database. What may be considered a high
number of disk reads for an OLTP application may not even be minimal for a data

- 29 -
 Demo

 Using SQL Trace and TKProf

– Create a big table
– Do access it using Full table
scan
– Check the Time statistics in
trace
– Create an index
– Hit the table for data retrival
– Analyze the tkProf output.

- 30 -
Creating the Plan Table

• Run a standard script to create a plan table.

SQL> START utlxplan.sql

• Create a plan table manually, with a different name.

SQL> create table my_plan_table
2 (statement_id varchar2(30)
3 ,timestamp date
4 ,remarks varchar2(80)
5 ,operation varchar2(30)
...
)

- 31 -
Using the EXPLAIN PLAN command and the
DBMS_XPLAN.DISPLAY function

 SQL> explain plan for select * from emp;

Explained.
 Query PLAN_TABLE to see the generate Explain Plan
(utlxpls.sql)
SQL> @d:\oracle10g\rdbms\admin\utlxpls.sql

 OR, you can see the explain plan using DBMS_XPLAN package
select * from table(dbms_xplan.display);

- 32 -
EXPLAIN PLAN Example

SQL> EXPLAIN PLAN

2 set statement_id = 'demo_01' for
3 SELECT a.customer_name, a.customer_number,
4 b.invoice_number, b.invoice_type, b.invoice_date,
5 b.total_amount, c.line_number, c.part_number,
6 c.quantity, c.unit_cost FROM customers a, invoices b,
7 invoice_items c WHERE c.invoice_id = :b1 AND
8 c.line_number = :b2 AND b.invoice_id = c.invoice_id
9 AND a.customer_id = b.customer_id;

Explained.

Note: The EXPLAIN PLAN command does not

actually execute the query.

- 33 -
 select job,sum(sal)from emp e, dept d where
e.deptno=d.deptno group by job;

- 34 -
Displaying the Execution Plan

COL id FORMAT 999

COL parent_id FORMAT 999 HEADING "PARENT"
COL operation FORMAT a35 TRUNCATE
COL object_name FORMAT a30
SELECT id, parent_id, LPAD (' ', LEVEL - 1) || operation || ' ' ||
options operation, object_name FROM plan_table
WHERE statement_id = ‘demo_01'
START WITH id = 0 AND statement_id = '&stmt_id'
CONNECT BY
PRIOR id = parent_id AND statement_id = '&stmt_id'; /

- 35 -
Displaying the Execution Plan

Id Parent Operation Object_name

---- ------ ----------------------------------- ---------------------------
0 Select Statement
1 0 Nested Loops
2 1 Nested Loops
3 2 Table Access By Index Rowid Invoice_items
4 3 Index Unique Scan Invoice_items_pk

5 2 Table Access By Index Rowid Invoices

6 5 Index Unique Scan Invoices_pk

7 1 Table Access By Index Rowid Customers

8 7 Index Unique Scan Customers_pk

- 36 -
Understanding the execution plan

 The Oracle Optimizer is a cost-based optimizer.

 The execution plan selected for a SQL statement is just one of the
many alternative execution plans considered by the Optimizer.
 The Optimizer selects the execution plan with the lowest cost,
where cost represents the estimated resource usage for that plan.
 The lower the cost the more efficient the plan is expected to be.
 The optimizer’s cost model accounts for the IO, CPU, and network
resources that will be used by the query.

- 37 -
Reading an Explain Plan

 scott@ORA920> explain plan for

 2 select ename, dname, grade
 3 from emp, dept, salgrade
 4 where emp.deptno = dept.deptno
 5 and emp.sal between salgrade.losal and salgrade.hisal
 6 /
 Explained.
 1
 /\
 2 5
 /\ \
 3 4 6

- 38 -
 scott@ORA920> @?/rdbms/admin/utlxpls
  
 PLAN_TABLE_OUTPUT
 -----------------------------------------------------------------
 | Id | Operation |Name |Rows|Bytes|Cost |
 -----------------------------------------------------------------
 | 0 | SELECT STATEMENT | | | | |
 | 1 | NESTED LOOPS | | | | |
 | 2 | NESTED LOOPS | | | | |
 | 3 | TABLE ACCESS FULL | SALGRADE| | | |
 |* 4 | TABLE ACCESS FULL | EMP | | | |
 | 5 | TABLE ACCESS BY INDEX ROWID| DEPT | | | |
 |* 6 | INDEX UNIQUE SCAN | DEPT_PK | | | |
 -----------------------------------------------------------------
  
 Predicate Information (identified by operation id):
 ---------------------------------------------------
  
 4 - filter("EMP"."SAL"<="SALGRADE"."HISAL" AND
 "EMP"."SAL">="SALGRADE"."LOSAL")
 6 - access("EMP"."DEPTNO"="DEPT"."DEPTNO")

- 39 -
 psuedo code for how the plan is evaluated and then we'll discuss how I
arrived at this conclusion:
  
 For salgrade in (select * from salgrade)
 Loop
 For emp in ( select * from emp )
 Loop
 If ( emp.sal between salgrade.losal and salgrade.hisal )
 Then
 Select * into dept_rec
 From dept
 Where dept.deptno = emp.deptno;
  
 OUTPUT RECORD with fields from salgrade,emp,dept
 End if;
 End loop;
 End loop;
- 40 -
 You should also be able to look at the execution plan and assess if the
Optimizer has made any mistake in its estimations or calculations, leading
to a suboptimal plan. The components to assess are:
 Cardinality– Estimate of the number of rows coming out of each of the
operations.
 Access method – The way in which the data is being accessed, via either a
table scan or index access.
 Join method – The method (e.g., hash, sort-merge, etc.) used to join tables
with each other.
 Join type – The type of join (e.g., outer, anti, semi, etc.).
 Join order – The order in which the tables are joined to each other.
 Partition pruning – Are only the necessary partitions being accessed to
answer the query?
 Parallel Execution – In case of parallel execution, is each operation in the
plan being conducted in parallel? Is the right data redistribution method
being used?

- 41 -
Access Method

 The access method - or access path - shows how the data will be
accessed from each table (or index).
 Full table scan
– Reads all rows from a table and filters out those that do not meet the
where clause predicates.
– A FTS is selected if large portion of the rows in the table must be
accessed, no indexes exist or the ones present can’t be used or if the
cost is the lowest.

Create table try(no number, name varchar2(12));

set autotrace on explain

- 42 -
Access Method …Table access by ROWID

 The rowid of a row specifies the data file, the data block within that
file, and the location of the row within that block.
 Oracle first obtains the rowids either from a WHERE clause
predicate or through an index scan of one or more of the table's
indexes.
 Oracle then locates each selected row in the table based on its
rowid and does a row-by-row access.
 TABLE ACCESS (BY INDEX ROWID) and TABLE ACCESS (BY
USER ROWID

select *from try where

rowid=chartorowid('AAANGKAAEAAAAAlAAA');

- 43 -
Access Method …Index unique scan

 select no from try where no=1

 So the above statement indicates that CBO is performing Index
Unique Scan.
 This means, in order to fetch the id value as requested, Oracle
is actually reading the index only and not the whole table.
 Of course this will be faster than FULL TABLE ACCESS
operation shown earlier.

- 44 -
Access Method …Index range scan

 Oracle accesses adjacent index entries and then uses the ROWID
values in the index to retrieve the corresponding rows from the
table.
 An index will be used when a statement has an equality predicate
on a non-unique index key, or a non-equality or range predicate on
a unique index key. (=, <, >,LIKE if not on leading edge).
 Data is returned in the ascending order of index columns.
– select * from emp where empno>1;

- 45 -
Access Method …Index range scan descending

 Conceptually the same access as an index range scan, but it is

used when an ORDER BY .. DESCENDING clause can be satisfied
by an index.

 select * from emp where empno>1 order by empno desc;

- 46 -
Access Method …Index Skip Scanning

 Normally, in order for an index to be used, the prefix of the index key
(leading edge of the index) would be referenced in the query.
 However, if all the other columns in the index are referenced in the
statement except the first column, Oracle can do an index skip scan,
to skip the first column of the index and use the rest of it.
 This can be advantageous if there are few distinct values in the
leading column of a concatenated index and many distinct values in
the non-leading key of the index.
 In previous releases a composite index could only be used if the first
column, the leading edge, of the index was referenced in the
WHERE clause of a statement.
 In Oracle 9i this restriction is removed because the optimizer can
perform skip scans to retrieve rowids for values that do not use the
prefix.

- 47 -
Access Method …A full index scan

 A full index scan does not read every block in the index structure, contrary
to what
 its name suggests.
 An index full scan processes all of the leaf blocks of an index, but only
enough of
 the branch blocks to find the first leaf block.
 It is used when all of the columns necessary to satisfy the statement are in
the index and it is cheaper than scanning the table. It uses single block IOs.
 It may be used in any of the following situations:
– An ORDER BY clause has all of the index columns in it and the order is the
same as in the index (can also contain a subset of the columns in the
index).
– The query requires a sort merge join and all of the columns referenced in
the query are in the index.
– Order of the columns referenced in the query matches the order of the
leading index columns.
– A GROUP BY clause is present in the query, and the columns in the GROUP
BY clause are present in the index.

- 48 -
A full index scan…Example

- 49 -
Join method

 The join method describes how data from two data producing
operators will be joined together.
 You can identify the join methods used in a SQL statement by
looking in the operations column in the explain plan.

- 50 -
 Hash Joins - Hash joins are used for joining large data sets.
– The optimizer uses the smaller of the two tables or data sources to
build a hash table, based on the join key, in memory.
– It then scans the larger table, and performs the same hashing
algorithm on the join column(s).
– It then probes the previously built hash table for each value and if
they match, it returns a row.
– Smaller result set should be the driving table
– Larger result set should be the inner table

- 51 -
 Nested Loops joins - Nested loops joins are useful when small
subsets of data are being joined and if there is an efficient way of
accessing the second table (for example an index look up).
– For every row in the first table (the outer table), Oracle accesses all
the rows in the second table (the inner table).
– Consider it like two embedded FOR loops.

- 52 -
Sort Merge joins

 Sort merge joins are useful when the join condition between two
tables is an inequality condition such as, <, <=, >, or >=.
 Sort merge joins can perform better than nested loop joins for large
data sets.
 The join consists of two steps:
– Sort join operation: Both the inputs are sorted on the join key.
– Merge join operation: The sorted lists are merged together.
 A sort merge join is more if there is likely to be chosen an index on
one of the tables that will eliminate one of the sorts.

- 53 -
SQL*Plus AUTOTRACE

 Syntax :-
SET AUTOTRACE OFF|ON|TRACEONLY [EXPLAIN] [STATISTICS]

- 54 -
 Sort Merge joins - Sort merge joins are useful when the join
condition between two tables is an inequality condition such as, <,
<=, >, or >=.
 Sort merge joins can perform better than nested loop joins for large
data sets.
 The join consists of two steps:
– Sort join operation: Both the inputs are sorted on the join key.
– Merge join operation: The sorted lists are merged together.

- 55 -
 Cartesian join - The optimizer joins every row from one data source
with every row from the other data source, creating a Cartesian
product of the two sets.
 Typically this is only chosen if the tables involved are small or if one
or more of the tables does not have a join conditions to any other
table in the statement.
 Cartesian joins are not common, so it can be a sign of problem with
the cardinality estimates, if it is selected for any other reason.
Strictly speaking, a Cartesian product is not a join.

- 56 -
SQL*Plus AUTOTRACE Examples

To start tracing statements using

AUTOTRACE:

SQL> SET AUTOTRACE ON

... and hide statement output:

SQL> SET AUTOTRACE TRACEONLY

... and display execution plans only:

SQL> SET AUTOTRACE TRACEONLY EXPLAIN

- 57 -
SQL*Plus AUTOTRACE Examples

To start tracing statements using

AUTOTRACE:

SQL> SET AUTOTRACE ON

... and hide statement output:

SQL> SET AUTOTRACE TRACEONLY

... and display execution plans only:

SQL> SET AUTOTRACE TRACEONLY EXPLAIN

- 58 -
STATSPACK

 Originally introduced in Oracle8i Release 2

 STATSPACK is the updated and much improved cousin of the often-
cryptic REPORT.TXT produced by the UTLBSTAT.SQL and
UTLESTAT.SQL scripts
 It uses a combination of Oracle-supplied SQL scripts and PL/SQL
packages to produce an evaluation of your database’s overall
performance and recommendations regarding possible performance
enhancing changes.

- 59 -
Philosophy behind Oracle DB 10g

 Automation
– Incremental steps in 9i (Advisors, Time)
– Most significant change in Performance management
– “Out of the box” setups
– GUI “hides” the complexity (and details!)
 Consistency
– Common/Unified interface
– Stats storage and presentation
– Interpretation

- 60 -
Reality check before we proceed

 Licensing changes in Oracle Database 10g

 A tale of two packs:
– Oracle Diagnostic Pack
• Automatic Workload Repository (AWR)
• Automatic Database Diagnostic Monitor (ADDM)
• Monitoring and Event notifications and history
– Oracle Tuning Pack
• SQL Access Advisor
• SQL Tuning Advisor and STS
• Object Advisor
 Required even to access Views directly!!!

- 61 -
 EM
Demo

 For BLOCKING SESSIONS

– Logon to Oracle using two
parallel sessions
– Do access one single table
– Try to update using one
session and block the other
session for doing any DML
– Check in EM for these
blocking Sessions.

- 62 -
 EM
Demo

 For DUPLICATE SQL

– Logon to Oracle using SCOTT
session
– Do access one single table
– Try to update using one
session and block the other
session for doing any DML
– Check in EM for these
blocking Sessions.

- 63 -
 EM
Demo

 For BLOCKING SESSIONS

– Logon to Oracle using two
parallel sessions
– Do access one single table
– Try to update using one
session and block the other
session for doing any DML
– Check in EM for these
blocking Sessions.

- 64 -
 EM
Demo

 For DUPLICATE SQL

– Logon to Oracle using two
parallel sessions
– select * from bigtab where
id=&n;
– Check in EM for the
DUPLICATE SQLs

- 65 -
Database Maintenance

Automatic Automated Proactive Reactive

tasks

Advisory Server Critical

framework alerts errors

Automatic Automatic
Workload Diagnostic
Repository Efficient Repository

Data warehouse Automatic collection Direct memory

of the database of important statistics access

- 66 -
AWR Infrastructure

External clients
EM SQL*Plus …

SGA
Efficient V$ DBA_*
in-memory AWR
statistics snapshots
collection MMON

Self-tuning … Self-tuning
ADDM
Internal clients component component

- 67 -
Terminology

– Automatic Workload Repository (AWR): Infrastructure for data gathering,

analysis, and solutions recommendations
– Baseline: A set of AWR snapshots for performance comparison
– Metric: Rate of change in a cumulative statistic
– Statistics: Data collections used for performance monitoring or SQL
optimization
– Threshold: A boundary value against
which metric values are compared

- 68 -
AWR Contents

 Active Session History (ASH)

 High-load SQL statements
 Time model statistics (both System/Session)
 Object usage - access counts for segments
 Snapshots of V$ and some Metrics
 Host CPU and Memory statistics (V$OSSTAT)
 Baseline information
 “Management” type information
– Snapshot details
– Advisor and other parameters

- 69 -
Enterprise Manager and the AWR

- 70 -
Managing the AWR

– Retention period
• Default: Eight days
• Consider storage needs
– Collection interval
• Default: 60 minutes
• Consider storage needs and performance impact
– Collection level
• Basic (disables most ADDM functionality)
• Typical (recommended)
• All (adds additional SQL tuning information to snapshots)

- 71 -
Automatic Database
Diagnostic Monitor (ADDM)

– Runs after each AWR snapshot

– Monitors the instance; detects bottlenecks
– Stores results in the AWR

Snapshots

EM ADDM
ADDM results
AWR

- 72 -
Diagnosing Problems Automatically

 Use Automatic Database Diagnostic Monitor (ADDM) to

automatically:
– Investigate and diagnose performance problems
– Determine the cause
– Provide advice on how to resolve it

- 73 -
The main sections in an AWR report include

 Report Summary: This gives an overall summary of the instance during the
snapshot period, and it contains important aggregate summary information.
 Cache Sizes (end): This shows the size of each SGA region after AMM has
changed them.  This information can be compared to the original init.ora
parameters at the end of the AWR report.
 Load Profile: This important section shows important rates expressed in
units of per second and transactions per second.
 Instance Efficiency Percentages: With a target of 100%, these are high-level
ratios for activity in the SGA.
 Shared Pool Statistics: This is a good summary of changes to the shared
pool during the snapshot period.
 Top 5 Timed Events: This is the most important section in the AWR report. 
It shows the top wait events and can quickly show the overall database
bottleneck.

- 74 -
 Wait Events Statistics Section: This section shows a breakdown of the main
wait events in the database including foreground and background database
wait events as well as time model, operating system, service, and wait
classes statistics.
 Wait Events: This AWR report section provides more detailed wait event
information for foreground user processes which includes Top 5 wait events
and many other wait events that occurred during the snapshot interval.
 Background Wait Events: This section is relevant to the background process
wait events.
 Time Model Statistics: Time mode statistics report how database-processing
time is spent. This section contains detailed timing information on particular
components participating in database processing.
 Operating System Statistics: The stress on the Oracle server is important,
and this section shows the main external resources including I/O, CPU,
memory, and network usage.
 Service Statistics: The service statistics section gives information about how
particular services configured in the database are operating.

- 75 -
SQL Section: This section displays top SQL,
ordered by important SQL execution metrics.

           SQL Ordered by Elapsed Time: Includes SQL statements that took
significant execution time during processing.
           SQL Ordered by CPU Time: Includes SQL statements that consumed
significant CPU time during its processing.
           SQL Ordered by Gets: These SQLs performed a high number of
logical reads while retrieving data.
           SQL Ordered by Reads: These SQLs performed a high number of
physical disk reads while retrieving data.
           SQL Ordered by Parse Calls: These SQLs experienced a high
number of reparsing operations.
           SQL Ordered by Sharable Memory: Includes SQL statements cursors
which consumed a large amount of SGA shared pool memory.
           SQL Ordered by Version Count: These SQLs have a large number of
versions in shared pool for some reason.

- 76 -
 Instance Activity Stats: This section contains statistical
information describing how the database operated during the
snapshot period.
           Instance Activity Stats (Absolute Values): This section
contains statistics that have absolute values not derived from
end and start snapshots.
           Instance Activity Stats (Thread Activity): This report
section reports a log switch activity statistic.

- 77 -
 I/O Section: This section shows the all important I/O activity for
the instance and shows I/O activity by tablespace, data file, and
includes buffer pool statistics.
           Tablespace IO Stats 
           File IO Stats 
           Buffer Pool Statistics 

- 78 -
 Advisory Section: This section show details of the advisories
for the buffer, shared pool, PGA and Java pool.
           Buffer Pool Advisory 
           PGA Aggr Summary: PGA Aggr Target Stats; PGA Aggr
Target Histogram; and PGA Memory Advisory. 
           Shared Pool Advisory 
           Java Pool Advisory 

- 79 -
 Buffer Wait Statistics: This important section shows buffer
cache waits statistics.
 Enqueue Activity: This important section shows how enqueue
operates in the database. Enqueues are special internal
structures which provide concurrent access to various
database resources.
 Undo Segment Summary: This section gives a summary about
how undo segments are used by the database.
 Undo Segment Stats: This section shows detailed history
information about undo segment activity.

- 80 -
 Latch Activity: This section shows details about latch
statistics. Latches are a lightweight serialization mechanism
that is used to single-thread access to internal Oracle
structures.
           Latch Sleep Breakdown
           Latch Miss Sources
           Parent Latch Statistics
           Child Latch Statistics

- 81 -
Segment Section: This report section
provides details about hot segments using
the following criteria:

           Segments by Logical Reads: Includes top segments

which experienced high number of logical reads.
           Segments by Physical Reads: Includes top segments
which experienced high number of disk physical reads.
           Segments by Buffer Busy Waits: These segments have
the largest number of buffer waits caused by their data blocks.
           Segments by Row Lock Waits: Includes segments that
had a large number of row locks on their data.
           Segments by ITL Waits: Includes segments that had a
large contention for Interested Transaction List (ITL). The
contention for ITL can be reduced by increasing INITRANS
storage parameter of the table.

- 82 -
 Dictionary Cache Stats: This section exposes details about
how the data dictionary cache is operating.
 Library Cache Activity: Includes library cache statistics
describing how shared library objects are managed by Oracle.
 SGA Memory Summary: This section provides summary
information about various SGA regions.
 init.ora Parameters: This section shows the original init.ora
 parameters for the instance during the snapshot period.

- 83 -
Some Examples on reading AWR

 Snap Id Snap Time Sessions Cursors/Session

Begin Snap: 112 11-Jun-09 00:00:57 191 6.7
End Snap: 113 11-Jun-09 01:00:11 173 7.4
Elapsed: 59.23 (mins)
DB Time: 710.73 (mins)
 Check the "DB Time" metric. If it is much higher than the elapsed
time, then it indicates that the sessions are waiting for something.

Here in this example, the Elapsed Time is around 60 minutes while

the DB Time is around 700 minutes. This means that 700 minutes of
time is spent by the sessions on waiting.

- 84 -
ADDM Page

- 85 -
SQL Details

- 86 -
Topology Viewer for SQL Details Plan

- 87 -
Session Details

- 88 -
Database Performance Page

- 89 -
Database Performance Page

- 90 -
Real-Time Monitoring Links

 These pages have real-time diagnostic capabilities:

– Top Activity
– Top Consumers
– Instance Activity
– Historical SQL

- 91 -
Top Activity

- 92 -
Top Consumers

- 94 -
Instance Activity

- 95 -
Historical SQL (AWR)

- 96 -
Active Session History (ASH) Report

- 97 -
 Use Active Session History (ASH) reports to perform analysis
of:
– Transient performance problems that typically last for a few minutes
– Scoped or targeted performance analysis by various dimensions or their
combinations, such as time, session, module, action, or SQL_ID

- 98 -
ADDM Findings

- 99 -
ADDM Recommendations

- 100 -
 ADDM
Demo

 Using ADDM at command

line
– Conn using SYS user login
– @C:\oracle\product\10.2.0\db_
1\RDBMS\ADMIN\addmrpt.sql
– Specify the Begin and End
Snapshot Ids
– Enter value for report_name
– Verify the report in the default
Command Prompt path

- 101 -
Automated Maintenance Tasks

- 102 -
Setting Thresholds

- 103 -
Creating and Testing an Alert

1. Specify a threshold.
2. Create a test case.
3. Check for an alert.

1
2

- 104 -
Alerts Notification

- 105 -
AWR – Performance Warehouse

 Performance Data Warehouse for 10g

 Basis for most of the problem detection and reporting
 AWR collects, stores performance data
– Direct memory access (MMNL/MMON)
– In-memory component (V$/Metric views)
– “Persisted” in WR tables (SYSAUX)
– 162 tables – WRI$, WRH$, WRM$
– Exposed via DBA_HIST_* Views
 Self managing “out of the box”
 Set retention, frequency, baseline

- 107 -
ASH – What’s up with sessions

 Historical view of active sessions

 Active sessions sampled every second
 Stored in circular memory buffer
 Every 10th sample persisted in AWR
 V$ACTIVE_SESSION_HISTORY : “In-memory”
 WRH$_ACTIVE_SESSION_HISTORY : “Persisted”
 Enables “after-the-fact” analysis!!!
 Reported via ASHRPT (Not available in 10gR1)
 “Slice-and-dice” analysis can reveal a lot of info

- 108 -
ASH – Session states exposed!

 “On-the-spot” analysis
 Retroactive analysis
– From memory buffer (V$ACTIVE_SESSION_HISTORY)
– From persisted AWR data (WRH$_ACTIVE_SESSION_HISTORY connected via
SNAP_ID)
– Supports manual drill down from AWR/ADDM
 Tracks High load SQL execution behavior
 Determine Blocking sessions and “hot” segments
 SESSION_STATE : “ON CPU” or “WAITING”

- 109 -
Useful sections: AWR Report

 Segment statistics in AWR report

– Same as “Top 5 Segments” in Level 7 STATSPACK reports (9i+)
– Segments by Global Cache Buffer Busy (RAC only, new section in 10g)
– Segments by CR Blocks Received (RAC only)
– Segments by Current Blocks Received (RAC only)
 New GC Load profile and GC Efficiency percentages
Global Cache Load Profile
~~~~~~~~~~~~~~~~~~~~~~~~~ Per Second Per Transaction
--------------- ---------------
Global Cache blocks received: 1,375.70 2.90
Global Cache blocks served: 164.77 0.35
GCS/GES messages received: 5,165.31 10.88
GCS/GES messages sent: 8,684.54 18.30
DBWR Fusion writes: 0.63 0.00
Estd Interconnect traffic (KB) 15,028.80
Global Cache Efficiency Percentages (Target local+remote 100%)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer access - local cache %: 97.41
Buffer access - remote cache %: 0.43
Buffer access - disk %: 2.16

- 110 -
Extracting data from the AWR

 Complete source in paper

 Adaptable for different types of extracts
/* This cursor fetches details of the current snapshot plus the next one using the LEAD function. We will use this to
make sure that there was no DB restart in-between */
cursor snapshot is
select snap_id, lead(snap_id, 1, 0) OVER (ORDER BY snap_id),
startup_time, lead(startup_time, 1) OVER (ORDER BY snap_id),
to_char(begin_interval_time) begin_interval_time,
to_char(end_interval_time) end_interval_time
from sys.dba_hist_snapshot
where instance_number = v_instance_number -- For RAC instances
and dbid = (select dbid from v$database);

- 111 -
Extracting data from the AWR

-- We don't subtract for certain types such as NUM_CPUS, etc.

cursor osstat is
select e.instance_number, e.stat_name,
case
when e.stat_name in ('NUM_CPU_SOCKETS','NUM_CPUS','NUM_CPU_CORES','LOAD')
then e.value
else e.value - b.value
end stat_value
from sys.dba_hist_osstat b, sys.dba_hist_osstat e
where b.stat_id = e.stat_id
and b.snap_id = v_begin_snap_id and e.snap_id = v_end_snap_id
and b.instance_number = e.instance_number
and b.instance_number = v_instance_number;

- 112 -
Extracting data from the AWR

v_instance_number := &1; -- Send this from command line

open snapshot;
LOOP
fetch snapshot into v_begin_snap_id, v_end_snap_id,
v_begin_startup_time, v_end_startup_time,
v_begin_interval_time, v_end_interval_time;
exit when snapshot%NOTFOUND;
-- Run through only if the startup times for both snaps are same!
-- also, avoid the last line (lead will return 0 for end_id)
if ( v_begin_startup_time = v_end_startup_time ) and ( v_end_snap_id != 0 ) then
open osstat;
loop
fetch osstat into v_instance_number, v_stat_name, v_value;
exit when osstat%NOTFOUND;
dbms_output.put_line(v_end_snap_id || ','
|| to_char(v_end_interval_time, 'DD-MON-YY HH24:MI')
|| ',' || v_stat_name || ',' || v_value);
end loop;
close osstat;
end if;
END LOOP;
close snapshot;
end;

- 113 -
Extracting data from the AWR

Sample output: (portion of output)

SQL> @awr_osstat 1
old 38: v_instance_number := &1; -- Send this from command line
new 38: v_instance_number := 1; -- Send this from command line
5363,18-FEB-08 00:00,NUM_CPUS,24
5363,18-FEB-08 00:00,IDLE_TIME,5975106
5363,18-FEB-08 00:00,BUSY_TIME,2664727
5363,18-FEB-08 00:00,USER_TIME,970933
5363,18-FEB-08 00:00,SYS_TIME,1693794
5363,18-FEB-08 00:00,IOWAIT_TIME,531265
5363,18-FEB-08 00:00,LOAD,.3505859375
5363,18-FEB-08 00:00,NUM_CPU_SOCKETS,24
5363,18-FEB-08 00:00,PHYSICAL_MEMORY_BYTES,0
5363,18-FEB-08 00:00,VM_IN_BYTES,23502864
5363,18-FEB-08 00:00,VM_OUT_BYTES,0
--
5364,18-FEB-08 01:00,NUM_CPUS,24
5364,18-FEB-08 01:00,IDLE_TIME,6018339
5364,18-FEB-08 01:00,BUSY_TIME,2684043
5364,18-FEB-08 01:00,USER_TIME,967711
5364,18-FEB-08 01:00,SYS_TIME,1716332
5364,18-FEB-08 01:00,IOWAIT_TIME,600067
<snip>

- 114 -
New features in DBMS_XPLAN

 Excellent alternative for EXPLAIN_PLAN

 Introduced in 9i, expanded in 10g
– DISPLAY_AWR - Plan stored in the AWR
– DISPLAY_CURSOR – V$SQL cursor cache
– DISPLAY_SQLSET - Plan of a given statement stored in a SQL
tuning set (STS)
– Simple to use:
• “select * from table(dbms_xplan.display_awr(‘<SQL_ID>’, options));”
– Displays all child cursors if present

- 115 -
New features in DBMS_XPLAN

SQL> select * from table(dbms_xplan.display_cursor('g6jzbgnku8024',NULL,'ADVANCED'));

PLAN_TABLE_OUTPUT
-------------------------------------------------------------------------------------------
SQL_ID g6jzbgnku8024, child number 0
-------------------------------------
SELECT R.RESPONSIBILITY_NAME FROM FND_RESPONSIBILITY_VL R
WHERE R.RESPONSIBILITY_ID = :1 AND R.APPLICATION_ID = :1
Plan hash value: 3221072286
---------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 2 (100)| |
| 1 | NESTED LOOPS | | 1 | 51 | 2 (0)| 00:00:01 |
|* 2 | INDEX UNIQUE SCAN | FND_RESPONSIBILITY_U1 | 1 | 10 | 1 (0)| 00:00:01 |
| 3 | TABLE ACCESS BY INDEX ROWID| FND_RESPONSIBILITY_TL | 1 | 41 | 1 (0)| 00:00:01 |
|* 4 | INDEX UNIQUE SCAN | FND_RESPONSIBILITY_TL_U1 | 1 | | 0 (0)| |
---------------------------------------------------------------------------------------------------------
Query Block Name / Object Alias (identified by operation id):
-------------------------------------------------------------
1 - SEL$F5BB74E1
2 - SEL$F5BB74E1 / B@SEL$2
3 - SEL$F5BB74E1 / T@SEL$2
4 - SEL$F5BB74E1 / T@SEL$2
Outline Data
-------------

/*+
BEGIN_OUTLINE_DATA
IGNORE_OPTIM_EMBEDDED_HINTS
OPTIMIZER_FEATURES_ENABLE('10.2.0.3')
OPT_PARAM('_b_tree_bitmap_plans' 'false')
OPT_PARAM('_fast_full_scan_enabled' 'false')
*/

- 116 -
New features in DBMS_XPLAN

Peeked Binds (identified by position):

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

1 - :1 (NUMBER): 50357
2 - :1 (NUMBER, Primary=1)

Predicate Information (identified by operation id):

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

2 - access("B"."APPLICATION_ID"=:1 AND "B"."RESPONSIBILITY_ID"=:1)

4 - access("T"."APPLICATION_ID"=:1 AND "T"."RESPONSIBILITY_ID"=:1 AND
"T"."LANGUAGE"=USERENV('LANG'))

Column Projection Information (identified by operation id):

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

1 - "T"."RESPONSIBILITY_NAME"[VARCHAR2,100]
3 - "T"."RESPONSIBILITY_NAME"[VARCHAR2,100]
4 - "T".ROWID[ROWID,10]

SQL_ID g6jzbgnku8024, child number 1

-------------------------------------
SELECT R.RESPONSIBILITY_NAME FROM FND_RESPONSIBILITY_VL R WHERE R.RESPONSIBILITY_ID = :1 AND
R.APPLICATION_ID = :1

<snipped out further information about child cursor 1 and 2>

- 117 -
V$ Performance Views

- 118 -
Wait Events

– Wait events are statistics that are incremented by a server

process/thread to indicate that it had to wait for an event to complete
before being able to continue processing.
– Wait event data reveals various symptoms of problems that might be
impacting performance, such as latch contention, buffer contention, and
I/O contention.
– The following list includes common examples of the waits in some of the
classes:
• Application: locks waits caused by row level locking or explicit lock
commands
• Commit: waits for redo log write confirmation after a commit
• Idle: wait events that signify the session is inactive, such as SQL*Net
message from client
• Network: waits for data to be sent over the network
• User I/O: wait for blocks to be read off a disk

- 119 -
Oracle Wait Events

 A collection of wait events provides information on the

sessions that had to wait or must wait for different
reasons.
– V$EVENT_NAME view:
– EVENT#
– NAME
– PARAMETER1
– PARAMETER2
– PARAMETER3

- 120 -
Time Model Statistics

– Most Oracle advisories and reports describe statistics in terms of time.

– V$SESS_TIME_MODEL and V$SYS_TIME_MODEL views provide time
model statistics.

- 121 -
V$EVENT_NAME View

SQL> SELECT name, parameter1, parameter2, parameter3

2 FROM v$event_name;

NAME PARAMETER1 PARAMETER2 PARAMETER3

------------------------------- ---------- ---------- ----------
PL/SQL lock timer duration
alter system set mts_dispatcher waited
buffer busy waits file# block# id
library cache pin handle addr pin address 0*mode+name
log buffer space
log file switch
(checkpoint incomplete)
transaction undo seg# wrap# count
...
136 rows selected.

- 122 -
Statistics Event Views

 V$SYSTEM_EVENT: Total waits for an event, all sessions

together
 V$SESSION_EVENT: Waits for an event for each session
that had to wait
 V$SESSION_WAIT: Waits for an event for current active
sessions that are waiting

- 123 -
V$SYSTEM_EVENT View

SQL> SELECT event, total_waits, total_timeouts,

2 time_waited, average_wait
3 FROM v$system_event;

EVENT TOTAL_ TOTAL_ TIME_ AVERAGE_

WAITS TIMEOUTS WAITED WAIT
----------------- ------ -------- ------ ----------
latch free 5 5 5 1
pmon timer 932 535 254430 272.993562
process startup 3 8 2.66666667
buffer busy waits 12 0 5 5
...
23 rows selected.

- 124 -
V$SESSION_EVENT View

SQL> select sid, event, total_waits,average_wait

2> from v$session_event where sid=10;

SID EVENT TOTAL_WAITS AVERAGE_WAIT

---- ------------------------------ ----------- -------------
10 buffer busy waits 12 5
10 db file sequential read 129 0
10 file open 1 0
10 SQL*Net message to client 77 0
10 SQL*Net more data to client 2 0
10 SQL*Net message from client 76 0

- 125 -
V$SESSION_WAIT View

SQL> SELECT sid, seq#, event, wait_time, state

2 FROM v$session_wait;

SID SEQ#EVENT WAIT STATE

TIME
---- ------ --------------------------- ----- -------
1 1284 pmon timer 0 WAITING
2 1697 rdbms ipc message 0 WAITING
3 183 rdbms ipc message 0 WAITING
4 4688 rdbms ipc message 0 WAITING
5 114 smon timer 0 WAITING
6 14 SQL*Net message from client -1 WAITED
SHORT
TIME

- 126 -
 The following query shows the distribution of shared pool
memory across different type of objects. It also shows if any of
the objects have been pinned in the shared pool using the
procedure DBMS_SHARED_POOL.KEEP().

SELECT type, kept, COUNT(*), SUM(sharable_mem) FROM

V$DB_OBJECT_CACHE GROUP BY type, kept;

- 127 -
 Finding Objects with Large Number of Loads

SELECT owner, name sharable_mem, kept, loads FROM

V$DB_OBJECT_CACHE WHERE loads > 1 OR invalidations > 0
ORDER BY loads DESC;

- 128 -