Oracle Week 2017 slides. Agenda: Basics: How and What To Tune? Using the Automatic Workload Repository (AWR) Using AWR-Based Tools: ASH, ADDM Real-Time Database Operation Monitoring (12c) Identifying Problem SQL Statements Using SQL Performance Analyzer Tuning Memory (SGA and PGA) Parallel Execution and Compression Oracle Database 12c Performance New Features

1. Oracle Database Performance Tuning Advanced
Features and Best Practices for DBAs
Zohar Elkayam
CTO, Brillix
Zohar@Brillix.co.il
www.realdbamagic.com
Twitter: @realmgic

2. 2
• Zohar Elkayam, CTO at Brillix
• Programmer, DBA, team leader, database trainer, public speaker, and
a senior consultant for over 19 years
• Oracle ACE Since 2014
• ilOUG Board Member – Israel Oracle User Group
• Blogger – www.realdbamagic.com and www.ilDBA.co.il
Who am I?

3. 3
About Brillix
• We offer complete, integrated end-to-end solutions based on best-of-
breed innovations in database, security and big data technologies
• We provide complete end-to-end 24x7 expert remote database
services
• We offer professional customized on-site trainings, delivered by our
top-notch world recognized instructors

4. 4
Some of Our Customers

5. 5
• Founded in 1999, over 7000 members at its peak
• Divided into Technologies (Databases) and Applications groups
• Free Bi-monthly meetups for DBAs and Developers at Oracle Israel offices
• Yearly conference with guests speakers from all over the world:
• January 22-23, 2018
• Over 30 Speakers from all over the world: Ask TOM team, Oracle product mangers
and Oracle ACEs from 9 different countries!
• You can join our community: meetup group, facebook group or follow us
on twitter (@ilOUG_org)!
• Our website: www.ilOUG.org
ilOUG – Israel Oracle User Group

6. 6
Agenda
• Basics: How and What To Tune?
• Using the Automatic Workload Repository (AWR)
• Using AWR-Based Tools: ASH, ADDM
• Real-Time Database Operation Monitoring (12c)
• Identifying Problem SQL Statements
• Using SQL Performance Analyzer
• Tuning Memory (SGA and PGA)
• Parallel Execution and Compression
• Oracle Database 12c Performance New Features

7. 7
Our Goal Today
• Learning new about SQL techniques
• We will not expert everything
• Get to know some new 12c features
• Hear about Oracle 18c
• This is a starting point – don’t be afraid to try

8. 8
•‫דעתכם‬ ‫חוות‬ ‫את‬ ‫לקבל‬ ‫ונשמח‬ ‫משוב‬ ‫טופס‬ ‫יחולק‬ ‫הסמינר‬ ‫יום‬ ‫בסיום‬.
•‫חשובה‬ ‫דעתכם‬:‫יותר‬ ‫טובים‬ ‫הסמינרים‬ ‫את‬ ‫לעשות‬ ‫לנו‬ ‫המאפשרת‬ ‫זו‬ ‫היא‬!
Our REAL Agenda
10:30-10:45‫הפסקה‬
12:30-13:30‫משתתפ‬ ‫לכל‬ ‫צהריים‬ ‫ארוחת‬‫המלון‬ ‫בגן‬ ‫הכנס‬ ‫י‬
15:00-15:15‫הפנים‬ ‫קבלת‬ ‫במתחם‬ ‫מתוקה‬ ‫הפסקה‬
16:30‫הביתה‬ ‫הולכים‬

9. What Is Tuning Anyway?

10. 10
Who Tunes?
• The people who are involved with tuning:
• Database administrators
• Application architects
• Application designers
• Application developers
• System administrators
• Storage administrators

11. 11
What Does the DBA Tune?
• Performance tuning areas:
• Application:
• SQL statement performance
• Change management
• Instance tuning:
• Memory
• Database structure
• Instance configuration
• Operating system interactions:
• I/O
• Swap
• Parameters
Shared with developers
Shared with SA

12. 12
Tuning During the Life Cycle
Tuning can be divided into two classes:
• Proactive (make it better, so it will not break)
• Test scenarios.
• Find the problem areas.
• Resolve the problem.
• Reactive (wait until it breaks, then fix it)
• Monitor active instance.
• Tune issues as needed.
ReactiveProactive

13. 13
How Does a Tuning Session Should Looks Like
Tuning sessions should have the same basic procedure:
1. Define the problem and state the goal
2. Collect current performance statistics
3. Consider some common performance errors
4. Build a trial solution
5. Implement and measure the change
6. Decide: “Did the solution meet the initial goal?”
• No? Then go to step 3 and repeat.
• Yes? Then create a new baseline.

14. 14
Tuning Methodology
• Tune the following from the top down:
• The design before tuning the application code
• The code before tuning the instance
• Tune the area with the greatest potential benefit—identify:
• The longest waits
• The largest service times
• Stop tuning when the goal is met

15. 15
Defining the Problem
Users DBA
Monitor
Reports and files
Database
instance
Feedback

16. 16
Tuning Objectives and Goals
• The objectives of tuning
• Minimizing response time
• Increasing throughput
• Increasing load capabilities
• Decreasing recovery time
• Effective tuning goals
• Specific
• Measurable
• Achievable

17. 17
Okay, So How do we Tune?
• Basic tools:
• Dynamic performance views (v$, gv$, x$)
• System Statistics
• Database Metrics
• Enterprise Manager pages
• Database internal tools
• Database options: diagnostic/tuning pack - AWR, ASH, ADDM
• Statspack (Add-in for SE or when no packs)
• Various custom DBA scripts
• External tools: TOAD, SQL Developer, etc.

18. 18
Using Features of the Packs

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

20. 20
DB Time
DB Time =
DB Wait Time +
DB CPU Time

21. 21
CPU and Wait Time Tuning Dimensions
Scalable
application
Possibly
needs SQL
tuning
Needs
instance/RAC
tuning
CPU
time
Wait
time
No gain
achieved
by adding
CPUs/nodes
DB time = DB CPU time + DB wait time

22. 22
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.
• The statistics are accessible through:
• V$SYS_TIME_MODEL
• V$SESS_TIME_MODEL
• DB time represents the total
time spent in database calls.
• A tuning goal is to reduce DB time.
• Using DB time, you can gauge the performance impact of any entity of the
database.
SQL
Parse
DB time

23. 23
Time Model Statistics Hierarchy
Failed parse (out of shared memory) elapsed time
DB time
DB CPU
Connection management call elapsed time
Sequence load elapsed time
SQL execute 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
PL/SQL execution elapsed time
Inbound PL/SQL RPC elapsed time
PL/SQL compilation elapsed time
Java execution elapsed time
Repeated bind elapsed time
Background elapsed time
Background CPU time
RMAN CPU time
(backup/restore)

24. 25
Time Model Example

25. 26
Dynamic Performance Views
• Dynamic performance views provide
access to information about
changing states and conditions in the
instance.
Session data
Wait events
Memory allocations
Running SQL
UNDO usage
Open cursors
Redo log usage
And so on
Oracle instance

26. 27
Dynamic Performance Views:
Usage Examples
SQL> SELECT sql_text, executions
2 FROM v$sqlstats
3 WHERE cpu_time > 200000;
SQL> SELECT * FROM v$session
2 WHERE machine = 'EDRSR9P1' and
3 logon_time > SYSDATE - 1;
SQL> SELECT sid, ctime
2 FROM v$lock WHERE block > 0;
a
b
c

27. 28
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.”
• Read consistency is not guaranteed on these views because the data
is dynamic.

28. 29
Statistic Levels
STATISTICS_LEVEL
BASIC TYPICAL ALL
Recommended
default value
Additional statistics
for manual
SQL diagnostics
Disable all
self-tuning
capabilities
V$STATISTICS_LEVEL

29. 30
Statistics and Wait Events
Reports
Dynamic
performance
views
Statistics
Wait events

30. 31
System Statistic Classes
Cache
Debug
RAC
SQL
Redo
User
Enqueue
OS
V$SYSSTAT
V$SESSTATV$STATNAME
System
statistic
classes

31. 32
Displaying Statistics
• Statistics are collected for:
• Sessions
• All sessions V$SESSTAT
• Current session V$MYSTAT
• Services V$SERVICE_STATS
• System V$SYSSTAT

32. 33
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
• PARAMETER2
• PARAMETER3
Wait

33. 34
Using the V$EVENT_NAME View
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
...
961 rows selected.
SQL> SELECT name, parameter1, parameter2, parameter3
2 FROM v$event_name;

34. 35
Wait Classes
Scheduler
Cluster Configuration
Commit
Application
Administrative
Network
User I/O
Concurrency
System I/O
Other
Idle
Background
processes I/O
Foreground
processes I/O
DBA
commands
Should be
rare
Inadequate database/
instance configuration
Resource manager
RAC
resources
User
application
code
Inactive
sessions
Network
messaging
log file sync
Internal database resources
V$SESSION_WAIT_CLASS
V$SERVICE_WAIT_CLASS
V$SYSTEM_WAIT_CLASS
V$EVENT_NAME
Wait
classes

