Oracle Database Performance Tuning Advanced

Features and Best Practices for DBAs

Zohar Elkayam
CTO, Brillix
[email protected]
www.realdbamagic.com
Twitter: @realmgic
 Who am I?
• 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

2
 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

3
Some of Our Customers

4
 ilOUG – Israel Oracle User Group
• 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

5
 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

6
 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

7
 ‫‪Our REAL Agenda‬‬

‫הפסקה‬ ‫‪10:30-10:45‬‬
‫ארוחת צהריים לכל משתתפי הכנס בגן המלון‬ ‫‪12:30-13:30‬‬
‫הפסקה מתוקה במתחם קבלת הפנים‬ ‫‪15:00-15:15‬‬
‫הולכים הביתה‬ ‫‪16:30‬‬

‫• בסיום יום הסמינר יחולק טופס משוב ונשמח לקבל את חוות דעתכם‪.‬‬
‫• דעתכם חשובה‪ :‬היא זו המאפשרת לנו לעשות את הסמינרים טובים יותר!‬

‫‪8‬‬
What Is Tuning Anyway?
 Who Tunes?
• The people who are involved with tuning:
• Database administrators
• Application architects
• Application designers
• Application developers
• System administrators
• Storage administrators

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

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

Proactive Reactive

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

13
 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

14
 Defining the Problem

Monitor

Feedback

Users DBA Database

instance

Reports and files

15
 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

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

17
Using Features of the Packs

18
 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

19
 DB Time
DB Time =

DB Wait Time +

DB CPU Time

20
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

21
 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: Parse
• V$SYS_TIME_MODEL
• V$SESS_TIME_MODEL
• DB time represents the total SQL

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.

22
 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

23
Time Model Example

25
 Dynamic Performance Views
• Dynamic performance views provide
access to information about
changing states and conditions in the Session data

instance. Wait events

Memory allocations
Running SQL
UNDO usage
Open cursors
Redo log usage
And so on

Oracle instance

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

27
 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
 Statistic Levels

V$STATISTICS_LEVEL

STATISTICS_LEVEL

BASIC TYPICAL ALL

Disable all Additional statistics

Recommended
self-tuning for manual
default value
capabilities SQL diagnostics

29
 Statistics and Wait Events

Dynamic
Statistics
performance
Wait events
views

Reports

30
 System Statistic Classes
V$SYSSTAT User
Debug

Redo
SQL

System
statistic
classes
RAC
Enqueue

OS
V$STATNAME V$SESSTAT
Cache

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

32
 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

33
 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
...
961 rows selected.

34
 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
sessions commands
classes
User Should be
application Application Other
rare
code

RAC Cluster Inadequate database/

Configuration
resources instance configuration
Scheduler
V$SERVICE_WAIT_CLASS Resource manager V$EVENT_NAME

35
 Displaying Wait Event Statistics
EVENT X X X

• Wait event statistics levels: TOTAL_WAITS

TOTAL TIMEOUTS
X
X
X
X
X
X
• System TIME_WAITED X X X

• Service AVERAGE_WAIT
TIME_WAITED_MICRO
X
X
X
X
X
X
• Session EVENT_ID X X X
TOTAL_WAIT_FG X
• Wait event statistics columns TOTAL_TIMEOUTS_FG X

vary by view. TIME_WAITED_FG

AVERAGE_WAIT_FG
X
X
TIME_WAITED_MICRO_FG X
V$SYSTEM_EVENT
SID X
SERVICE_NAME X
V$SERVICE_EVENT SERVICE_NAME_HASH X
WAIT_CLASS_ID X X
WAIT_CLASS# X X
V$SESSION_EVENT
WAIT_CLASS X X

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

Log buffer space Log buffer I/O

Log file sync Over-commit, I/O

38
 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

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

41
Statspack
 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)

43
 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

44
 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

45
 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[…]

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

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

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

49
 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

50
 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

51
 Reading a Statspack Report: Wait Events
• Time Model System Stats
• Top 5 wait events
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

• More events information: foreground, background, mixed and even

histograms

52
 Reading a Statspack Report: Top SQL
• Top SQL based on CPU, Elapsed, Gets, etc.
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;

• Note:
• No full SQL for long text queries (and no SQL_ID – just the old hash value)

53
 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

54
 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

55
AWR – Automatic Workload
Repository
 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

57
 Automatic Workload Repository: Overview

External clients EM SQL*Plus …

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

Where the magic happens

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

58
 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

59
 What does the AWR collect?

Base SQL Advisor

statistics statistics results

