Basic Tuning Diagnostics

Objectives

After completing this lesson, you should be able to do the

following:
• View the top wait events to determine the highest wait
• View the time model to diagnose performance issues
• Use dynamic performance views to view statistics and wait
events
• Use Enterprise Manager Monitoring
• Identify the key tuning components of the alert logs
• Identify the key tuning components of user trace files
 Performance Tuning Diagnostics

Diagnostic tools gather and format the following types of

performance data:
• Cumulative statistics:
– Wait events with time information
– Time model
• Metrics: Statistic rates
• Sampled statistics: Active Session History
– Statistics by session
– Statistics by SQL
– Statistics by service
– Other dimensions
 Performance Tuning Tools

Available tools:
• Basic:
– Time model
– Top wait events
– Dynamic performance views and tables
– Alert log
– Trace files
– Enterprise Manager pages
• Add-in: Statspack
• Options:
– Diagnostics Pack
– Tuning Pack
 Tuning Objectives

The objectives of tuning are:

• Minimizing response time
• Increasing throughput
• Increasing load capabilities
• Reducing recovery time
Top Timed Events
 DB Time

DB Time =

DB Wait Time +

DB CPU Time
CPU and Wait Time Tuning Dimensions

DB time = DB CPU time + DB wait time

CPU
time
Possibly Scalable
needs SQL application
tuning

Needs No gain
instance/RAC achieved
tuning by adding
CPUs/nodes
Wait
time
 Time Model: Overview

• The time model is a set of statistics that give an overview of

where time is spent inside the Oracle database.
• All statistics use the same dimension: time.
DB time
• The statistics are accessible through:
– V$SYS_TIME_MODEL Parse

– V$SESS_TIME_MODEL
• DB time represents the total time
SQL
spent in database calls by user sessions.
• A tuning goal is to reduce DB time.
• Using DB time, you can gauge the performance impact of
any entity of the database.
 Time Model Statistics Hierarchy

DB time Background elapsed time

DB CPU Background CPU time
Connection management call elapsed time RMAN CPU time
Sequence load elapsed time (backup/restore)
SQL execute elapsed time
Repeated bind elapsed time
Parse time elapsed
Hard parse elapsed time
Hard parse (sharing criteria) elapsed time
Hard parse (bind mismatch) elapsed time
Failed parse elapsed time
Failed parse (out of shared memory) elapsed time
PL/SQL execution elapsed time
Inbound PL/SQL RPC elapsed time
PL/SQL compilation elapsed time
Java execution elapsed time
Time Model Example
 Dynamic Performance Views

Dynamic performance views

provide access to information
about changing states and
Session data
conditions in the instance. Wait events
Memory allocations
Running SQL
UNDO usage
Open cursors
Redo log usage
And so on

Oracle instance
 Dynamic Performance Views:
Usage Examples

SQL> SELECT sql_text, executions

a 2 FROM v$sqlstats
3 WHERE cpu_time > 200000;

SQL> SELECT * FROM v$session

b 2 WHERE machine = 'EDRSR9P1' and
3 logon_time > SYSDATE - 1;

SQL> SELECT sid, ctime

c 2 FROM v$lock WHERE block > 0;
 Dynamic Performance Views: Considerations

• These views are owned by SYS.

• Different views are available at different times:
– The instance has been started.
– The database is mounted.
– The database is open.
• You can query V$FIXED_TABLE to see all the view names.
• These views are often referred to as “v-dollar views.”
• All reads on these views are current reads.
 Statistic Levels

V$STATISTICS_LEVEL

STATISTICS_LEVEL

BASIC TYPICAL ALL

Disable all Additional statistics

Recommended
self-tuning for manual
default value
capabilities SQL diagnostics
Instance Activity and Wait Event
Statistics

Instance Activity Dynamic

Wait Events performance
views

Reports
 System Statistic Classes

V$SYSSTAT User
Debug

Redo
SQL

System
statistic
classes
RAC
Enqueue

OS
V$STATNAME V$SESSTAT
Cache
 Displaying Statistics

Instance Activity Statistics are collected for:

• Sessions
– All sessions V$SESSTAT
– Current session V$MYSTAT
• Services V$SERVICE_STATS
• System V$SYSSTAT
 Displaying SGA Statistics

SQL> SELECT * FROM V$SGAINFO;

NAME BYTES RES

-------------------------------- ---------- ---
Fixed SGA Size 1303132 No
Redo Buffers 17780736 No
Buffer Cache Size 50331648 Yes
Shared Pool Size 142606336 Yes
Large Pool Size 4194304 Yes
Java Pool Size 12582912 Yes
Streams Pool Size 0 Yes
Shared IO Pool Size 0 Yes
Granule Size 4194304 No
Maximum SGA Size 836976640 No
Startup overhead in Shared Pool 41943040 No
Free SGA Memory Available 608174080
 Wait Events

• A collection of wait events provides information about the