35. 36
Displaying Wait Event Statistics
• Wait event statistics levels:
• System
• Service
• Session
• Wait event statistics columns
vary by view.
V$SERVICE_EVENT
V$SYSTEM_EVENT
V$SESSION_EVENT
EVENT X X X
TOTAL_WAITS X X X
TOTAL TIMEOUTS X X X
TIME_WAITED X X X
AVERAGE_WAIT X X X
TIME_WAITED_MICRO X X X
EVENT_ID X X X
TOTAL_WAIT_FG X
TOTAL_TIMEOUTS_FG X
TIME_WAITED_FG X
AVERAGE_WAIT_FG X
TIME_WAITED_MICRO_FG X
SID X
SERVICE_NAME X
SERVICE_NAME_HASH X
WAIT_CLASS_ID X X
WAIT_CLASS# X X
WAIT_CLASS X X

36. 38
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,
Db file sequential read
I/O, SQL Tuning
Enqueue waits (enq:) Locks
Library cache waits Latches
Log buffer space Log buffer I/O
Log file sync Over-commit, I/O

37. 39
Using the V$SESSION_WAIT View
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
SQL> SELECT sid, seq#, event, wait_time, state
2 FROM v$session_wait;

38. 41
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)

39. Statspack

40. 43
Statspack
• Since Oracle 7 (1992!), the database is counting wait events for
various wait operations
• Timed events were gathered in the instance level (non persistent)
• In Oracle 8.1.6 a new feature for diagnosing the wait events was
added: Statspack
• This tool doesn’t require license or additional costs
• Can run on Standard Edition
• Very limited information (in comparison to other solutions)

41. 44
What Does Statspack Do?
• Snapshots: select and persist over 50 different internal tables and
views:
• V$
• X$
• DBA Views
• Manual operation: take snapshot before and after expected load
• Calculates Deltas and Ratios
• Reports output in a 1000-2000 lines output you can diagnose

42. 45
Installing and Using
• Install
• Connect as SYSDBA
• Use @?/rdbms/admin/spcreate.sql to create the objects and
packages (create a tablespace first to store the objects!)
• Must have parameter timed_statistics set to TRUE (default)
• Run
• Manually execute statspack.snap to take a snapshot of current state
• [We used to use BSTAT and ESTAT, not anymore]
• Generate Report
• Use @?/rdbms/admin/spreport.sql

43. 46
Create, View and Delete Snapshots
SQL> exec statspack.snap;
PL/SQL procedure successfully completed.
SQL> r
1 select name,snap_id,to_char(snap_time,'DD.MM.YYYY:HH24:MI:SS')"Date/Time“, SNAP_LEVEL
2* from stats$snapshot,v$database
NAME Snap Id Date/Time SNAP_LEVEL
--------- -------- ------------------- ----------
ORCL 1 10.11.2017:09:34:05 5
ORCL 2 10.11.2017:10:17:29 5
ORCL 3 10.11.2017:10:32:34 5
ORCL 4 10.11.2017:11:35:09 5
SQL> @?/rdbms/admin/sppurge;
[…]
Specify the Lo Snap Id and Hi Snap Id range to purge
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[…]

44. 47
Changing the SNAP_LEVEL
• We can run statistics in multiple levels
SQL> SELECT * FROM stats$level_description ORDER BY snap_level;
SNAP_LEVEL DESCRIPTION
---------- ------------------------------------------------------------------------------------------
0 This level captures general statistics, including rollback segment, row cache, SGA,
system events, background events, session events, system statistics, wait statistics, lock
statistics, and Latch information
5 This level includes capturing high resource usage SQL Statements, along with all data
captured by lower levels
6 This level includes capturing SQL plan and SQL plan usage information for high resource
usage SQL Statements, along with all data captured by lower levels
7 This level captures segment level statistics, including logical and physical reads, row
lock, itl and buffer busy waits, along with all data captured by lower levels
10 This level includes capturing Child Latch statistics, along with all data captured by
lower levels
SQL> exec statspack.snap(i_snap_level => 6);

45. 48
Generating a Report
• Run the report using spreport.sql
• Choose begin snap and end snap
• Generates a text based report
SQL> @?/rdbms/admin/spreport.sql
[...]
Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for begin_snap: 1
Begin Snapshot Id specified: 1
Enter value for end_snap: 5
End Snapshot Id specified: 5
[...]
End of Report ( sp_1_5.lst )

46. 49
Reading a Statspack Report
• Basic information and DB Time
STATSPACK report for
Database DB Id Instance Inst Num Startup Time Release RAC
~~~~~~~~ ----------- ------------ -------- --------------- ----------- ---
1475408233 orcl 1 25-Jun-17 21:59 12.2.0.1.0 NO
Host Name Platform CPUs Cores Sockets Memory (G)
~~~~ ---------------- ---------------------- ----- ----- ------- ------------
lnx7-oracle-1 Linux x86 64-bit 1 1 1 3.6
Snapshot Snap Id Snap Time Sessions Curs/Sess Comment
~~~~~~~~ ---------- ------------------ -------- --------- ------------------
Begin Snap: 1 10-Nov-17 11:34:05 42 .9
End Snap: 5 10-Nov-17 11:44:46 43 .9
Elapsed: 10.68 (mins) Av Act Sess: 0.0
DB time: 0.07 (mins) DB CPU: 0.06 (mins)

47. 50
Reading a Statspack Report: Load
Load Profile Per Second Per Transaction Per Exec Per Call
~~~~~~~~~~~~ ------------------ ----------------- ----------- -----------
DB time(s): 0.0 0.5 0.00 0.03
DB CPU(s): 0.0 0.4 0.00 0.02
Redo size: 20,245.0 1,441,893.8
Logical reads: 124.7 8,882.0
Block changes: 69.4 4,944.6
Physical reads: 0.0 3.1
Physical writes: 5.2 369.8
User calls: 0.2 16.9
Parses: 5.1 359.4
Hard parses: 0.8 55.9
W/A MB processed: 0.4 30.6
Logons: 0.1 5.4
Executes: 14.6 1,036.4
Rollbacks: 0.0 0.0
Transactions: 0.0
[...]
Host CPU (CPUs: 1 Cores: 1 Sockets: 1)
~~~~~~~~ Load Average
Begin End User System Idle WIO WCPU
------- ------- ------- ------- ------- ------- --------
0.09 0.00 1.51 0.45 97.74 0.05

48. 51
Reading a Statspack Report: Efficiency
Instance Efficiency Indicators
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 99.98 Redo NoWait %: 100.00
Buffer Hit %: 99.96 Optimal W/A Exec %: 100.00
Library Hit %: 92.09 Soft Parse %: 84.45
Execute to Parse %: 65.32 Latch Hit %: 100.00
Parse CPU to Parse Elapsd %: 91.80 % Non-Parse CPU: 94.07
Shared Pool Statistics Begin End
------ ------
Memory Usage %: 79.82 84.86
% SQL with executions>1: 44.68 48.85
% Memory for SQL w/exec>1: 44.58 49.68

49. 52
Reading a Statspack Report: Wait Events
• Time Model System Stats
• Top 5 wait events
• More events information: foreground, background, mixed and even
histograms
Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Call Time
-------------------------------------------- ------------ ----------- ---------
CPU time 122 91.65
db file sequential read 1,571 2 1.61
db file scattered read 1,174 2 1.59
log file sequential read 342 2 1.39
control file parallel write 450 2 1.39

50. 53
Reading a Statspack Report: Top SQL
• Top SQL based on CPU, Elapsed, Gets, etc.
• Note:
• No full SQL for long text queries (and no SQL_ID – just the old hash value)
SQL ordered by CPU DB/Inst: ORCL/orcl Snaps: 1-5
-> Total DB CPU (s): 3
-> Captured SQL accounts for 334.0% of Total DB CPU
-> SQL reported below exceeded 1.0% of Total DB CPU
CPU CPU per Elapsd Old
Time (s) Executions Exec (s) %Total Time (s) Buffer Gets Hash Value
---------- ------------ ---------- ------ ---------- --------------- ----------
2.59 1 2.59 75.4 2.74 16,543 1141143835
Module: MMON_SLAVE
BEGIN sys.dbms_auto_report_internal.i_save_report (:rep_ref, :sn
ap_id, :pr_class, :
rep_id, :suc); END;

51. 54
What Else In the Report?
• General usage statistics
• OS Statistics
• IO Information
• File IO Stats
• Tablespace IO Stats
• File Read Histogram Stats
• Latch Information
• Some advisories output
• Parameter file output

52. 55
The Disadvantages of Statspack
• Manual:
• No automatic gathering of data (use jobs/scheduled jobs to collect)
• No automatic purging of data
• Very limited information is actually being gathered
• Statspack is a script based snapshot. If the script didn’t run (because of
load, for example), no data is gathered at all
• Information is only used for its own report – gathered information is not
used for advisories or database internal tools
• Text only reports
• Doesn’t really support RAC related information

53. AWR – Automatic Workload
Repository

54. 57
Automatic Workload Repository
• Performance Data Warehouse started in Oracle 10g
• AWR collects and stores the performance data from
• In-memory component (V$/Metric views)
• Data is persisted in the WR tables (use the SYSAUX tablespace)
• Over 162 tables – WRI$, WRH$, WRM$
• Self managing out of the box
• Set retention, frequency, baseline

55. 58
Automatic Workload Repository: Overview
SGA
V$ DBA_*
ADDM
Self-tuning
component
Self-tuning
component
…
Internal clients
External clients EM SQL*Plus …
Efficient
in-memory
statistics
collection
AWR
snapshotsMMON
Where the magic happens