Metrics ASH

AWR

60
 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

61
Workload Repository Snapshot

ADDM finds
MMON
top problems.

SYSAUX
SGA
6:00 a.m. Snapshot 1
In-memory 7:00 a.m. Snapshot 2
statistics 8:00 a.m. Snapshot 3
9:00 a.m.
Snapshot 4

9:30 a.m.

62
 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

63
 AWR Snapshot Settings

DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS (
retention IN NUMBER DEFAULT NULL,
interval IN NUMBER DEFAULT NULL,
topnsql IN NUMBER DEFAULT NULL);

• Sample every 15 minutes, keep data for 30 days:

DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS (
retention => 30 * 24 * 60,
interval => 15);

64
Database Control and AWR

Edit snapshot parameters

Run AWR report

Manage snapshots

Manage baselines

65
Generating AWR Reports in EM

66
Generating AWR Reports in EM

67
 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

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

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

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

71
Reading AWR Report
 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

73
Getting Started: AWR Header

74
Top 10 Foreground Events

75
Wait Classes

76
Main Report

77
 Wait Event Statistics
• Wait Events
• Timed Model
• Foreground and Background

78
 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

79
Time Model Statistics

80
Foreground Wait Class

81
Foreground Wait Events

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

83
Understanding the Wait Event Histogram

84
Break It Down Even More…

85
 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

86
 Top SQL Reports
SQL by Elapsed Time

SQL by CPU Time

SQL by Executions

SQL by Buffer Gets

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

88
IOStat by Function/Filetype

89
 IO Stats
• Tablespace IO Stats

• File IO Stats

90
Information by Segment

91
Segments by Write/Changes

92
 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

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

94
 Other AWR Tools:
ASH - Active Session History
 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

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

97
Active Session History: Mechanics

Viewers go
unlatched.
V$ACTIVE_SESSION_HISTORY
Statistics
1sec

ASH Direct path 1sec

Rolling
No use inserts 1sec
buffer
of SQL
V$SESSION Every Recent history
60 minutes
1 out
MMON
SGA of 10

MMNL
Workload repository
When 66% full
WRH$_ACTIVE_SESSION_HISTORY (partitioned)
DBA_HIST_ACTIVE_SESSION_HISTORY

98
 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

99
Generating ASH Reports

100
ASH in Wait Drilldown

101
ASH Report: General Section

V$ACTIVE_SESSION_HISTORY
DBA_HIST_ACTIVE_SESSION_HISTORY

102
ASH Report Structure

103
ASH Report: Activity Over Time

104
 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
105
-------------------------------------------------------------
 Other AWR Tools:
ADDM - Automatic Database
Diagnostic Monitor
 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!)

107
ADDM Performance Monitoring layout

MMON 60 minutes

In-memory
statistics
Snapshots
SGA

ADDM

AWR

ADDM results

108
Database Control and ADDM Findings

109
ADDM Analysis Results

110
ADDM Recommendations

111
Database Control and ADDM Task

112
Top Performance Issues Detected

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

114
 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

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

116
 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

117
 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

118
119
120
121
When the SQL is the Problem

Identifying Problem SQL Statements

 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

123
 TOP SQL Reports
SQL Ordered by CPU Time

SQL Ordered by Gets

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

SORT

HJ

HJ

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

HJ HJ

NL HJ

126
 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

127
 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

128
 EXPLAIN PLAN Command: Output
SELECT PLAN_TABLE_OUTPUT FROM TABLE(DBMS_XPLAN.DISPLAY());

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.

129
 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

130
 Querying V$SQL_PLAN
SELECT PLAN_TABLE_OUTPUT FROM
TABLE(DBMS_XPLAN.DISPLAY_CURSOR('cfz0cdukrfdnu'));

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

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

133
 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. SQL Trace
Trace
file
6. Format the trace file.
7. Interpret the output. Report
TKPROF
file

Database

134
 Initialization Parameters

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

135
 Enabling SQL Trace
• For your current session:
SQL> EXEC dbms_monitor.session_trace_enable;

SQL> EXECUTE dbms_session.set_sql_trace(true);

• For any session:

SQL> EXECUTE dbms_system.set_sql_trace_in_session
2 (session_id, serial_id, true);

• For instance-wide tracing:

SQL> EXEC dbms_monitor.database_trace_enable();

136
 Disabling SQL Trace
• For your current session:
SQL> EXEC dbms_monitor.session_trace_disable;

SQL> EXECUTE dbms_session.set_sql_trace(false);

• For any session:

SQL> EXECUTE dbms_system.set_sql_trace_in_session
2 (session_id, serial_id, false);

• For instance-wide tracing:

SQL> EXEC dbms_monitor.database_trace_disable();

137
 Formatting Your Trace Files
OS> tkprof tracefile outputfile [options]

• 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

138
 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.)

139
 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

140
 Generate an Optimizer Trace
• Set an event—10053 optimizer trace.

SQL> ALTER SESSION SET EVENTS

2> '10053 trace name context forever, level 1';

• Execute the statement of interest.

SQL> select *
2> from hr.employees natural join hr.departments
3> where department_id = 10;

• Find and view the trace file.

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

142
Real-time Database Operation
Monitoring
 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

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

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

146
 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

147
Database Operation Monitoring Architecture

148
 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

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

150
 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;
/

151
 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

152
Composite Operations

153
 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

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

156
 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

157
 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

158
Where to Focus: Example

159
Where to Focus: Example (cont.)

160
 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

161
 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

162
 Tuning The Memory

SGA, PGA, Temporary and Automatic Memory Management

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

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

165
 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

166
Diagnostic Tools for Tuning the Shared Pool
Views
V$SGASTAT V$SGAINFO Shared pool
V$LIBRARYCACHE Library cache
V$LIBRARY_CACHE_MEMORY Statpack
Shared SQL
V$SHARED_POOL_RESERVED report
V$SQLSTATS and PL/SQL
V$SQL
V$SQLAREA
V$SQLTEXT AWR report
Data dictionary
V$DB_OBJECT_CACHE cache

Parameters affecting the components:

SHARED_POOL_SIZE, OPEN_CURSORS
SESSION_CACHED_CURSORS, CURSOR_SPACE_FOR_TIME
CURSOR_SHARING, SHARED_POOL_RESERVED_SIZE

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

168
Load Profile

169
Instance Efficiencies

170
Top Waits

171
Time Model

172
Library Cache Activity

173
 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

174
 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

175
 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

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

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

178
 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

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

• Return few rows

Query Result
Cache

SELECT
2 3 SELECT …
Session 1 … Session 2

180
 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

181
 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

182
 Using the RESULT_CACHE Hint
EXPLAIN PLAN FOR
SELECT /*+ 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
--------------------------------------------------------------

SELECT /*+ NO_RESULT_CACHE */ department_id, AVG(salary)

FROM employees
GROUP BY department_id;

183
 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:
SELECT DBMS_RESULT_CACHE.STATUS FROM DUAL;
• Retrieve statistics on the cache memory usage:
EXECUTE DBMS_RESULT_CACHE.MEMORY_REPORT;
• Remove all existing results and clear cache memory:
EXECUTE DBMS_RESULT_CACHE.FLUSH;

• Invalidate cached results depending on specified object:

EXEC DBMS_RESULT_CACHE.INVALIDATE('JFV','MYTAB');

184
 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

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

186
 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

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

188
Buffer Cache
 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

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

191
 Buffer Busy Waits
• Application-level contention for buffers in the buffer cache
• Identify buffer busy waits contention:
SELECT class, count
FROM V$WAITSTAT
WHERE count>0
ORDER BY count DESC;

SELECT object_name, value

FROM V$SEGMENT_STATISTICS
WHERE statistic_name = 'buffer busy waits' AND
value > 20000;

192
 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

193
 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

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

195
 Free Buffer Waits

Server Buffer
state
D
dirty
Server C DBWn
A

J
Server Write
B free
K

LRU
list

196
 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

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

198
 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

Auto-tuned

Default Keep Recycle

199
 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
16 KB cache
Keep
Recycle

Set#8
Set#4

Set#5

Set#7
Set#3

Set#6
Set#1

Set#2

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

201
PGA
 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.

203
 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

204
 Monitoring SQL Memory Usage
V$SQL_WORKAREA
V$PGASTAT

V$SQL V$SQL_PLAN

V$PROCESS_MEMORY
V$SQL_WORKAREA_ACTIVE

V$TEMPSEG_USAGE V$SYSSTAT

WORK AREA

TEMP SEGMENT

OTHER
V$SQL_WORKAREA_HISTOGRAM

205
Monitoring SQL Memory Usage: Examples
SELECT sql_text,
sum(onepass_executions) onepass_cnt, 1
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, 2
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;
 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

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

208
 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

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

210
 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 temporary
Default tablespace tablespace group TEMP
EXAMPLE Tablespace … Tablespace
TEMP1 TEMPn

211
 Temporary Tablespace Group: Benefits