sessions that had to wait or must wait for different reasons.
• These events are listed in the V$EVENT_NAME view, which
has the following columns:
– EVENT#
– NAME
– PARAMETER1 Wait
– PARAMETER2
– PARAMETER3
 Using the 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
...
1118 rows selected.
 Wait Classes
V$SESSION_WAIT_CLASS V$SYSTEM_WAIT_CLASS
Internal database resources
Concurrency
Background
log file sync Commit System I/O processes I/O

Foreground
Network User I/O processes I/O
Network
messaging

Inactive Wait DBA

Idle Administrative commands
sessions classes
User Should be
application Application Other
rare
code

RAC Cluster Configuration Inadequate database/

resources instance configuration
Scheduler
V$SERVICE_WAIT_CLASS Resource manager V$EVENT_NAME
 Displaying Wait Event Statistics
EVENT X X X
TOTAL_WAITS X X X
• Wait event statistics levels: TOTAL TIMEOUTS X X X
– System TIME_WAITED X X X
AVERAGE_WAIT X X X
– Service
TIME_WAITED_MICRO X X X
– Session EVENT_ID X X X
• Wait event statistics columns TOTAL_WAIT_FG X
vary by view. TOTAL_TIMEOUTS_FG X
TIME_WAITED_FG X
V$SYSTEM_EVENT AVERAGE_WAIT_FG X
TIME_WAITED_MICRO_FG X
SID X
V$SERVICE_EVENT
SERVICE_NAME X
SERVICE_NAME_HASH X
V$SESSION_EVENT WAIT_CLASS_ID X X
WAIT_CLASS# X X
WAIT_CLASS X X
 Commonly Observed Wait Events

Wait Event Area

Buffer busy waits Buffer cache, DBWR

Free buffer waits Buffer cache, DBWR, I/O

Db file scattered read, I/O, SQL Tuning

Db file sequential read
Enqueue waits (enq:) Locks

Library cache waits Mutexes/Latches

Log buffer space Log buffer I/O

Log file sync Over-commit, I/O

 Using the 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
 Precision of System Statistics

• Views that include microsecond timings:

– V$SESSION_WAIT, V$SYSTEM_EVENT,
V$SERVICE_EVENT,
V$SESSION_EVENT (TIME_WAITED_MICRO column)
– V$SQL, V$SQLAREA (CPU_TIME, ELAPSED_TIME
columns)
– V$LATCH, V$LATCH_PARENT, V$LATCH_CHILDREN
(WAIT_TIME column)
– V$SQL_WORKAREA, V$SQL_WORKAREA_ACTIVE
(ACTIVE_TIME column)
• Views that include millisecond timings:
– V$ENQUEUE_STAT (CUM_WAIT_TIME column)
 Using Features of the Packs

Monitoring and tuning Monitoring and tuning

with packs without packs
Database Diagnostics Pack
• Automatic Workload Repository • SQL traces
• Automatic Database Diagnostic Monitor (ADDM)
• Active Session History (ASH)
• Statspack
• Performance monitoring (database and host)
• Event notifications: notification methods, rules, and schedules
• System statistics
• Event history and metric history (database and host) • Wait model
• Blackouts
• Dynamic metric baselines • Time model
• Monitoring templates
• OS statistics
Database Tuning Pack Database Configuration
• SQL Access Advisor Management Pack • Metrics
• Database and Host Configuration
• SQL Tuning Advisor
• Deployments
• Service statistics
• Automatic SQL Tuning
• SQL Tuning Sets • Patch Database and View Patch Cache • Histograms
• Automatic Plan Evolution • Patch staging
of SQL Plan Management • Clone Database • Optimizer statistics
• SQL Monitoring • Clone Oracle Home
• Reorganize objects • Search configuration • SQL statistics
• Compare configuration
• Policies
 Accessing the Database Home Page

https://host name:1158/em
 Performance Information
on the Database Home Page
 Viewing the Alert Log

Database Home page > Related Links region >

Alert Log Contents
 Using Alert Log Information
as an Aid in Tuning
The alert log file contains the following information that can be
used to aid in tuning the database:
• Time to perform archiving
• Instance recovery start and complete times
• Deadlock and timeout errors
• Incomplete checkpoints
• Checkpoint start and end times
 User Trace Files

• Server-process tracing can be enabled or disabled at the

session or instance level.
• A user trace file contains statistics for traced SQL
statements in that session.
• User trace files are created on a per server process basis.
• User trace files can also be created by:
– Performing a BACKUP CONTROL FILE TO TRACE
– Process errors
 Background Processes Trace Files

• The Oracle database server dumps information about errors

detected by any background process into trace files.
• Oracle Support uses these trace files to diagnose
and troubleshoot.
• These files do not usually contain tuning information.
 Summary

In this lesson, you should have learned how to:

• View the top wait events to determine highest wait
• View the time model to diagnose performance issues
• Use dynamic performance views to view statistics and wait
events
• Use Enterprise Manager Monitoring
• Identify the key tuning components of the alert logs
• Identify the key tuning components of user trace files