56. 59
AWR – “Statspack on Steroids”
• Snapshots concept is similar to the Statspack snapshots but are not
collected by job or script (MMON)
• AWR snapshot automatically analyzed for advisories and other tools
• Reports are accessible via GUI, scripts (awrrpt.sql, awrrpti.sql,
awrsqrpt.sql) and PL/SQL
• Information is also accessible by querying WRH$ tables and DBA_HIST_*
views
• High-impact SQL captured differently
• Stores session level info as well as OS information
• Gathers RAC information from all nodes at the same time

57. 60
What does the AWR collect?
Advisor
results
AWR
SQL
statistics
Base
statistics
Metrics ASH

58. 61
What does the AWR collect?
• Active Session History (ASH)
• Time model statistics (both System/Session)
• High-load SQL statements
• Object usage - access counts for various segments
• Snapshots of V$ and some Metrics
• OS related information

59. 62
Workload Repository Snapshot
SYSAUX
SGA
In-memory
statistics
6:00 a.m.
7:00 a.m.
8:00 a.m.
Snapshot 1
Snapshot 2
Snapshot 3
Snapshot 4
9:00 a.m.
9:30 a.m.
ADDM finds
top problems.
MMON

60. 63
Rule of Thumb: Sampling
• The AWR default sample is every 1 hour. That might not be enough so
we might want to consider increase the sample to every 15 minutes
• The AWR default retention is 8 days. We might want to increase the
value to a higher number
• Changes to the AWR can be done by GUI or using
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS
• Saving the information takes space, this can be analyzed using
awrinfo.sql

61. 64
AWR Snapshot Settings
• Sample every 15 minutes, keep data for 30 days:
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS (
retention IN NUMBER DEFAULT NULL,
interval IN NUMBER DEFAULT NULL,
topnsql IN NUMBER DEFAULT NULL);
DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS (
retention => 30 * 24 * 60,
interval => 15);

62. 65
Database Control and AWR
Edit snapshot parameters
Run AWR report
Manage snapshots
Manage baselines

63. 66
Generating AWR Reports in EM

64. 67
Generating AWR Reports in EM

65. 68
Using the AWR Scripts
• Scripts are on the database server (?/rdbms/admin)
• awrrpt.sql Workload Repository Report for a database/instance
• awrrpti.sql Workload Repository Report for an Instance
• awrddrpt.sql AWR Diff-Diff report
• awrextr.sql frontends a DataPump dump
• awrsqrpt.sql Execution statistics for specific SQL statement
• awrinfo.sql Space usage by AWR/ASH

66. 69
Generating AWR Reports in SQL*Plus
• AWR PL/SQL interface is a package: DBMS_WORKLOAD_REPOSITORY
• We can use the package to generate reports (HTML or TEXT)
programmatically:
DBMS_WORKLOAD_REPOSITORY.AWRRPT_REPORT_TEXT (
L_DBID NUMBER IN,
L_INST_NUM NUMBER IN,
L_BID NUMBER IN,
L_EID NUMBER IN,
L_OPTIONS NUMBER IN DEFAULT NULL);

67. 70
Generating AWR Report from Client
Set heading off trimspool off linesize 80 feedback off termout on
Spool awr_from_console.txt
select output from table(dbms_workload_repository.awr_report_text(
&dbid, &inst_num, &bid, &eid));
spool off;
SQL> Spool awr_from_console.txt
SQL> select output from table(dbms_workload_repository.awr_report_text(&dbid, &inst_num, &bid, &eid));
Enter value for dbid: 2492639615
Enter value for inst_num: 1
Enter value for bid: 953
Enter value for eid: 954
old 1: select output from table(dbms_workload_repository.awr_report_text(&dbid, &inst_num, &bid,
&eid))
new 1: select output from table(dbms_workload_repository.awr_report_text(1475408233 , 1, 20, 21))

68. 71
OUTPUT
--------------------------------------------------------------------------------------------------------
WORKLOAD REPOSITORY report for
DB Name DB Id Unique Name DB Role Edition Release RAC CDB
------------ ----------- ----------- ---------------- ------- ---------- --- ---
ORCL 1475408233 orcl PRIMARY EE 12.2.0.1.0 NO YES
Instance Inst Num Startup Time
------------ -------- ---------------
orcl 1 25-Jun-17 21:59
Container DB Id Container Name Open Time
--------------- --------------- ---------------
675430203 ORCLPDB 25-Jun-17 22:06
1475408233 CDB$ROOT 25-Jun-17 21:06
Host Name Platform CPUs Cores Sockets Memory(GB)
---------------- -------------------------------- ---- ----- ------- ----------
lnx7-oracle-1 Linux x86 64-bit 1 1 1 3.61
Snap Id Snap Time Sessions Curs/Sess PDBs
--------- ------------------- -------- --------- -----
Begin Snap: 20 10-Nov-17 11:17:13 54 .5 1
End Snap: 21 10-Nov-17 12:00:21 43 1.0 1
Elapsed: 43.12 (mins)
DB Time: 0.31 (mins)

69. Reading AWR Report

70. 73
How to Read AWR?
• Depends on the type of application
• OLTP
• OLAP/DWH
• Depends on the problem: what are we looking for?
• High CPU/High load (database or OS related)?
• IO issue – is it reading or writing? Who is generating the IO?
• Long/intensive queries?
• Memory or buffer related problem?
• “Just plain slow”
• Everyone has their own reading style: this is my own method
• We will usually try to generate a report for an hour or two. Sampling a
larger range will often be statistical mistake

71. 74
Getting Started: AWR Header

72. 75
Top 10 Foreground Events

73. 76
Wait Classes

74. 77
Main Report

75. 78
Wait Event Statistics
• Wait Events
• Timed Model
• Foreground and Background

76. 79
Foreground and Background Wait Events
• Breakdown of wait class into Foreground (user waited) and
Background (instance internals)
• Foreground events are showed as Classes (grouped) too
• Background events are usually TMI but sometimes we can spot
something important

77. 80
Time Model Statistics

78. 81
Foreground Wait Class

79. 82
Foreground Wait Events

80. 83
Understanding the Wait Event Histogram
• Wait events are broken down into histograms for better
understanding of the statistical diversion

81. 84
Understanding the Wait Event Histogram

82. 85
Break It Down Even More…

83. 86
SQL Statistics Menu
• The SQL Statistics menu can help us find the long running or intensive
queries in our database
• Not all queries are gathered into the SQL statistics report - just the
top queries over time by different measures

84. 87
Top SQL Reports
SQL by Elapsed Time
SQL by CPU Time
SQL by Executions
SQL by Buffer Gets

85. 88
IO Stats
• IO Stats can help us diagnose problems coming from the IO
subsystems
• We can monitor information by function, tablespace or actual file (on
specific disk/LUN)

86. 89
IOStat by Function/Filetype

87. 90
IO Stats
• Tablespace IO Stats
• File IO Stats

88. 91
Information by Segment

89. 92
Segments by Write/Changes

90. 93
Common Tuning Cases
• Inefficient or high-load SQL statements
• Suboptimal use of Oracle Database by the application
• Concurrency or locking issues
• I/O issues
• Database configuration issues (e.g. Undersized memory structures)
• Short-lived performance problems
• Degradation of database performance over time
• Unexpected performance regression after environment changes

91. 94
AWR in Oracle 12c
• A lot of new events and statistics
• By default, data is gathered at the root level container
• Data can be gathered at the container level
• Reports can be generated from each container at the root level
(default) or by container level (if sampled)
• A new type of report: 'active-html' which Includes Performance Hub
active report (requires flash)

92. Other AWR Tools:
ASH - Active Session History

93. 96
ASH – What’s Up With Active Sessions
• Historical view of active sessions
• Data can be queried from V$ACTIVE_SESSION_HISTORY
• Active sessions (only) sampled every second
• Stored in circular memory buffer
• Every 10th sample, data is persisted to the AWR
• Enables “after-the-fact” analysis

94. 97
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)
• Easy to find high load SQL execution behavior
• Determine Blocking sessions and “hot” segments
• SESSION_STATE : “ON CPU” or “WAITING”

95. 98
Active Session History: Mechanics
SGA
Statistics
V$SESSION
ASH
Recent history
Rolling
buffer
Workload repository
1sec
1sec
1sec
Every
60 minutes
MMON
MMNL
When 66% full
V$ACTIVE_SESSION_HISTORY
WRH$_ACTIVE_SESSION_HISTORY (partitioned)
No use
of SQL
Direct path
inserts
DBA_HIST_ACTIVE_SESSION_HISTORY
1 out
of 10
Viewers go
unlatched.

96. 99
ASH Report
• Summary of all user activity over the selected period
• Drill down to a more granular period
• List details of only a Session, SQL ID, Wait Class, Service, Module or
Client ID over a particular period
• “Top” Background events, P1-P3 values, etc.
• ?/rdbms/admin/ashrpt.sql + GUI
• In 12c – part of the regular AWR report

97. 100
Generating ASH Reports

98. 101
ASH in Wait Drilldown

99. 102
ASH Report: General Section
V$ACTIVE_SESSION_HISTORY
DBA_HIST_ACTIVE_SESSION_HISTORY

100. 103
ASH Report Structure

101. 104
ASH Report: Activity Over Time