• Enables a user to use multiple temporary tablespaces:
• Same user in multiple sessions
• One particular parallel operation

HR Parallel
Serial HR

Tablespace Tablespace Tablespace

TEMP1 TEMP2 TEMP3
Temporary tablespace group TEMP

212
 Monitoring Temporary Tablespace
• Use V$TEMPSEG_USAGE to monitor space usage and workload
distribution:
SELECT session_num, username, segtype, blocks, tablespace
FROM V$TEMPSEG_USAGE;

• Use V$SORT_SEGMENT to determine space usage percentage:

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;

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

214
Automatic Memory Management

ASMM and AMM

 Automatic Shared Memory Management:
Overview
• Uses dynamic SGA and memory advisors to automatically adapt to
workload changes
• Maximizes memory utilization
• Helps eliminate Buffer cache
out-of-memory Buffer cache

errors Large pool

Large pool
• Avoids relearning Shared pool Shared pool
when using SPFILE Java pool Java pool
Streams pool Streams pool
Online users Batch jobs

216
 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.
Auto-tuned Manual Manual
parameters dynamic parameters static parameters
SHARED_POOL_SIZE DB_KEEP_CACHE_SIZE LOG_BUFFER
DB_CACHE_SIZE DB_RECYCLE_CACHE_SIZE
LARGE_POOL_SIZE DB_nK_CACHE_SIZE SGA_MAX_SIZE
JAVA_POOL_SIZE RESULT_CACHE_MAX_SIZE
STREAMS_POOL_SIZE SGA_TARGET

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

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

219
Automatic Memory Management: Overview
AMM Disabled AMM Enabled

Untunable Untunable Memory target Untunable

PGA PGA PGA
Free
Free PGA target
SQL areas
SQL areas
SQL areas
Buffer cache
SGA target
Buffer cache
Buffer cache
Large pool
Large pool
Large pool

Shared pool Shared pool Shared pool

Java pool Java pool Java pool

Streams pool Streams pool Streams pool

Other SGA Other SGA Other SGA

OLTP BATCH BATCH

220
Automatic Memory Management: Overview
AMM AMM
350 MB 350 MB
Memory Memory
max target max target
300 MB
Memory target

250 MB
Memory target

ALTER SYSTEM SET

MEMORY_TARGET=300M;

221
 Oracle Database Memory Parameters
MEMORY_MAX_TARGET
SGA_MAX_SIZE

MEMORY_TARGET

SGA_TARGET PGA_AGGREGATE_TARGET

SHARED_POOL_SIZE
Others
DB_CACHE_SIZE
LARGE_POOL_SIZE
JAVA_POOL_SIZE
STREAMS_POOL_SIZE

DB_KEEP_CACHE_SIZE LOG_BUFFER
DB_RECYCLE_CACHE_SIZE RESULT_CACHE_SIZE
DB_nK_CACHE_SIZE

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

223
Automatic DOP and Parallel
Statement Queuing
 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

225
 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

226
 Automated Degree of Parallelism
SQL Statement is hard parsed
If estimated time greater Optimizer determines
statement And optimizer determines the
than threshold ideal DOP
execution plan

Actual DOP = MIN(default DOP, ideal DOP)

If estimated time less
than threshold
PARALLEL_MIN_TIME_THRESHOLD

Statement executes in
parallel
Statement executes
serially

227
 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

228
 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

229
 Parallel Statement Queuing

SQL Statement is parsed If not enough parallel servers

statements and Oracle automatically available queue
determines DOP

64 64
32 32
16 128
16

FIFO Queue

When the required number of

parallel servers become
If enough parallel servers available the first stmt on the
available execute queue is dequeued and
immediately executed

128

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

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

232
 Table Compression Concepts

Inserts are again

uncompressed.

Compressed
data
PCTFREE reached
triggers compression.

Uncompressed
data
Data block PCTFREE reached
triggers compression.
Header
PCTFREE
limit

Free
space
Inserts are
uncompressed.

233
 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:
CREATE TABLE t1 COMPRESS FOR ALL OPERATIONS;

• Enable compression on existing table:

ALTER TABLE t2 COMPRESS FOR ALL OPERATIONS;

• Does not trigger compression on existing rows

234
Did You Hear About
Oracle 18c?
 Wait! 18c?! What happened to 13c?
• 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

236
 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

237
 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

238
 Q&A
Any Questions? Now will be the time!
 Zohar Elkayam
twitter: @realmgic
[email protected]
www.ilDBA.co.il
www.realdbamagic.com