102. 105
Activity Over Time
Activity Over Time DB/Inst: ORCL/orcl (Nov 10 14:19 to 14:34)
-> Analysis period is divided into smaller time slots
-> Top 3 events are reported in each of those slots
-> 'Slot Count' shows the number of ASH samples in that slot
-> 'Event Count' shows the number of ASH samples waiting for
that event in that slot
-> '% Event' is 'Event Count' over all ASH samples in the analysis period
Slot Event
Slot Time (Duration) Count Event Count % Event
-------------------- -------- ------------------------------ -------- -------
14:19:35 (25 secs) 2 CPU + Wait for CPU 1 5.88
oracle thread bootstrap 1 5.88
14:20:00 (2.0 min) 2 CPU + Wait for CPU 1 5.88
control file parallel write 1 5.88
14:22:00 (2.0 min) 5 CPU + Wait for CPU 3 17.65
log file parallel write 1 5.88
oracle thread bootstrap 1 5.88
14:24:00 (2.0 min) 2 control file parallel write 1 5.88
oracle thread bootstrap 1 5.88
14:26:00 (2.0 min) 1 CPU + Wait for CPU 1 5.88
14:28:00 (2.0 min) 1 CPU + Wait for CPU 1 5.88
14:30:00 (2.0 min) 3 control file parallel write 2 11.76
oracle thread bootstrap 1 5.88
14:32:00 (2.0 min) 1 CPU + Wait for CPU 1 5.88
-------------------------------------------------------------

103. Other AWR Tools:
ADDM - Automatic Database
Diagnostic Monitor

104. 107
ADDM – Your unpaid Tuning Expert!
• Should be the starting point for most investigations
• Runs after every AWR snapshot
• Determines and records performance issue
• Recommends corrective action
• Generates probable benefit
• Suggest use of other advisors
• Common currency - “DB Time” (qualitative!)

105. 108
ADDM Performance Monitoring layout
Snapshots
ADDM
In-memory
statistics
AWR
SGA
60 minutes
ADDM results
MMON

106. 109
Database Control and ADDM Findings

107. 110
ADDM Analysis Results
1
2
3

108. 111
ADDM Recommendations

109. 112
Database Control and ADDM Task

110. 113
Top Performance Issues Detected

111. 114
ADDM – Findings/Recommendations
• Hardware changes
• Database-configuration changes
• Schema-level changes
• Application changes
• Using other advisors (for example)
• SQL Tuning / Access Advisor
• Segment Advisor

112. 115
ADDM – Accessing “ADDuM”
• GUI! (easiest because of linkage)
• ?/rdbms/admin/addmrpt.sql
• API – DBMS_ADVISOR In-built PL/SQL
• Look at following views
• DBA_ADVISOR_LOG
• DBA_ADVISOR_FINDINGS
• DBA_ADVISOR_RECOMMENDATIONS
• DBA_ADVISOR_ACTIONS
• DBA_ADVISOR_RATIONALE

113. 116
Retrieving ADDM Reports by Using SQL
SELECT dbms_advisor.GET_TASK_REPORT(task_name)
FROM dba_advisor_tasks
WHERE task_id = (
SELECT max(t.task_id)
FROM dba_advisor_tasks t,
dba_advisor_log l
WHERE t.task_id = l.task_id AND
t.advisor_name = 'ADDM' AND
l.status = 'COMPLETED');
SQL> @?/rdbms/admin/addmrpt
…
Enter value for begin_snap: 8
Enter value for end_snap: 10
…
Enter value for report_name:
Generating the ADDM report for this analysis ...

114. 117
ADDM – Don’t Stare At The Screen!
SQL> select type, count(*) from dba_advisor_findings
where task_id in
(select task_id from dba_advisor_log
where execution_start > sysdate - 1)
group by type;
TYPE COUNT(*)
----------- --------
INFORMATION 46
WARNING 1
SYMPTOM 49
PROBLEM 79

115. 118
ADDM – Don’t Stare At The Screen!
SQL> select count(*) count, message from dba_advisor_findings
where task_id in
(select task_id from dba_advisor_log
where execution_start > sysdate - 1)
and type = 'PROBLEM‘ group by message order by 1 desc;
COUNT MESSAGE
----- -----------------------------------------------------------------
24 SQL statements consuming significant database time were found.
24 SQL statements were found waiting for row lock waits.
24 Individual database segments responsible for significant user I/O wait were found.
4 The execution plan of this statement can be improved by creating one or more indices
1 PL/SQL execution consumed significant database time.
1 Significant virtual memory paging was detected on the host operating system.
1 The throughput of the I/O subsystem was significantly lower than expected

116. 119

117. 120

118. 121

119. When the SQL is the Problem
Identifying Problem SQL Statements

120. 123
Identifying Bad SQL
• Bad SQL uses more resources than necessary.
• Bad SQL has the following characteristics:
• Long parse time
• Excessive I/O (physical reads and writes)
• Excessive CPU time
• Excessive waits
• In this session, we will identify the issues but not solve them

121. 124
TOP SQL Reports
SQL Ordered by CPU Time
SQL Ordered by Gets

122. 125
What Is an Execution Plan?
• An execution plan is a set of steps that the optimizer performs when
executing a SQL statement and performing an operation.
HJ
SORT
HJ

123. 126
Uses of Execution Plans
• Determining the current execution plan
• Identifying the effect of indexes
• Determining access paths
• Verifying the use of indexes
• Verifying which execution plan may be used
HJ
SORT
NL
HJ
SORT
HJ

124. 127
Methods for Viewing Execution Plans
• EXPLAIN PLAN (watch out! Might not be the actual running plan!)
• V$SQL_PLAN
• SQL Trace
• Automatic Workload Repository
• SQL*Plus AUTOTRACE

125. 128
DBMS_XPLAN Package: Overview
• The DBMS_XPLAN package provides an easy way to display the
output from the:
• EXPLAIN PLAN command
• Automatic Workload Repository (AWR)
• V$SQL_PLAN and V$SQL_PLAN_STATISTICS_ALL fixed views
• The DBMS_XPLAN package supplies three table functions that can
be used to retrieve and display the execution plan:
• DISPLAY
• DISPLAY_AWR
• DISPLAY_CURSOR

126. 129
EXPLAIN PLAN Command: Output
Plan hash value: 1343509718
-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU|
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 106 | 2862 | 6 (17|
| 1 | MERGE JOIN | | 106 | 2862 | 6 (17|
| 2 | TABLE ACCESS BY INDEX ROWID| DEPARTMENTS | 27 | 432 | 2 (0|
| 3 | INDEX FULL SCAN | DEPT_ID_PK | 27 | | 1 (0|
|* 4 | SORT JOIN | | 107 | 1177 | 4 (25|
| 5 | TABLE ACCESS FULL | EMPLOYEES | 107 | 1177 | 3 (0|
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")
filter("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")
18 rows selected.
SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY());

127. 130
Using the V$SQL_PLAN View
• V$SQL_PLAN provides a way of examining the execution plan for
cursors that were recently executed.
• Information in V$SQL_PLAN is very similar to the output of an
EXPLAIN PLAN statement:
• EXPLAIN PLAN shows a theoretical plan that can be used if this statement
were to be executed.
• V$SQL_PLAN contains the actual plan used.
• Really important to remember that when Adaptive Plans is enabled

128. 131
Querying V$SQL_PLAN
SQL_ID cfz0cdukrfdnu, child number 0
-------------------------------------
SELECT e.last_name, d.department_name
FROM hr.employees e, hr.departments d WHERE
e.department_id =d.department_id
Plan hash value: 1343509718
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU|
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 6 (100|
| 1 | MERGE JOIN | | 106 | 2862 | 6 (17|
| 2 | TABLE ACCESS BY INDEX ROWID| DEPARTMENTS | 27 | 432 | 2 (0|
| 3 | INDEX FULL SCAN | DEPT_ID_PK | 27 | | 1 (0|
|* 4 | SORT JOIN | | 107 | 1177 | 4 (25|
| 5 | TABLE ACCESS FULL | EMPLOYEES | 107 | 1177 | 3 (0|
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")
filter("E"."DEPARTMENT_ID"="D"."DEPARTMENT_ID")
24 rows selected.
SELECT PLAN_TABLE_OUTPUT FROM
TABLE(DBMS_XPLAN.DISPLAY_CURSOR('cfz0cdukrfdnu'));

129. 132
V$SQL_PLAN_STATISTICS View
• V$SQL_PLAN_STATISTICS provides actual execution statistics.
• V$SQL_PLAN_STATISTICS_ALL enables
side-by-side comparisons of the optimizer estimates.

130. 133
Querying the AWR
SELECT PLAN_TABLE_OUTPUT FROM TABLE
(DBMS_XPLAN.DISPLAY_AWR('454rug2yva18w'));
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------
SQL_ID 454rug2yva18w
--------------------
select /* example */ * from hr.employees natural join hr.departments
Plan hash value: 2052257371
----------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
----------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 6 (100)| |
| 1 | HASH JOIN | | 11 | 968 | 6 (17)| 00:00:01 |
| 2 | TABLE ACCESS FULL| DEPARTMENTS | 11 | 220 | 2 (0)| 00:00:01 |
| 3 | TABLE ACCESS FULL| EMPLOYEES | 107 | 7276 | 3 (0)| 00:00:01 |
----------------------------------------------------------------------------------

131. 134
How to Use the SQL Trace Facility
1. Set the initialization parameters.
2. Enable tracing.
3. Run the application.
4. Disable Trace.
5. Close the session.
6. Format the trace file.
7. Interpret the output. Report
file
Database
Trace
file
TKPROF
SQL Trace

132. 135
Initialization Parameters
STATISTICS_LEVEL = {BASIC|TYPICAL|ALL}
TIMED_STATISTICS = {false|true}
MAX_DUMP_FILE_SIZE = {n|unlimited}
DIAGNOSTIC_DEST={directory_path|$ORACLE_BASE/diag}

133. 136
SQL> EXEC dbms_monitor.database_trace_enable();
Enabling SQL Trace
• For your current session:
• For any session:
• For instance-wide tracing:
SQL> EXEC dbms_monitor.session_trace_enable;
SQL> EXECUTE dbms_session.set_sql_trace(true);
SQL> EXECUTE dbms_system.set_sql_trace_in_session
2 (session_id, serial_id, true);

134. 137
SQL> EXEC dbms_monitor.database_trace_disable();
Disabling SQL Trace
• For your current session:
• For any session:
• For instance-wide tracing:
SQL> EXEC dbms_monitor.session_trace_disable;
SQL> EXECUTE dbms_session.set_sql_trace(false);
SQL> EXECUTE dbms_system.set_sql_trace_in_session
2 (session_id, serial_id, false);

135. 138
Formatting Your Trace Files
• TKPROF command examples:
OS> tkprof
OS> tkprof ora_902.trc run1.txt
OS> tkprof ora_902.trc run2.txt sys=no
sort=execpu print=3
OS> tkprof tracefile outputfile [options]

136. 139
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
(This step modifies the data for INSERT, UPDATE, and
DELETE statements.)
FETCH Retrieves the rows returned by a query
(Fetches are performed only for SELECT statements.)

137. 140
Output of the TKPROF Command
• There are seven categories of trace statistics:
Count Number of times the 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
Current Number of logical buffers read in current mode
Rows Number of rows processed by the fetch or execute

138. 141
Generate an Optimizer Trace
• Set an event—10053 optimizer trace.
• Execute the statement of interest.
• Find and view the trace file.
SQL> ALTER SESSION SET EVENTS
2> '10053 trace name context forever, level 1';
SQL> select *
2> from hr.employees natural join hr.departments
3> where department_id = 10;

139. 142
How to Handle SQL Performance
• Managing optimizer statistics
• Optimizer statistics change over time
• Changes in statistics influence the optimizer
• To maintain optimum execution plans:
• Set statistic preferences
• Defer statistics publishing
• Use automatic tools to locate and manage queries:
• Use Real-time SQL Monitoring - DBMS_SQLTUNE (before 12c)
• Use Real-Time Database Operation Monitoring - DBMS_SQL_MONITOR (after
12c)

140. Real-time Database Operation
Monitoring

141. 144
Automatic SQL Tuning: Overview
• Before Oracle 12c, we had the Real-time SQL Monitor and Automatic
SQL Tuning
• Automatic SQL Tuning automates the entire SQL tuning process and
replaces manual SQL tuning
• Optimizer modes:
• Normal mode
• Tuning mode or Automatic Tuning Optimizer (ATO)
• SQL Tuning Advisor is used to access tuning mode
• You should use tuning mode only for high-load SQL statements

142. 145
SQL Statement Profiling
• Statement statistics are key inputs to the optimizer.
• ATO verifies statement statistics such as:
• Predicate selectivity
• Optimizer settings (FIRST_ROWS versus ALL_ROWS)
• Automatic Tuning Optimizer (ATO) uses:
• Dynamic sampling
• Partial execution of the statement
• Past execution history statistics of the statement
• ATO builds a profile if statistics were generated:
exec :profile_name := -
dbms_sqltune.accept_sql_profile( -
task_name =>'my_sql_tuning_task');

143. 146
Real-time Database Operation Monitor
• Database Operation
• One or more database tasks, defined by you
• Contains one or more SQL or PL/SQL statements
• In one or more sessions
• Database Operation Monitor (DBOM)
• Monitor single SQL or PL/SQL operations (pre 12c)
• Monitor composite database operations (12c)

144. 147
Real-time Database Operation Monitor Intro
• Part of Diagnostics & Tuning Packs
• CONTROL_MANAGEMENT_PACK_ACCESS = DIAGNOSTICS+TUNING
• Feature includes views, hints, functions and reports
• Most value in Active XML SQL Monitor Report (requires flash plugin)
• New 12c Features:
• Composite DB Operations
• In-Memory and Adaptive Execution Plan Monitoring
• Historical Reports Stored in AWR
• Run-away Query Logging

145. 148
Database Operation Monitoring Architecture

146. 149
Basics
• Detailed monitoring of SQL Statements while executing
• No Performance Penalty
• Information efficiently captured by background processes
• Similar to AWR and ASH
• Statements Monitored by Default if:
• Consuming >5 seconds of DB time
• Executed in parallel
• Use /*+ MONITOR */ hint to force

147. 150
Diagnose Composite Operations
• Enable composite operation monitoring:
• Set operation name
• Get operation ID
• Start and end the monitoring using DBMS_SQL_MONITORING

148. 151
Example
VARIABLE l_dbop_eid NUMBER;
BEGIN
:l_dbop_eid := DBMS_SQL_MONITOR.begin_operation (
dbop_name => 'db_my_operation',
dbop_eid => :l_dbop_eid,
forced_tracking => DBMS_SQL_MONITOR.force_tracking -- ‘Y’
);
END;
/
[commands]
BEGIN
DBMS_SQL_MONITOR.end_operation (
dbop_name => 'db_my_operation',
dbop_eid => :l_dbop_eid
);
END;
/

149. 152
What About Applications?
Identify Using Tagging for Java and OCI Applications
• OCI Calls
• OCIAttrSet
• OCIAppCtxSet
• Java
• setClientInfo
• OS Environment Variable
• ORA_DBOP
• End Operation by setting Tag to NULL

150. 153
Composite Operations

151. 154
Accessing The SQL Monitor
• Associated V$ views
• V$SQL_MONITOR, V$SQL_PLAN_MONITOR and V$SQL_MONITOR_SESSTAT
• Join with other views: V$SQL, V$ACTIVE_SESSION_HISTORY and
V$SESSION_LONGOPS
• Using SQL Monitor Reports
• DBMS_SQL_MONITOR.REPORT_SQL_MONITOR
• Text, HTML, Active (requires flash plugin), XML
• Using Enterprise Manager 12c or EM Database Express
• From Performance Menu/Performance Hub

152. 155
Accessing SQL Monitor Using
DBMS_SQL_MONITOR
• Generate using
• DBMS_SQL_MONITOR.REPORT_SQL_MONITOR function
• DBMS_SQLTUNE prior to 12c
• Might require elevated permission – probably want to run it from a
user with DBA role
SET LONG 1000000 LONGCHUNKSIZE 1000000 LINESIZE 1000 PAGESIZE 0 TRIM ON
SET TRIMSPOOL ON ECHO OFF FEEDBACK OFF HEADING OFF SHOW OFF VERIFY OFF
SPOOL my_sql_monitor_active_report.html
SELECT DBMS_SQL_MONITOR.report_sql_monitor(
sql_id => '4djw12tvp6836',
type => 'HTML',
report_level => 'ALL') AS report
FROM dual;
SPOOL OFF

153. 156
What’s in a SQL Monitor Report
• Execution Plan
• Plan Statistics
• Estimated vs. Actual Row Counts
• Bind Variable Values
• DB Time and Wait Statistics
• Execution’s Duration vs. DB Time
• CPU and Wait Events, and time spent,
for each execution step
• CPU, IO, Memory and Wait Activity:
mapped over statement run time
• IO Statistics
• Memory Statistics
• Temp Activity Statistics
• Parallel Activity Detail
• Exadata Cell Offload (Smart
Scan) Efficiency

154. 157
Runaway Query Logging
• DB Resource Manager can now log to SQL Monitor based on certain thresholds:
• Estimated Execution Time
• Elapsed Time (new in 12c)
• CPU time
• IO requests or IO Bytes
• Logical IOs (new in 12c)
• New columns in V$SQL_MONITOR
• RM_CONSUMER_GROUP
• RM_LAST_ACTION
• RM_LAST_ACTION_REASON
• RM_LAST_ACTION_TIME
• Can also switch consumer group, Abort SQL Call or Kill Session

155. 158
Interpreting SQL Monitor Report
1. Time & Wait Statistics
• Find Where SQL is Spending Time
• Duration vs Database Time
• CPU vs Wait
• Database Time Breakdown
• Total Active DB Processing Time Consumed by Execution
• If Parallel = QC + PX Slaves
2. Activity % in Plan Statistics Detail
• If DB Time Mostly on CPU >> Focus on CPU Activity %
• If DB Time Mostly on Waits >> Focus on Wait Activity %
• Line(s) with the Most Activity % is Where to Focus
3. Other Plan Statistics & Metrics Help with Diagnosis

156. 159
Where to Focus: Example

157. 160
Where to Focus: Example (cont.)

158. 161
When To Use DBOM and SQL Monitoring
• Long Execution Plans
• Reading, Diagnosing and Quickly Identifying Problem Areas
• Optimal Use of Indexes
• Find Bind Variable Values
• Partially Parallelized SQL
• Verify Parallel DML/DDL
• Detect Skew Between Parallel Processes
• Identify latency, network or application, outside of database
• Find Cause of High Temp Usage
• Verify Exadata Smart Scans and Cell Offload Efficiency
• Identify Long-running SQL in Batch or Multi-statement Processes

159. 162
Things You Should Know
• Plans are limited with 300 lines. Can be modified by using a
parameter: _sqlmon_max_planlines = 300
• How to Monitor SQL Statements with Large Plans Using Real-Time SQL
Monitoring? (Doc ID 1613163.1)
• Bind Variables are recorded and might be visible in the reports
• Can help validate if parallel DML was triggered
• Can help locate partially parallelized commands

160. Tuning The Memory
SGA, PGA, Temporary and Automatic Memory Management

161. 164
What Memory Should We Tune?
• SGA
• Shared Pool
• Buffer Cache
• Others (not covered here)
• PGA
• ASMM: Automatic Shared Memory Management
• AMM: Automatic Memory Management

162. 165
Shared Pool Architecture
• Major components of the shared pool are:
• Library cache
• Data dictionary cache
• Results cache

163. 166
Common SGA Related Issues
• Shared Pool Issues
• Hard Parsing
• Soft Parsing
• Latch and Mutex issues
• Buffer Cache Issues
• Latch: cache buffer chains
• Latch: cache buffer LRU chains
• Buffer Busy Waits
• Read Waits
• Free Buffer Waits
• Cache Hit Ratio

164. 167
V$SGASTAT V$SGAINFO
V$LIBRARYCACHE
V$LIBRARY_CACHE_MEMORY
V$SHARED_POOL_RESERVED
V$SQLSTATS
V$SQL
V$SQLAREA
V$SQLTEXT
V$DB_OBJECT_CACHE
Diagnostic Tools for Tuning the Shared Pool
Parameters affecting the components:
SHARED_POOL_SIZE, OPEN_CURSORS
SESSION_CACHED_CURSORS, CURSOR_SPACE_FOR_TIME
CURSOR_SHARING, SHARED_POOL_RESERVED_SIZE
Statpack
report
AWR report
Data dictionary
cache
Shared pool
Library cache
Shared SQL
and PL/SQL
Views

165. 168
Diagnosing Memory issues using
AWR/Statspack Indicators
• AWR and Statspack reports include indicators:
• Load Profile
• Instance Efficiencies
• Top Wait Events
• Time Model

166. 169
Load Profile

167. 170
Instance Efficiencies

168. 171
Top Waits

169. 172
Time Model

170. 173
Library Cache Activity

171. 174
Reminder: Parse Phase in SQL
• Parsing is a part of the regular work of the database
• Always:
• Checks syntax
• Checks semantics and privileges
• Soft parse:
• Searches for the statement in the shared pool
• Hard parse:
• Merges view definitions and subqueries
• Determines execution plan
• But excessive parsing might also indicate a problem

172. 175
Avoid Hard Parses
• In an OLTP system, reduce misses by keeping hard-parsing to a
minimum:
• Make sure that users can share statements by using bind variables
• Prevent frequently used statements from being aged-out by allocating
enough space
• Avoid invalidations that induce reparsing

173. 176
SQL Statement Processing Phases: Bind
• Bind Variables are like parameters to a query
• Bind phase:
• Checks the statement for bind variables
• Assigns or reassigns a value to the bind variable
• Bind variables impact performance when:
• Parsing is reduced by using a shared cursor
• A different execution plan might benefit performance with different bind
values

174. 177
Sharing Cursors
• Values for CURSOR_SHARING are:
• EXACT (default)
• SQL statements must be identical to share cursors.
• SIMILAR
• SQL statements that are similar share cursors, provided that their respective
execution plans are the same.
• FORCE
• SQL statements that are similar share cursors regardless of the impact on the
execution plan. Bind peeking is done on the first parse, and possibly later due to adaptive cursor
sharing.
• Similar statements are identical, except for the values of some
literals.

175. 178
Adaptive Cursor Sharing Views
• The following views provide information about Adaptive Cursor
Sharing usage:
V$SQL Two columns show whether a cursor is bind-
sensitive or bind-aware.
V$SQL_CS_HISTOGRAM Shows the distribution of the execution count
across the execution history histogram.
V$SQL_CS_SELECTIVITY Shows the selectivity cubes stored for every
predicate containing a bind variable and whose
selectivity is used in the cursor-sharing checks.
V$SQL_CS_STATISTICS Shows execution statistics of a cursor using
different bind sets.

176. 179
Avoiding Soft Parses
• Reducing soft parses reduces library cache latch contention.
• Keep soft parsing to a minimum by:
• Setting SESSION_CACHED_CURSORS
• Setting HOLD_CURSOR in the application precompiler
• Setting CURSOR_SPACE_FOR_TIME

177. 180
SQL Query Result Cache: Overview
• Cache the result of a query or query block for future reuse.
• Cache is used across statements and sessions unless it is stale.
• Benefits:
• Scalability
• Reduction of memory usage
• Good candidate statements:
• Access many rows
• Return few rows
SELECT
…
SQL
Query Result
Cache
SELECT …
Session 1 Session 2
1
2 3

178. 181
Managing the SQL Query Result Cache
• RESULT_CACHE_MODE values:
• MANUAL: Use the result_cache hint to specify results to be stored in the
cache.
• FORCE: All results are stored in the cache.
• RESULT_CACHE_MAX_SIZE
• Sets the memory allocated to the result cache
• Disabled if value is 0.
• Limited to 75% of shared pool
• Default is derived from other memory settings
• 0.25% of memory_target or
• 0.5% of sga_target or
• 1% of shared_pool_size

179. 182
Managing the SQL Query Result Cache
• RESULT_CACHE_MAX_RESULT
• Sets maximum cache memory for a single result
• Defaults to 5% of RESULT_CACHE_MAX_SIZE
• RESULT_CACHE_REMOTE_EXPIRATION
• Sets the expiry time for cached results depending on remote database
objects
• Defaults to 0

180. 183
Using the RESULT_CACHE Hint
EXPLAIN PLAN FOR
SELECT /*+ RESULT_CACHE */ department_id, AVG(salary)
FROM employees
GROUP BY department_id;
SELECT /*+ NO_RESULT_CACHE */ department_id, AVG(salary)
FROM employees
GROUP BY department_id;
--------------------------------------------------------------
| Id | Operation | Name |Rows
--------------------------------------------------------------
| 0 | SELECT STATEMENT | | 11
| 1 | RESULT CACHE | 8fpza04gtwsfr6n595au15yj4y
|
| 2 | HASH GROUP BY | | 11
| 3 | TABLE ACCESS FULL| EMPLOYEES | 107
--------------------------------------------------------------

181. 184
Using the DBMS_RESULT_CACHE Package
• Use the DBMS_RESULT_CACHE package to:
• Manage memory allocation for the query result cache
• View the status of the cache:
• Retrieve statistics on the cache memory usage:
• Remove all existing results and clear cache memory:
• Invalidate cached results depending on specified object:
EXECUTE DBMS_RESULT_CACHE.MEMORY_REPORT;
EXECUTE DBMS_RESULT_CACHE.FLUSH;
SELECT DBMS_RESULT_CACHE.STATUS FROM DUAL;
EXEC DBMS_RESULT_CACHE.INVALIDATE('JFV','MYTAB');

182. 185
Viewing SQL Result Cache Dictionary Information
• The following views provide information about the query result
cache:
(G)V$RESULT_CACHE_STATISTICS Lists the various cache settings and
memory usage statistics
(G)V$RESULT_CACHE_MEMORY Lists all the memory blocks and the
corresponding statistics
(G)V$RESULT_CACHE_OBJECTS Lists all the objects (cached results and
dependencies) along with their attributes
(G)V$RESULT_CACHE_DEPENDENCY Lists the dependency details between
the cached results and dependencies

183. 186
SQL Query Result Cache: Considerations
• Result cache is disabled for queries containing:
• Temporary or dictionary tables
• Nondeterministic PL/SQL functions
• Sequence CURRVAL and NEXTVAL
• SQL functions current_date, sysdate, sys_guid, and so on
• DML/DDL on remote database does not expire cached results.
• Flashback queries can be cached.
• Result cache does not automatically release memory.
• It grows until maximum size is reached.
• DBMS_RESULT_CACHE.FLUSH purges memory.

184. 187
Latch and Mutex
• A latch is a memory object that allows:
• Sharing of a resource without corruption
• Exclusive access for update and allocation
• Shared access for reads
• A mutual exclusion object allows:
• Sharing of a resource without corruption
• Shared access for reads
• Exclusive access for update
• Each object to have its own mutex

185. 188
Latch and Mutex: Views and Statistics
• Latch views:
• V$LATCH
• V$LATCH_MISSES
• V$LATCH_PARENT
• V$LATCH_CHILDREN
• V$LATCHHOLDER
• V$LATCHNAME
• Latch wait events:
• latch: latchname
• Mutex views:
• V$MUTEX_SLEEP
• V$MUTEX_SLEEP_HISTORY
• Mutex wait events:
• cursor:mutex X
• cursor:mutex S
• cursor:pin X
• cursor:pin S
• cursor:pin S wait on X

186. Buffer Cache

187. 190
Cache Buffer Chains Latch Contention
• Contention for this latch indicates:
• Multiple processes attempting to access the same “hot” block
• Excessive block replacement
• Hot blocks are often caused by application design choices or
inefficient SQL that rereads blocks

188. 191
Finding Hot Segments
• Characteristics of cache buffer chains latch contention:
• Many accesses to one or more block under the same latch
• Worse with larger block sizes
• To find hot segments:
SQL> SELECT * FROM ( SELECT owner, object_name,
2 object_type, statistic_name, sum(value)
3 FROM V$SEGMENT_STATISTICS
4 GROUP BY owner, object_name, object_type,
5 statistic_name
6 ORDER BY SUM(value) DESC)
7 WHERE ROWNUM <= 10;

189. 192
Buffer Busy Waits
• Application-level contention for buffers in the buffer cache
• Identify buffer busy waits contention:
SELECT object_name, value
FROM V$SEGMENT_STATISTICS
WHERE statistic_name = 'buffer busy waits' AND
value > 20000;
SELECT class, count
FROM V$WAITSTAT
WHERE count>0
ORDER BY count DESC;

190. 193
Calculating the Buffer Cache Hit Ratio
SELECT name, value
FROM v$sysstat
WHERE name IN ('db block gets from cache',
'consistent gets from cache',
'physical reads cache');
PHYSICAL READS = 'physical reads cache')
LOGICAL READS = ('consistent gets from cache' +
'db block gets from cache')
HIT RATIO = 1 - PHYSICAL READS/LOGICAL READS

191. 194
Buffer Cache Hit Ratio Is Not Everything
• A badly tuned database can still have a hit ratio of 99% or better
• Hit ratio is only one part in determining tuning performance
• Hit ratio does not determine whether a database is optimally tuned
• Use the wait interface to examine what is causing a bottleneck:
• V$SESSION_WAIT
• V$SESSION_EVENT
• V$SYSTEM_EVENT
• Tune SQL statements

192. 195
Read Waits
• List of wait events performing disk reads into the buffer cache:
• db file sequential read
• db file parallel read
• db file scattered read
• If wait time for reads is high:
• Tune the SQL statement that issues most disk reads by sorting V$SQL by
DISK_READS and BUFFER_GETS.
• Increase the buffer cache if needed.
• Reduce writes due to checkpointing.
• Add more disk capacity.

193. 196
Free Buffer Waits
K
B
J
A
C
D
LRU
list
Server
Server
Server Write
Buffer
state
dirty
free
DBWn

194. 197
Solutions
• The buffer cache solutions are applied depending on the symptoms:
• Properly size the buffer cache (if not automatic)
• Cache objects
• Use the keep and recycle pools
• Increase the writing speed of DBWn
• Use the private I/O pool

195. 198
Caching Tables
• Enable caching during full table scans by:
• Creating the table with the CACHE clause
• Altering the table with the CACHE clause
• Using the CACHE hint in a query
• Caching tables put blocks at the MRU end of the LRU list.
• Guideline: Do not overcrowd the buffer cache.
• Use a keep pool.

196. 199
Multiple Buffer Pools
• Three buffer pools:
• Default: SYS and non-flagged table or indexes
• Keep: Hot objects
• Recycle: Infrequent access
• Useful for small, simple schemas with well-known access paths
Default Keep Recycle
Auto-tuned

197. 200
Multiple Block Sizes
• Allow buffer caches for nonstandard block sizes
• Parameters: DB_nK_CACHE_SIZE {n = 2, 4, 8, 16, 32}
• BLOCKSIZE attribute of CREATE TABLESPACE storage clause
• Intended for transportable tablespaces
Default
Keep
Recycle
16 KB cache
Set#1
Set#2
Set#3
Set#4
Set#5
Set#6
Set#7
Set#8

198. 201
Automatically Tuned Multiblock Reads
• DB_FILE_MULTIBLOCK_READ_COUNT is automatically tuned.
The automatic setting:
• Is enabled if the parameter is not set or is set to zero
• Simplifies the determination of the optimal I/O size
• Optimal I/O size is:
• Platform dependent
• The size of the prefetch
• Rules for the automatic parameter behavior are:
• Prefetch is limited to 64 KB, if prefetch blocks exceed 10% of the cache.
• Value of eight blocks is used for calculating the cost of full table scans.

199. PGA

200. 203
PGA and SQL Memory Usage
• Memory-intensive SQL operators:
• Sort-based (sort, group-by, rollup, window, and so on)
• Hash-join
• Bitmap operators (merge and inversion)
• Concept of work area: Memory allocated by a memory-intensive
operator to process its input data
• Performance impact of memory:
• Optimal: Input data fits into the work area (cache).
• One-pass: Perform one extra pass over input data.
• Multi-pass: Perform several extra passes over input data.

201. 204
Configuring Automatic PGA Memory
• PGA_AGGREGATE_TARGET:
• Specifies the target aggregate amount of PGA memory available to the
instance
• Can be dynamically modified at the instance level
• Examples: 100,000 KB; 2,500 MB; 50 GB
• Default value: 10 MB or 20% of the size of the SGA, whichever is greater
• WORKAREA_SIZE_POLICY:
• Optional
• Can be dynamically modified at the instance or session level
• Allows you to fall back to static SQL memory management for a particular
session

202. 205
Monitoring SQL Memory Usage
V$SQL_WORKAREA_ACTIVE
V$SQL_WORKAREA
V$PGASTAT
V$SQL_PLANV$SQL
V$SQL_WORKAREA_HISTOGRAM
V$PROCESS_MEMORY
V$SYSSTAT
V$TEMPSEG_USAGE
WORK AREA
TEMP SEGMENT
OTHER

203. Monitoring SQL Memory Usage: Examples
SELECT sql_text,
sum(onepass_executions) onepass_cnt,
sum(multipasses_executions) mpass_cnt
FROM V$SQL s, V$SQL_WORKAREA wa
WHERE s.address = wa.address
GROUP BY sql_text
HAVING sum(onepass_executions+multipasses_executions)>0;
SELECT TO_NUMBER(DECODE(sid, 65535, NULL, sid)) sid,
operation_type OPERATION,
TRUNC(expected_size/1024) ESIZE,
TRUNC(actual_mem_used/1024) MEM,
TRUNC(max_mem_used/1024) MAXMEM,
number_passes PASS,
TRUNC(tempseg_size/1024) TSIZE
FROM V$SQL_WORKAREA_ACTIVE
ORDER BY 1,2;
1
2

204. 207
Tuning SQL Memory Usage
• Determine the best PGA_AGGREGATE_TARGET value by using:
• V$PGA_TARGET_ADVICE
• V$PGA_TARGET_ADVICE_HISTOGRAM
• Monitor AWR reports/Statspack reports for:
• direct path read temp
• direct path write temp

205. 208
Temporary Tablespace Management: Overview
• Temporary data generated by a database includes:
• Bitmap merges
• Hash-join
• Bitmap index creation
• Sort
• Temporary LOBs
• Global temporary tables
• Data persists for the duration of a transaction or session.
• High concurrency of the space management operation is critical.
• Media and instance recovery is not required.

206. 209
Temporary Tablespace: Best Practice
• Using locally managed temporary tablespaces:
• Allows high-concurrency space management
• At steady state, all space metadata is cached in SGA.
• Operations are serialized by the SGA latch.
• Allows faster writes to temp files. Redo generated on temporary blocks is
not written to disk.
• Makes READ ONLY databases possible

207. 210
Configuring Temporary Tablespace
• Locally managed temporary tablespaces are uniform-extent
tablespaces.
• 1 MB to 10 MB extent size:
• For DSS, OLAP applications involving huge work areas
• Large temporary LOBs are predominant.
• 64 KB or multiple less than 1 MB:
• Small global temporary tables are predominant.
• OLTP
• Use V$TEMPSEG_USAGE to monitor space usage and workload
distribution.

208. 211
Temporary Tablespace Group: Overview
• Groups multiple temporary tablespaces
• Characteristics:
• At least one temporary tablespace
• Same namespace as tablespaces
• Created implicitly on first assignment
• No explicit deletion
Default tablespace
EXAMPLE …
Default temporary
tablespace group TEMP
Tablespace
TEMP1
Tablespace
TEMPn

209. 212
Temporary Tablespace Group: Benefits
• Enables a user to use multiple temporary tablespaces:
• Same user in multiple sessions
• One particular parallel operation
Temporary tablespace group TEMP
Tablespace
TEMP1
Tablespace
TEMP2
Tablespace
TEMP3
Serial
ParallelHR
HR

210. 213
Monitoring Temporary Tablespace
• Use V$TEMPSEG_USAGE to monitor space usage and workload
distribution:
• Use V$SORT_SEGMENT to determine space usage percentage:
SELECT session_num, username, segtype, blocks, tablespace
FROM V$TEMPSEG_USAGE;
SELECT (s.tot_used_blocks/f.total_blocks)*100 as pctused
FROM (SELECT SUM(used_blocks) tot_used_blocks
FROM V$SORT_SEGMENT
WHERE tablespace_name='TEMP') s,
(SELECT SUM(blocks) total_blocks
FROM DBA_TEMP_FILES
WHERE tablespace_name='TEMP') f;

211. 214
Tablespace Option for Creating Temporary Table
• Specify which temporary tablespace to use for your global temporary
tables.
• Decide a proper temporary extent size.
CREATE TEMPORARY TABLESPACE temp
TEMPFILE 'tbs_temp.dbf' SIZE 600m REUSE AUTOEXTEND ON MAXSIZE
UNLIMITED
EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1m;
CREATE GLOBAL TEMPORARY TABLE temp_table (c varchar2(10))
ON COMMIT DELETE ROWS TABLESPACE temp;

212. Automatic Memory Management
ASMM and AMM

213. 216
Automatic Shared Memory Management:
Overview
• Uses dynamic SGA and memory advisors to automatically adapt to
workload changes
• Maximizes memory utilization
• Helps eliminate
out-of-memory
errors
• Avoids relearning
when using SPFILE
Online users Batch jobs
Buffer cache
Large pool
Shared pool
Java pool
Buffer cache
Large pool
Shared pool
Java pool
Online users Batch jobs
Streams pool Streams pool

214. 217
SGA Sizing Parameters: Overview
• With ASMM, five important SGA components can be automatically
sized.
• Nondefault buffer pools are not auto-tuned.
• Log buffer is not a dynamic component but has a good default.
DB_KEEP_CACHE_SIZE
DB_RECYCLE_CACHE_SIZE
DB_nK_CACHE_SIZE
RESULT_CACHE_MAX_SIZE
SGA_TARGET
LOG_BUFFERSHARED_POOL_SIZE
DB_CACHE_SIZE
LARGE_POOL_SIZE
JAVA_POOL_SIZE
STREAMS_POOL_SIZE
Auto-tuned
parameters
Manual
dynamic parameters
Manual
static parameters
SGA_MAX_SIZE

215. 218
Dynamic SGA Transfer Modes
• ASMM IMMEDIATE transfer mode:
• Out-of-memory (ORA-04031) errors
• Partial granules can be used.
• ASMM DEFERRED transfer mode:
• Transparently executed in the background
• Partial granules can be used.
• MANUAL transfer mode:
• Used with ALTER SYSTEM commands
• Resize must use full granules.

216. 219
Behavior of Auto-Tuned SGA Parameters
• When SGA_TARGET is not set or is set to zero:
• Auto-tuned parameters are explicitly set
• Note: SHARED_POOL_SIZE includes internal startup overhead. Value
may need to be increased from previous releases.
• When SGA_TARGET is set to a nonzero value and auto-tuned
parameters are:
• Not set, the auto-tuned parameters default to zero
• Set, a nonzero value is a lower bound
• When automatically adjusted. Current values in megabytes are
shown by:
SELECT component, current_size/1024/1024
FROM V$SGA_DYNAMIC_COMPONENTS;

217. 220
Automatic Memory Management: Overview
AMM Disabled AMM Enabled
Untunable
PGA
Free
Buffer cache
Large pool
Shared pool
Java pool
Streams pool
SQL areas
Other SGA
SGA target
PGA target
OLTP BATCH
Buffer cache
Large pool
Shared pool
Java pool
Streams pool
SQL areas
Other SGA
Untunable
PGA
Free
BATCH
Buffer cache
Large pool
Shared pool
Java pool
Streams pool
Other SGA
SQL areas
Untunable
PGA
Memory target

218. 221
Automatic Memory Management: Overview
AMM
Memory target
Memory
max target
250 MB
350 MB
ALTER SYSTEM SET
MEMORY_TARGET=300M;
AMM
Memory target
Memory
max target
300 MB
350 MB

219. 222
Oracle Database Memory Parameters
DB_KEEP_CACHE_SIZE
DB_RECYCLE_CACHE_SIZE
DB_nK_CACHE_SIZE
LOG_BUFFER
RESULT_CACHE_SIZE
SHARED_POOL_SIZE
DB_CACHE_SIZE
LARGE_POOL_SIZE
JAVA_POOL_SIZE
STREAMS_POOL_SIZE
SGA_TARGET
SGA_MAX_SIZE
MEMORY_MAX_TARGET
MEMORY_TARGET
Others
PGA_AGGREGATE_TARGET

220. 223
Monitoring Automatic Memory Management
• To monitor the decisions made by Automatic Memory Management,
use the following views:
• V$MEMORY_DYNAMIC_COMPONENTS (displays the current status of all
memory components)
• V$MEMORY_RESIZE_OPS (displays a circular history buffer of the last 800
completed memory resize requests)
• V$MEMORY_CURRENT_RESIZE_OPS (displays current memory resize
operations)
• All SGA and PGA equivalents are still in place for backward
compatibility.

221. Automatic DOP and Parallel
Statement Queuing

222. 225
Automated Degree of Parallelism Settings
• Oracle determine the degree of parallelism on each table/query
based on a set of criteria and some initialization parameter settings
• To enable use the parallel_degree_policy parameter (by
default this stuff is off - parameter is set to manual)
• For Auto DOP, setting this to LIMITED is sufficient
• For more functionality (in-memory parallel processing and parallel
statement queuing) parallel_degree_policy should be set to AUTO

223. 226
Automated Degree of Parallelism Settings
• The parameter for the threshold of parallel query evaluation is
parallel_min_time_threshold.
The default of this parameter is 10 seconds (set lower to allow more
parallel queries evaluations)
• The maximum DOP that can be used is set by
Parallel_degree_limit.
By default this is set to the value of “CPU” multiplied with the value
of the parameter parallel_threads_per_cpu

224. 227
Automated Degree of Parallelism
SQL
statement
Statement is hard parsed
And optimizer determines the
execution plan
Statement executes
serially
Statement executes in
parallel
Optimizer determines
ideal DOP
If estimated time greater
than threshold
Actual DOP = MIN(default DOP, ideal DOP)
If estimated time less
than threshold
PARALLEL_MIN_TIME_THRESHOLD

225. 228
Parallel Statement Queuing
• Because of the expected behavior of more statements running in
parallel it becomes more important to manage the usage of the
parallel resources.
• Queries that does not have enough resources can put on “hold” until
enough resources are available
• Oracle maintains FIFO queue for the waiting statements
• Use NO_STMT_QUEUING hint to avoid the queue

226. 229
Parallel Statement Queuing Settings
• parallel_degree_policy must be set to AUTO
• The parameter for enabling the parallel statement query evaluation is
parallel_server_target
The default value is 4 times the default DOP.
• To avoid an arbitrary number of parallel processes to be running on a
system, which may overload that system, the parameter
parallel_max_servers provides a hard upper boundary

227. 230
Parallel Statement Queuing
When the required number of
parallel servers become
available the first stmt on the
queue is dequeued and
executed
128
163264
SQL
statements
Statement is parsed
and Oracle automatically
determines DOP
If enough parallel servers
available execute
immediately
If not enough parallel servers
available queue
128163264
8
FIFO Queue

228. 231
Parallel Statement Queuing Monitoring
• Monitoring can be done using Enterprise Manager SQL Monitor
• Monitoring can also be done by using:
SELECT s.sql_id, s.sql_text
FROM v$SQL_MONITOR m, v$SQL s
WHERE m.status='QUEUED'
AND m.sql_id = s.sql_id;

229. 232
Table Compression: Overview
• Oracle Database 11g extends compression for OLTP data.
• Support for conventional DML operations
(INSERT, UPDATE, DELETE)
• New algorithm significantly reduces write overhead.
• Batched compression ensures no impact for most OLTP transactions.
• No impact on reads
• Reads may actually see improved performance due to fewer I/Os and
enhanced memory efficiency.

230. 233
Table Compression Concepts
Header
Uncompressed
data
Compressed
data
Free
space
Inserts are
uncompressed.
PCTFREE reached
triggers compression.
Inserts are again
uncompressed.
PCTFREE reached
triggers compression.
Data block
PCTFREE
limit

231. 234
Using Table Compression
• Requires database compatibility level at 11.1 or greater
• Use the COMPRESS keyword:
• COMPRESS [FOR {ALL | DIRECT_LOAD} OPERATIONS]
• FOR DIRECT_LOAD is the default: Refers to bulk load operations from prior
releases
• FOR ALL OPERATIONS: OLTP + direct loads
• Enable compression for new tables:
• Enable compression on existing table:
• Does not trigger compression on existing rows
CREATE TABLE t1 COMPRESS FOR ALL OPERATIONS;
ALTER TABLE t2 COMPRESS FOR ALL OPERATIONS;

232. Did You Hear About
Oracle 18c?

233. 236
• Oracle is changing the way they number products
• Products will be release more often
• Version names will be based on last two digits of the year and a
subversion
• There is no more Release 1-Release 2 for major versions, we can’t tell
when we jumped to the next major version and when for the next minor
• Examples:
• 12.2.0.1 will be followed by 18.1 (and not 12.2.0.2)
• SQL Developer 4.2.1 was followed by 17.3
• Read more at the updated MOS Note 742060.1 – Release Schedule of
Current Database Releases
Wait! 18c?! What happened to 13c?

234. 237
Summary
• We talked about tuning and what to tune
• Statspack, AWR, ASH and ADDM are great places to start instance
tuning
• We discussed how to find long running queries and PL/SQL blocks
and how to generate real time database monitoring reports
• We dived into Memory management and what to take care of
• We talked a little about parallelism, compression and other useful
abilities

235. 238
What Did We Not Talk About?
• We didn’t cover everything from the tuning perspective – we only
scratched the surface
• SQL tuning and optimizer manipulation: adaptive plans, statistics, etc.
• Tuning PL/SQL code
• Various tools: SQL Tuning Advisor, SQL Access Advisor, Real
Application Testing and more
• Database Partitions

236. Q&A
Any Questions? Now will be the time!

237. Zohar Elkayam
twitter: @realmgic
Zohar@Brillix.co.il
www.ilDBA.co.il
www.realdbamagic.com