2015-K-Db-Herv Schweitzer-Oracle Database Perfomance Tuning - Wie Angehen Fa Dbi Services - Praesentation

Infrastructure at your Service.
Oracle Perfomance Tuning Workshop
Oracle Performance Tuning

Your workshop instructor
Hervé Schweitzer
Chief Technology Officer
Principal consultant
Mobile +41 79 963 43 67

Herve.schweitzer@dbi-services.com
www.dbi-services.com
Oracle Performance Tuning Page 2

19.11.15
Your workshop instructor
Nicolas Jardot
Senior Consultant
Oracle Certified Professional Database 12c
Mobile +41 79 835 02 95

nicolas.jardot@dbi-services.com
www.dbi-services.com

19.11.15
Oracle Performance Tuning
Workshop Daily Schedule
09:00 – 10:30 : Workshop part 1

10:30 – 10:45 : Pause
10:45 – 12:15 : Workshop part 2
12h15 – 13h30 : Lunch
13:30 – 15:00 : Workshop part 3

15:00 – 15:15 : Pause
15:15 – 16:45 : Workshop part 4

11/19/15
Who we are
dbi services
Experts At Your Service
> 40 specialists in IT infrastructure
> Certified, experienced, passionate
Based In Switzerland
> 100% self-financed Swiss company
> Over CHF 6 mio. turnover
Leading In Infrastructure Services
> More than 100 customers in CH, D, & F
> Over 40 SLAs dbi FlexService contracted
dbi services is hiring in Basel & Zürich (career@dbi-services.com)

19.11.15
Our products
Database Management Kit – for free
Making IT easy for DBAs
> Platform independent, standardized scripts for Unix/Linux
& Windows – absolutely free!
> Numerous customers trust in DMK for a reliable & efficient
database infrastructure
> Simple, safe, and speedy way to carry out various DBA
tasks:
> Setting up database environments
> Start/stop of database components
> Checking of relevant database settings
> No time for maintenance & setup?
Profit from DMK Support!
www.dbi-services.com/DMK

19.11.15
Our products
dbi InSite Workshops
Expert insight from insiders
> Your instructors are experienced and certified consultants
> 2-4 day Workshop adjusted to your real needs
> Organized on-site or externally
> No theory: practical exercises, live demos, and case studies
Large portfolio
> Oracle Database: DBA, NF12c, B&R, Tuning, Data Guard, Grid Infra/RAC
> MS SQLServer: DBA, Tuning, NF 2012, NF 2014, etc
> PostgreSQL: DBA
> MS Sharepoint: Administration
> Middleware: APEX, WebLogic
> MySQL: DBA
> Linux: DBA
www.dbi-services.com/trainings

19.11.15
Oracle Performance Tuning workshop
Goals of the workshop
Method
> How to approach performance issues
> How to focus on the root cause
> How to match user perception of performance with system monitoring
Concepts
> How the Oracle database interacts with the system
> How the optimizer works
> Which are the different access path to data
Tools
> How to monitor performance
> How to fix performance issue
> From the application
> From the system

11/19/15
Oracle Performance Tuning workshop
Agenda
1. Introduction
2. Cost Based Optimizer
3. Access Path
4. Monitoring performance
5. Conclusion

11/19/15
Oracle Performance Tuning Workshop
Oracle Performance Tuning – Introduction

Agenda
1. Introduction
3. Access Path
5. Conclusion
Oracle Performance Tuning – Introduction Page 2

19.11.15
The goal of performance tuning
End-user performance perception
The main goal
> Reduce the response time for the critical use cases
Percentiles
> Do you want all user interactions to be less than 1 second
> Or do you want that 90% of user interactions are less than ½ second?
> Performance requirements should be defined with percentiles
How the end-user feels the performance

> 1 minute is not long for a report run once each year
> 20 seconds is very long when having a customer at the phone
> 10 seconds seems long for a query that is often less than 1 second

19.11.15
End-user performance perception
The user will probably call you
> When the system is very good and there is a sudden degradation
> When they know you can do something for them
The user will probably not call you

> When they think the system is always slow, and it’s just slower than usual
> When you improved something
It’s always a good idea to meet the end user

19.11.15
The secondary goals of performance tuning
Stability
> Having irregular response time is often worse than bad response time
Scalability
> Even when the response time is not affected, scalability issues must be
addressed proactively
Resource consumption
> Even when the response time is not affected, we want to use less
resources:
> Use less CPU because we pay licenses on CPU
> Use less bandwidth shared with other systems
> Save energy

19.11.15
Response time vs. Throughput
If you want the fastest response time PROC PROC
> You want to avoid queuing
PROC
> You give one CPU for each user
> Each call is processed immediately PROC PROC
> But the throughput is not optimized
> Some CPU will be idle, just waiting
You can improve throughput

> Throughput is regulated by queuing PROC PROC PROC PROC
> But response time increases PROC PROC PROC

> And queuing may bring more contention
(context switching) PROC PROC PROC PROC

19.11.15
Who is involved in performance tuning
Tuning only from system is very limited

> You don’t know what you tune
> You can’t improve the design
> You can only make slow operations a bit less slower
When an operation is slow

> Do it faster
> Do it less
this requires application knowledge
> Don’t do it at all
The major potential improvement is from design

> Involves business (performance requirements)
> Involves development (design)
> Involves system (monitor and configure)

19.11.15
What skills are involved in performance tuning
Understand how it works

> In 1 day workshop we cannot give all rules and patterns
> For all database versions (bugs and new features in each release)
> For all system architectures (VM, SATA, SSD, Cluster)
> For all application workloads (OLTP, DSS)
> We give the concepts to understand what you see
Measure what it does
> Tools available
> For developer / DBA
> In Standard / Enterprise Edition, with or without options
Methodology to
> Address the real issue
> Fix the root cause (workarounds and fixes)

19.11.15
Agenda
1. Introduction
2. Cost Based Optimizer Understand
3. Access Path
4. Monitoring performance Analyze
5. Conclusion

19.11.15
Oracle Performance Tuning – Cost Based Optimizer

Agenda
1. Introduction
3. Access Path
5. Conclusion
Oracle Performance Tuning – Cost Based Optimizer Page 2

19.11.15
Cost Based Optimizer
> Optimizer overview

> Objects statistics
> Other statistics
> SQL execution

19.11.15
Optimizer overview
Why?
SQL is a declarative language
> We describe the result we want, not the way to get it
> The RDBMS is responsible to choose the most efficient access
There are several ways to retrieve data (access path)

> We can go through tables in different orders
> We can get data from different structures (redundant: index, mviews)
> We can use different algorithms (joins, sorts)
The optimizer
> Evaluates the different ways to access data
> Chooses the most efficient

19.11.15
Optimizer overview
Optimizer concept
Optimizer role
> Find the most efficient path to return data
> Generate execution plans from SQL query
Two main versions

> Rule Based Optimizer (RBO): Deprecated
> Cost Based Optimizer (CBO): Actual recommended and used by default
Cost Based Optimizer (CBO)

> Transforms the statement
> Generate different execution plans
> Evaluates costs (I/O and CPU) for all operation to get cost for several
execution plans
> Choose execution plan with the best cost

19.11.15
Optimizer overview
RBO vs. CBO
Rule Based Optimizer Cost Based Optimizer
> Heuristic based optimizer > Evaluates different access paths
> Choose between 17 possible > Computes cost for several execution
access paths plans
> Lower ranked access path is > Selects plan with the lowest cost
chosen
> De-supported since Oracle 10g > Available since Oracle 7, default since
Oracle 10g
RBO cannot be used with new objects types or new features
It shall not be used in recent releases
Don’t use anymore the hint /*+ RULE */
19.11.15
Optimizer overview
Optimizer vocabulary
Row set
> Table, View, or result of a Join or Group by
Predicate
> Filter condition on a row set
Example: name = 'SMITH'
Selectivity
> How many rows returned from a row set using a predicate?
> Value from 0.0 to 1.0
Example: selectivity = 0.1, table = 1000 rows
0.1 * 1000 = 100 returned rows

19.11.15
Optimizer overview
Optimizer vocabulary
Cardinality
> How many rows in a row set?
> Example: There are 107 rows in table HR.EMPLOYEES
Cost
> Estimate amount of work required for one operation
> Expressed as CPU, I/O and memory
> I/O cost not expressed in rows but in number of I/O calls
> The cost value is proportional to the estimated time
> The cost unit is the estimated time for one I/O
> The cost is an estimation used by the optimizer.

> It has no value for us, especially when optimizer did a bad choice.

19.11.15
Optimizer overview
CBO structure
Inside the optimizer
> Optimizer works closely with the statistics and uses a cost model
Query Transformer
Data Dictionary
Plan Generator
Cost Estimator

19.11.15
Optimizer overview
Configuration
Database parameters control the optimizer heuristic
> optimizer_mode: ALL_ROWS | FIRST_ROWS_N
Two available ways

> ALL_ROWS: Use least amount of resources to return all rows – Best
throughput
> FIRST_ROWS_N: Use least of resources to return the first row(s) – Best
response time
dbi services recommends to keep the default value at instance level:

OPTIMIZER_MODE=ALL_ROWS
> And change to FIRST_ROWS_n at session or query level when we know we
will fetch only few rows (pagination)

19.11.15
Optimizer overview
Configuration
Several other parameters are available
> optimizer_features_enable: Control feature availability to work in
compatibility mode. By default equals to installed release
> optimizer_index_cost_adj (100): Adapt cost for index access
> optimizer_index_caching (0): Adjust index caching and impact index cost
It’s not advised to change parameters

> They fake the optimizer estimations
> They are there only for exceptions (bugs)
> Better to have good statistics on involved objects and system stats
> Recommendation since 8i: don’t set optimizer_index_* parameters
Some parameters can be pushed using hint if really needed

> OPT_PARAM: Allow changing database parameter at statement level

19.11.15
Optimizer

> Other statistics
> SQL execution

19.11.15
Objects statistics
Statistics overview
Use to give information about data in the object
> Number of rows
> Number of blocks and empty blocks
> Number of distinct values/nulls for a column
> The lowest and the highest value for a column
> Level or clustering factor for an index
Use static views to read object statistics

> ALL_TABLES / ALL_TAB_STATISTICS: Table statistics
> ALL_TAB_COLS / ALL_TAB_COL_STATISTICS: Column statistics
> ALL_INDEXES / ALL_IND_STATISTICS: Index statistics
> ALL_TAB_HISTOGRAMS : Histogram information

19.11.15
Objects statistics
Read object statistics
Check table statistics
SQL> select table_name, num_rows, blocks, empty_blocks,
avg_space, avg_row_len
from user_tab_statistics;
TABLE_NAME NUM_ROWS BLOCKS EMPTY_BLOCKS AVG_SPACE AVG_ROW_LEN

------------- ------------ ------ ------------ -------- -----------
EMPLOYEES 107 5 0 0 69
…
Check column statistics

SQL> select table_name, column_name, num_distinct, num_nulls, density
from user_tab_col_statistics
where table_name = 'EMPLOYEES'
TABLE_NAME COLUMN_NAME NUM_DISTINCT NUM_NULLS DENSITY

---------- --------------- ------------ ---------- ----------
EMPLOYEES EMPLOYEE_ID 107 0 .009345794
EMPLOYEES COMMISSION_PCT 7 72 .142857143
…

19.11.15
Objects statistics
Gather object statistics
Gather table statistics
exec dbms_stats.gather_table_statistics('HR', 'EMPLOYEES');
dbi services recommends using the default settings for statistics

gathering (since 11g)
> Using non-default values will disable new histograms in 12c: Top
Frequency and Hybrid
Starting Oracle 10g, an automatic job gather object statistics

automatically
> Run during the default maintenance window at night
> Started as automatic maintenance task starting 11g
> Gather only for objects with stale statistics
> Process object in order, start with very stale object first
> Gather objects and dictionary statistics

19.11.15
Objects statistics
Temporary objects statistics
Temporary objects have session’s private data
Before 12c, there is no specific management for temporary objects

> Same stats used by all sessions or dynamic sampling when there are no
stats
> Cursors can be shared and plans might be re-used even if not expected
Oracle 12c offers the ability to have private set of statistics

> Each session gather its own set of statistics
> Cursors will not be shared when statistics are different
How to enable private statistics

SQL> exec dbms_stats.set_table_prefs(<owner>,<tablename>,
'GLOBAL_TEMP_TABLE_STATS','SESSION');

19.11.15
Objects statistics
Gather statistics parameters
Default settings
SQL> SELECT sname,
nvl(to_char(sval1),spare4) value
FROM sys.optstat_hist_control$;
SNAME VALUE
------------------------------ ----------------------------------
STATS_RETENTION 31
SYS_FLAGS 1
APPROXIMATE_NDV TRUE
CASCADE DBMS_STATS.AUTO_CASCADE
ESTIMATE_PERCENT DBMS_STATS.AUTO_SAMPLE_SIZE
DEGREE NULL
METHOD_OPT FOR ALL COLUMNS SIZE AUTO
NO_INVALIDATE DBMS_STATS.AUTO_INVALIDATE
GRANULARITY AUTO
PUBLISH TRUE
STALE_PERCENT 10
INCREMENTAL FALSE
INCREMENTAL_INTERNAL_CONTROL TRUE
AUTOSTATS_TARGET AUTO

19.11.15
Objects statistics
Gather statistics preferences
Parameters can be set at different levels
> Global, Database, Schema, Table
Configure statistics gathering
> Global : Sets the global statistics preferences
> Database: For existing schema objects only (excluding Oracle objects)
> New objects will pick up the GLOBAL_PREF values for all parameters
exec dbms_stats.set_[global|database|schema|table]_prefs(
ownname =>'HR',
tabname =>'EMPLOYEES',
pname =>'ESTIMATE_PERCENT',
pvalue =>'100');
exec DBMS_STATS.SET_TABLE_PREFS (ownname => 'APPLIC',

tabname =>'QUEUE_TABLE',pname=>'ESTIMATE_PERCENT', pvalue =>'100');
exec DBMS_STATS.SET_GLOBAL_PREFS('STALE_PERCENT', 5);

19.11.15
Objects statistics
Default data distribution
By default Oracle assumes a balanced data distribution
> Selectivity = 1 / num. distinct values = 1 / 4 = 0,25
> If table contains 100 rows: 100 * 0,25 = 25 for each value (cardinality)

19.11.15
Objects statistics
Skewed data distribution
In real data set data can be skewed
> Oracle’s assumption about distribution might lead to bad cardinalities
> Another statistic type is necessary to describe the balance

19.11.15
Objects statistics
Histograms types
Histogram describes data distribution in a column
> Allow Oracle to know when data distribution is not uniform (i.e. skewed)
Oracle sorts data to create histograms (12c uses Approximate NDV)

> Data is always ordered in histograms
Four histogram types exist in 12c

> Frequency: Provide number of rows for each value (<254 distinct values)
> Top-Frequency: Provide number of rows for top most popular values when
there are more than 254 distinct values (under conditions)
> Height-Balanced: values are divided so each bucket contains the same
amount of rows (not created anymore by default in 12c)
> Hybrid: Evolution of Height-Balanced. Repeated value are not stored in
different buckets and a new count allows Oracle to get better estimation

19.11.15
Objects statistics
Frequency histograms
In frequency histograms, the buckets contain the column values
> Number of bucket n can be specified using method_opt
> 254 buckets by default, 2048 maximum in 12c
> Frequency/Top frequency contains the number of occurrences for each
value
Oracle creates frequency histogram

> If num. distinct values <= n (number of buckets)
Oracle creates top frequency histogram

> If num. distinct > n
> And if the percentage of rows occupied by top n frequent values is near
than 99.6% (n=254)
> And estimate_percent = AUTO_SAMPLE_SIZE (default)

19.11.15
Objects statistics
Frequency histogram gathering
> num. distinct <= n (4)
1 1 2 2 2 2 2 2 3 3 3 4
1 2 3 4
Endpoint 2 Endpoint 8 Endpoint 11 Endpoint 12

19.11.15
Objects statistics
Read a frequency histogram
> Endpoint_value = column value
> Endpoint_number = cumulative frequency for endpoint_value
SQL> select endpoint_number, endpoint_value,

endpoint_number - nvl(lag(endpoint_number,1) over (order by
endpoint_number),0) frequency
from user_histograms
where table_name='HISTOGRAM'
and column_name='COLUMN'
order by endpoint_number;
ENDPOINT_NUMBER ENDPOINT_VALUE FREQUENCY
--------------- -------------- ----------
2 1 2
8 2 6
11 3 3
12 4 1

19.11.15
Objects statistics
Height-balanced histograms
Height-balanced histogram
> Data is split in order to get same amount of rows in each bucket
> Endpoint_number is the bucket number
> Endpoint_value records the last value in the bucket
> Value is considered popular when it’s ending at least two buckets
Oracle creates height-balanced histogram

> Before 12c, if num. distinct > n
> In 12c, if num. distinct > n and estimate_percent != default value

19.11.15
Objects statistics
Height-balanced histogram gathering
> Before 12c, Height-balanced histogram is created when num. distinct > n
1 1 2 2 2 2 2 2 3 3 3 4
1 7 2 2 4
Endpoint 0 Endpoint 1 Endpoint 2 Endpoint 3

19.11.15
Objects statistics
Read a Height-balanced histogram
> Endpoint_number = bucket id
SQL> select endpoint_number, endpoint_value,
endpoint_number-nvl(lag(endpoint_number,1) over (order by
endpoint_number),0) bucket_size
where table_name='HISTOGRAM'
and column_name='C2'
ENDPOINT_NUMBER ENDPOINT_VALUE BUCKET_SIZE
--------------- -------------- -----------
0 1 0
2 2 2
3 4 1
Buckets are merged if ending with the same value

> Allow to quickly identify popular value

19.11.15
Objects statistics
Hybrid histograms
Hybrid histogram
> Starting 12c, Hybrid histogram is created when num. distinct > n
> If top-frequency is not possible
> and estimate_percent = AUTO_SAMPLE_SIZE
> Same value cannot be split into two distinct buckets
> New property endpoint_repeat_count to store number of occurrences
> Endpoint_number records the cumulative frequency

19.11.15
Objects statistics
Hybrid histograms
Hybrid histogram gathering in 12c
> Bucket size is dynamic
1 1 2 2 2 2 2 2 3 3 3 4
1 2 4
2 6 1
Endpoint 2 Endpoint 8 Endpoint 12

19.11.15
Objects statistics
Hybrid histograms
Read a Hybrid histogram
> Endpoint_number = cumulative frequency
> Endpoint_repeat_count = number of endpoint_value in the bucket
SQL> select endpoint_number, endpoint_value, endpoint_repeat_count,

endpoint_number-nvl(lag(endpoint_number,1) over (order by
endpoint_number),0) bucket_size
where table_name='T'
and column_name='C2'
ENDPOINT_NUMBER ENDPOINT_VALUE ENDPOINT_REPEAT_COUNT BUCKET_SIZE

--------------- -------------- --------------------- -----------
2 1 2 2
8 2 6 6
12 4 1 4

19.11.15
Objects statistics
Extended statistics
By default Oracle assumes there is no relationship between
columns
> Adding predicates should decrease the number of returned rows
> If columns are correlated cardinalities will be under estimated
Example of correlated columns

SQL> select * from locations where country='CH' and region='BS';
> Every location in Basel-Stadt is also in Switzerland

> Adding the filter will make Oracle divide the expected cardinality
Column group extended statistics provides a solution

> Oracle computes statistics for combination between the columns
SQL> exec dbms_stats.create_extended_stats(USER, 'LOCATION',
'(country, region)');

19.11.15
Objects statistics
Demo: Statistics History
> Connect as demo/demo(DB1) and check execution plan for:

SQL> set long 10000 linesize 130 autotrace on
SQL> select cust_gender,count(*) from CUSTOMERS where
cust_year_of_birth=1913 group by cust_gender;
> Gather statistics and run same query:

SQL> exec dbms_stats.gather_table_stats(user,'CUSTOMERS');
> Check statistics difference and return to previous statistics

SQL> select * from
table(dbms_stats.diff_table_stats_in_history(user,'CUSTOMERS',
sysdate-1));
SQL> exec dbms_stats.restore_table_stats(user,'CUSTOMERS',
as_of_timestamp=>sysdate-1);
>
> Run the query again

19.11.15
Optimizer

> Other statistics
> SQL execution

19.11.15
Other statistics
System statistics
System statistics
> Describe the hardware: How fast the server is?
> Used to compute the I/O and CPU costs
Two kind of statistic gathering

> Noworkload statistics
> Workload statistics
System statistics are not collected per default

> At startup, default noworkload statistics are set

19.11.15
Other statistics
Check system statistics
Check system statistics
SQL> set lines 132 pages 20
col PVAL2 format a30
select * from sys.aux_stats$;
Field SNAME differentiates information

> SYSSTATS_INFO: status and when gathered
> SYSSTATS_MAIN: shows the statistics values
> SYSSTATS_TEMP: available while gathering statistics
dbi services recommends to review system statistics

> At minimum gather NOWORKLOAD system statistics
> Caution: bug in 11.2.0.1/2 (See dbi's blog: http://tinyurl.com/ba9xsaf )
> Always check them after gathering

19.11.15
Other statistics
Read system statistics
Only no workload statistics are available on a new system
SQL> col PVAL2 format a30
SQL> select * from sys.aux_stats$;
SNAME PNAME PVAL1 PVAL2

--------------- ---------- ---------- --------------------
SYSSTATS_INFO STATUS COMPLETED
SYSSTATS_INFO DSTART 11-09-2012 14:42
SYSSTATS_INFO DSTOP 11-09-2012 14:42
SYSSTATS_INFO FLAGS 1
SYSSTATS_MAIN CPUSPEEDNW 3698.67374
SYSSTATS_MAIN IOSEEKTIM 10
SYSSTATS_MAIN IOTFRSPEED 4096
SYSSTATS_MAIN SREADTIM
SYSSTATS_MAIN MREADTIM
SYSSTATS_MAIN CPUSPEED
SYSSTATS_MAIN MBRC
SYSSTATS_MAIN MAXTHR
SYSSTATS_MAIN SLAVETHR

19.11.15
Other statistics
System statistics details
Parameters
> CPUSPEEDNW represents CPU speed using noworload benchmark
> IOSEEKTIM represents disk latency (seek time for I/O in millisecond)
> IOTFRSPEED is the transfer speed from disk (bytes per millisecond)
> CPUSPEED represents average number of CPU cycles per second
> SREADTIM represents the average time to read a single block randomly
> MREADTIM is the average read time to read multi block sequentially
> MBRC is the average number of blocks during multi block read
> MAXTHR is the maximum I/O throughput the I/O subsystem can deliver
> SLAVETHR is the average I/O throughput for a parallel processing slave
These parameters describes hardware characteristics

> They are used to estimate the costs of SQL statements

19.11.15
Other statistics
Gather system statistics
Gather noworkload statistics
> Gather on idle system
> Synthetic benchmark
> I/O transfer speed
> I/O seek time
> CPU speed
SQL> exec
dbms_stats.gather_system_stats(gathering_mode=>'NOWORKLOAD');

19.11.15
Other statistics
Gather system statistics
Gather workload statistics
> I/O performance: single and multi block read time
> I/O multi block read count
> Max system throughput and CPU performance
Use dbms_stats to gather workload system

SQL> exec dbms_stats.gather_system_stats('INTERVAL', 60);
> (interval in minutes) or with start/stop:

SQL> exec dbms_stats.gather_system_stats('start');
SQL> exec dbms_stats.gather_system_stats('stop');
Review gathered values and change them if needed

SQL> exec dbms_stats.set_system_stats('name', value);

19.11.15
Other statistics
Dictionary and fixed objects statistics
Dictionary statistics
> Basically same as object statistics but for data dictionary objects
> Are maintained via the automatic statistics gathering job running during
the nightly maintenance windows
Fixed objects statistics

> Statistics for x$ objects
> Describe memory structures: How big your memory objects are
> Not gathered by the automatic job
> Not available by default
Gather fixed object statistics

SQL> exec DBMS_STATS.GATHER_FIXED_OBJECTS_STATS();

19.11.15
Other statistics
Fixed objects statistics
Check fixed object statistics
SELECT count(*)
FROM dba_tab_statistics st, v$fixed_table ta
WHERE st.table_name = ta.name
and ta.type='TABLE'
and st.last_analyzed is not null;
Gather fixed object statistics on a running system

> Compute only once
> Re-compute after change: upgrade or memory increase

19.11.15
System Statistics
Demo: AUX_STATS$
Try the following statistics gathering methods

SQL> exec dbms_stats.delete_system_stats;
SQL> exec dbms_stats.gather_system_stats('noworkload');
SQL> exec dbms_stats.gather_system_stats('exadata');
SQL> exec dbms_stats.gather_system_stats('start');

SQL> exec dbms_stats.gather_system_stats('stop');
> Default: SREADTIM=12ms MREADTIM=26ms
> NOWORKLOAD measures IOSEEKTIM and IOTFRSPEED :

SREADTIM = IOSEEKTIM + db_block_size / IOTFRSPEED
MREADTIM = IOSEEKTIM + db_block_size * MBRC / IOTFRSPEED
> WORKLOAD between start and stop. Also measures MBRC
> EXADATA: IOSEEKTIM=200MB/s and fixes MBRC

19.11.15
Optimizer

> Other statistics
> SQL execution

19.11.15
SQL execution
Overview of SQL execution
Optimizer is involved in parsing time Open Cursor
and receive different inputs
Parse
SQL statement to optimize
> Apply transformation and rewrite rules
Binding
System statistics
> Use to adjust I/O and CPU costs
Execute
Object statistics
> Number of rows, Histograms Fetch
> Apply selectivity to get the cardinality
Close Cursor

19.11.15
SQL execution
Cursor types
A cursor is a pointer to a memory structure
> Cursors are stored in the Library Cache (in Shared Pool/SGA)
Two cursor types

> Parent cursor store the text of the SQL statement
> Child cursor contains execution plan and related optimizer environment
Parent cursor is identified by SQL_ID in v$sqlarea
Child cursor is identified by SQL_ID and CHILD_NUMBER in v$sql

19.11.15
SQL execution
Parsing process
Simplified execution process
SQL Parsing /
Execution
Statement Optimization
Optimizer is involved at parsing/optimization time to

generate an execution plan
There are two cases

> Hard Parsing when the SQL is executed for the first time
> Soft Parsing when the SQL has already been executed and
several steps of Hard Parsing have been performed previously

19.11.15
SQL execution
Hard parse – Optimization
• Include VPD predicates

VPD
• Syntax check
Parent • Semantic check
cursor Parsing • Check access rights
• Query rewrite
Logical • Optimizer transformation
Optimization
Data • Generate execution plans

Dictionary Physical • Compute cost for generated plans
Optimization
Child
cursor

19.11.15
SQL execution
Soft parse
• Include VPD predicates

VPD
• Syntax check
Parent • Semantic check
cursor Parsing • Check access rights
• Query rewrite
Logical • Optimizer transformation
Optimization
• Generate execution plans

Dictionary Physical • Compute cost for generated plans
Optimization
Child
cursor

19.11.15
SQL execution
Cursor sharing
A parent cursor can be shared
> if SQL text is the same
> if instance parameter CURSOR_SHARING is different from EXACT
A child cursor can also be shared

> statements share the same parent
> the execution environments are 'compatible’ – optimizer parameters
Sharing avoids to recompile the SQL at each execution
v$sql_shared_cursor shows the reason why a child was created

> Look at columns where value = Y (there is a REASON column since 11g)

19.11.15
SQL execution
Bind variables
Bind variables are placeholders in SQL queries
> Allows to write statements with variables
> Bind are replaced by their values at execution time without changing SQL
text (to allow cursor sharing)
> Bind variable datatype matters
Declare bind variables

variable v_id NUMBER
variable v_name VARCHAR2(12)
variable v_date DATE
exec :v_id:= 5;
exec :v_name:='SMITH';
exec :v_date:=to_date('01/08/14','DD/MM/YY');
Use bind variables

SQL> select from employees where emp_id=:v_id;

19.11.15
SQL execution
Bind peeking and Adaptive Cursor Sharing (ACS)
Bind variable peeking
> Introduced at Oracle 9iR2
> Optimizer takes value of variables at first execution
> Used to estimate cardinalities
> Drawback: execution plan is too often not optimal for all values possible
Adaptive Cursor Sharing (ACS)

> Introduced in 11g to solve peeking issues
> Allow several execution plans for same statement
> IS_BIND_SENSITIVE and IS_BIND_AWARE in V$SQL[AREA] help monitor
ACS usage
> V$SQL_CS_SELECTIVITY shows estimated selectivity for all children

19.11.15
SQL execution
Demo: Bind variable peeking
On a table with histograms and skewed data

C COUNT(*)
- ----------
M 4
F 1

C COUNT(*)
- ----------
M 613
F 312
Show execution plan

> With literals and bind values, in different order

19.11.15
SQL execution
Automatic Reoptimization
Automatic reoptimization allows Oracle to change a cursor after the
execution
> The optimizer compares estimations with real execution statistics
> If the difference is too important, next execution will use data collected at
previous execution to get a better execution plan
Oracle 12c supports two automatic reoptimization

> Statistics feedback (i.e. Cardinality feedback in 11g)
> Performance feedback
Reoptimization can happen several times on the same query

> Reoptimization can also be combined with others optimization features

19.11.15
SQL execution
Automatic Reoptimization – Statistics feedback
Oracle compares the number of rows
> number of returned/processed rows A-rows
> number of expected/estimated rows E-rows
If the difference is too important
> Cursor is flagged to be hard parsed again for the next executions
How to verify number of actual rows?
SQL> alter session set statistics_level=all;
SQL> select /*+ gather_plan_statistics */ ......
How to verify if statistics feedback will be used?

> Since 11.2.0.2 in V$SQL_SHARED_CURSOR
SQL> select sql_id, child_number, use_feedback_stats
from v$sql_shared_cursor where USE_FEEDBACK_STATS='Y';
> Since 12.1.0.1 in V$SQL
SQL> select sql_id, child_number, use_feedback_stats
from v$sql where IS_REOPTIMIZABLE='Y';

19.11.15
SQL execution
Dynamic Statistics (i.e. Dynamic Sampling)
Controlled by instance parameter: optimizer_dynamic _sampling
> Collects statistics by sampling during statement compilation
> Criteria to use and sample size is controlled by the level
> Levels go from 0 (disabled) to 11 (full automatic – since 11.2.0.4)
> For parallel statements Optimizer automatically set the level
Used when current statistics are not sufficient

> Missing statistics, unusable statistics: complex predicate for example
> Stale statistics (work in combination with SQL Plan Directives)
Default level of 2 fits with OLTP

> ad-hoc queries with literals (DSS, BI, reporting, analytic queries)
can use level 4 (more time to optimize and get a better plan)

19.11.15
SQL execution
SQL Plan Directives
Component introduced in 12c
> Used to keep information that help generate a good execution plan
> The optimizer will check directives during compilation
Directives are persistent

> Directives are created in memory within the shared pool
> Information is regularly flushed in SYSAUX tablespace
SQL> exec dbms_spd.flush_sql_plan_directive;
SQL> select * from dba_sql_plan_dir_objects join

dba_sql_plan_directives using (directive_id)
Directives are based on objects and expressions

> Allow the same directive to be used for different statements

19.11.15
SQL execution
SQL Plan Directives
Currently used to monitor statistics
> SPD are created by the optimizer when missing statistics is responsible for
an optimizer bad decision
> If dynamic statistics have been used
> If cardinality feedback has been used
> SPD are persisted with the state of missing statistics
> SPD are updated when the state of statistics change
Directives are used by several components

> Used by optimizer to determine the need for dynamic statistics
> Used by dbms_stats to determine useful extended statistics
> SPD are purged after 53 weeks if not used or manually with dbms_spd

19.11.15
SQL execution
Demo: SQL Plan Directives
On a table with correlated columns:

> 1st execution shows bad estimations
> Cursor marked as REOPTIMIZABLE
> SPD in NEW state
> 2nd execution of same query
> Statistics feedback to correct the estimations
> SPD in MISSING STATS state
> 1st execution of a different query with same predicates
> SPD is used to correct estimations with dynamic sampling
> Gather statistics on table
> Extended statistics are created to correct the estimations
> SPD is still in MISSING STATS state
> 1st execution of another different query
> SPD has been verified and changed to HAS STATS state

19.11.15
Cost Based Optimizer
Core Message
The optimizer chooses the execution plan
> The decision is controlled by instance parameters,
objects statistics and system statistics
Default values are good enough for most kind of workload

> Default values combined with adaptive features provide good enough
performance in most cases
Statistics and histograms are the main inputs

> Give the optimizer correct information (statistics, constraints, …)
> Wrong statistics generally leads to bad execution plans
Any questions? Please do ask.

19.11.15
Oracle Performance Tuning – Access Path

Agenda
1. Introduction
3. Access Path
5. Conclusion
Oracle Performance Tuning – Access Path Page 2

19.11.15
Access Path
> I/O mechanisms

> Table Access
> Index Access
> Join Methods
> Sorts and hash
> Hints

19.11.15
I/O mechanisms
I/O operations at O.S level
There are different methods available for accessing data
> Direct I/O: Read bypass O.S / file system caches
> Synchronous I/O: Wait for I/O completion after I/O request
> Asynchronous I/O: Allows processing during I/O request completion
I/O operations are controlled by two parameters

> filesystemio_options (none | setall | directIO | asynch): Control access
method for file stored on file system
setall = directIO + asynch
> disk_async_io (TRUE | FALSE): Enable asynchronous I/O for datafiles,
control files and logfiles if supported by the platform
Generally enabling both direct I/O and asynchronous I/O offers

better performance

19.11.15
I/O mechanisms
Database I/O – Conventional reads
Data is read from disk to the database buffer cache
> Also called buffered reads
> Data blocks stored in SGA can be shared and can be cached
> We can read on block at a time, or multiple contiguous blocks in one i/o
Sequential read
> Single-block read sequentially
> Usually used for direct block access like TABLE ACCESS BY ROWID
Scattered read
> Multi-block read into non adjacent memory locations
> Up to DB_FILE_MULTIBLOCK_READ_COUNT blocs in a single operation
> Usually used for large scans: FULL TABLE SCAN, INDEX FAST FULL SCAN

19.11.15
I/O mechanisms
Database I/O – Direct reads
Always used for parallel read
Can be used for serial reads since 11g
> Decision not done by the optimizer but at execution time for each segment
> Starting 11.2.0.2, decision is done using the statistics instead of actual
number of segment blocks
Data is read from disk directly into PGA

> Bypass databases caches (e.g. buffer cache) after a checkpoint
> Algorithm based on table size, buffer cache size
and number of cached blocks for serial read
> Segment size must be bigger than 5 * threshold defining small tables
> Less than 50% segment’s blocks is in the buffer
> Less than 25% segment’s blocks are dirty in the cache

19.11.15
Access Path
> I/O mechanisms

> Table Access
> Index Access
> Join Methods
> Sorts and hash
> Hints

19.11.15
Table Access
Full Table Scan
Heap Tables (the default)
> Can store a row anywhere within the segment
> Pushes the ‘High Water Mark’ when formatting new blocks
> Segment header has the allocation map (and the HWM)
Full Table Scan has to read all blocks up to the HWM

> Even if there is no rows (had rows that have been deleted)
> Uses efficient multiblock reads (large I/O) Inserts
Deletes
> Good when we need rows from most of the blocks Full Table Scan
HWM 0001 0004 0007 0010

0 blocks
1
2
3
4 0002 0005 0008 0011
0003 0006 0009 0012
0 rows fetched.
19.11.15
Table Access
How to lower the High Water Mark
HWM
0001 0004 0010
4 blocks 0002 0008 0011
0003 0006 0012
ALTER TABLE SHRINK SPACE COMPACT

HWM
0001 0004 0011
4 blocks 0002 0010 0008
0003 0006 0012
ALTER TABLE SHRINK SPACE or ALTER TABLE MOVE

HWM
0001 0004 0011
3 blocks 0002 0010 0008
0003 0006 0012
TRUNCATE TABLE
HWM
0 blocks

19.11.15
Table Access
Multiblock read
When reading several contiguous blocks
> Read all in one I/O call (db file squattered read)
> Up to db_file_multiblock_read_count (default: OS max I/O size)
> Only blocks that are not already in buffer cache
Blocks 0004, 0007 and 0008 already in cache:

block block block block block block block block block block block block
0001 0002 0003 0004 0005 0006 0007 0008 0009 0010 0011 0012
All blocks read in 3 I/O calls
Recommendation
> Don’t set the db_file_multiblock_read_count
> If it needs to be set (I/O size is smaller), be sure to have
workload system statistics for optimizer to use them

19.11.15
Table Access
Demo: Multiblock Read
Full table scan wait events

1. With db_file_multiblock_read_count=16
EVENT P3TEXT P3 WAIT_TIME_MICRO
------------------------------ ---------- ---------- ---------------
direct path read block cnt 16 17
2. With db_file_multiblock_read_count=64
3. Reading to buffer cache

db file scattered read blocks 64 353
db file scattered read blocks 62 321
4. Reading only single blocks

db file sequential read blocks 1 4
db file sequential read blocks 1 5

19.11.15
Table Access
Table access by rowid
ROWID identifies a table row
> The segment has an id (data_object_id)
> The extent is in a file (relative_fno)
> The block has an offset in the file (block_id)
> The row has a number in the block (the row directory entry)
Access by ROWID
> Is the fastest access to retrieve one row
> Is the slowest access to retrieve all the rows
ROWID can come from

> User provided rowid (not consistent across transactions)
> Index entries that address the table row with a ROWID
> Hash cluster that calculates ROWID from hash function

19.11.15
Table Access
Demo: table access by rowid
> Connect as demo/demo

> Set autotrace
> Get rowid for customer 100
SQL> set autotrace on
SQL> select rowid,cust_id from CUSTOMERS where cust_id=100;
> how many blocks are read?
> Get row from this rowid

SQL> select * from CUSTOMERS where rowid='AAAXYMAAGAAABZaAA7';
> how many blocks are read?
> View ROWID information

SQL> select dbms_rowid.rowid_object(rowid)
,dbms_rowid.rowid_relative_fno(rowid)
,dbms_rowid.rowid_block_number(rowid)
,dbms_rowid.rowid_row_number(rowid)

19.11.15
Table Access
Exercise: fetch size
> Connect as demo/demo

> Create the following table and check number of blocks:
SQL> create table DEMO as select CUST_ID from CUSTOMERS;
SQL> select blocks from user_tables where table_name='CUSTOMERS';
> how many blocks under high water mark?
> Set autotrace and select all rows:

SQL> select * from DEMO;
> how many blocks are read (consistent gets)?

> Why? How to read the minimum of blocks?
Hints:
1. Multiblock read is good to retrieve lot of rows in one call
2. Check also ‘SQL*Net roundtrips to/from client’

19.11.15
Access Path
> I/O mechanisms

> Table Access
> Index Access
> Join Methods
> Sorts and hash
> Hints

19.11.15
Index Access
Index B-Tree
An index is a sorted structure
> Quick access to a value, or a range of values
> Several levels: branches addresses lower branches of leaves
> Leaves have all entries and addresses table rows
Index is maintained
> New rows have new entries in the structure
> Leaf or branch blocks may be split when full
> When root is full, split add a new level
> Updating index value deletes the old value and adds the new one

19.11.15
Index Access
Index Clustering factor
Table access by index rowid
> Table rows coming from index entries may be scattered in the table
> Then each access is a new logical read
> If rows have been inserted from increasing values (sequence, date) they
are probably better clustered on that value
Index with Index with

good clustering Table bad clustering
001 001 B A
002 002 M B
003 A
003 C
004 004 C M
005 005 Y X
006 X
006 Y

19.11.15
Index Access
Index B-Tree (leaf split)
Table rows B-Tree index
150
100
200
300
400 100
100-200
100-200
350 250-300 200
150 300-400
350-400 300
250
100 100
250 350
300
150 200
300
150 350
400
200 200 400

19.11.15
Index Access
Index B-Tree (root split)
Table rows B-Tree index
100-220
100 250-400
200
300
400
100-150 100-200
250-300
350 250-300
150 200-220 350-400
350-400
250
220
100 100
200 250 350
150 150
220 300 400
200

19.11.15
Index Access
Index efficiency
An index is good to get few rows
> Quickly access to the values we want
> Get required columns from the index (covering index)
But
> Getting additional columns from table is expensive
> Especially when clustering factor is bad
Look at the access predicate

> Functions prevent index access (except with Function Based Index)
> Implicit conversions are like functions. See the execution plan.
> Index order is binary – not ordered for non US7ASCII character set
> Null entries are not indexed (when all columns are null)

19.11.15
Index Access
Cost of index access
Index access vs. Table full Scan
Index access Table scan
> B*Tree access:

2 or 3 blocks to
access to a entry > Full table scan:
+ one for the row Reads all blocks
efficient for lot of rows
19.11.15
Index Access
Demo: Index access
Run the following

SQL> set arraysize 5000
SQL> select /*+ gather_plan_statistics */ cust_id from CUSTOMERS where
cust_id=100;
cust_id between 100 and 1000;
cust_id between 1 and 1000 and cust_first_name='Amy';
> And get the execution plan after each one:

SQL> select * from
table(dbms_xplan.display_cursor(format=>'allstats last'));
> Replace the CUSTOMER_PK(CUST_ID) index by

CUSTOMER_DEMOINDEX(CUST_ID,CUST_FIRST_NAME)
and run the last select
Optimization is done by filtering as soon as possible.

19.11.15
Index Access
Index accesses alternatives
Hash cluster
> The rowid is derived from the value
Index Organized Tables
> Whole row is stored in the index structure
Bitmap indexes
> Single column indexes store bitmap of rowid
Storage indexes (exadata)
> Maps the blocks with their min/max values
In-Memory option
> Single column stored in memory for quick vector scan

19.11.15
Index Access
IOT and bitmap indexes
Index Organized Tables
> Whole row is stored in the index structure
> Except columns defined in overflow
> Secondary indexes are more expensive
> Use case: association table for many-to-many
Bitmap indexes
> Single column indexes store bitmap of rowid
> Cheap combination of several indexes
> But not suited for OLTP (degradation, locks)

19.11.15
Index Access
Row storage vs. Columnar storage
Row store vs Column store
> Analytic queries don’t need all columns -> column store
> DSS Data Marts have denormalized columns -> compression
> Bitmap indexes are not for OLTP
Hybrid Columnar compression
> For Oracle storage only (ZFS storage appliance, Exadata)
> Exadata can do SmartScan on it (storage index, predicate/projection
offloading, decompression)
> HCC is not for OLTP
In-Memory option
> Allows columnar optimized operations (scan & update)

19.11.15
Access Path
> I/O mechanisms

> Table Access
> Index Access
> Join Methods
> Sorts and Hash
> Hints

19.11.15
Join Methods
What is a join?
Relational database
> Stores entities in separate tables
> Tables are usually stored physically separate
> Queries require columns from several tables
> We need to join tables
Older syntax
> As if we do a Cartesian product, and then filter with predicates
select * from DEPT , EMP where DEPT.DEPTNO=EMP.DEPTNO
ANSII syntax
> Join condition is explicit
select * from DEPT join EMP on DEPT.DEPTNO=EMP.DEPTNO
> This is just syntax, Oracle will choose how to do

19.11.15
Join Methods
Nested Loop Join
EMPNO ENAME DEPTNO
#1 7369 SMITH 20 outer
#2 7499 ALLEN 30 outer DEPTNO DNAME
#3 7521 WARD 30 outer 10 ACCOUNTING

inner 20 RESEARCH
outer
#4 7566 JONES 20 inner 30 SALES
40 OPERATIONS
Nested Loop Join

> n rows from the outer table, EMPNO ENAME DNAME
access the inner table n times #1 7369 SMITH RESEARCH
> Good when having efficient access to #2 7499 ALLEN SALES
the inner table (index) and have a good #3 7521 WARD SALES
clustering factor #4 7566 JONES RESEARCH
> Bad if too many rows from outer table

19.11.15
Join Methods
Hash Join
EMPNO ENAME DEPTNO
#1 7369 SMITH 20 outer HASH

#2 7499 ALLEN 30 outer DEPTNO DNAME
#3 7521 WARD 30 outer 10 ACCOUNTING

inner 20 RESEARCH
outer
#4 7566 JONES 20 inner 30 SALES
40 OPERATIONS
Hash Join
> Builds a hash table from smaller input EMPNO ENAME DNAME
#1 7369 SMITH RESEARCH

> Longer to get the first result row
#2 7499 ALLEN SALES
> But faster access later
#3 7521 WARD SALES
> Better when smaller table fit in memory
#4 7566 JONES RESEARCH

19.11.15
Join Methods
Nested Loop execution plan (10g)
select * from DEPT join EMP using(deptno) where sal>=3000
----------------------------------------------------------------------------
| Id | Operation | Name | Starts | A-Rows | Buffers |
----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 3 | 13 |
| 1 | NESTED LOOPS | | 1 | 3 | 13 |
|* 2 | TABLE ACCESS FULL | EMP | 1 | 3 | 8 |
| 3 | TABLE ACCESS BY INDEX ROWID| DEPT | 3 | 3 | 5 |
|* 4 | INDEX UNIQUE SCAN | PK_DEPT | 3 | 3 | 2 |
----------------------------------------------------------------------------
Nested Loop
> Outer table (EMP) has 3 rows after applying the ‘sal>=3000’ predicate
> for each of them the DEPT is accessed by a rowid

19.11.15
Join Methods
Nested Loop execution plan (11g)
select * from DEPT join EMP using(deptno) where sal>=3000
----------------------------------------------------------------------------
| Id | Operation | Name | Starts | A-Rows | Buffers |
----------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 3 | 13 |
| 1 | NESTED LOOPS | | 1 | 3 | 13 |
| 2 | NESTED LOOPS | | 1 | 3 | 10 |
|* 3 | TABLE ACCESS FULL | EMP | 1 | 3 | 8 |
|* 4 | INDEX UNIQUE SCAN | PK_DEPT | 3 | 3 | 2 |
| 5 | TABLE ACCESS BY INDEX ROWID| DEPT | 3 | 3 | 3 |
----------------------------------------------------------------------------
Join Batching
> A first loop retrieves a vector of rowid
> A second loop retrieves the rows by batch

19.11.15
Join Methods
Hash Join
select * from DEPT join EMP using(deptno)
-----------------------------------------------------------------------
| Id | Operation | Name | Starts | A-Rows | Buffers | OMem |
-----------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 14 | 15 | |
|* 1 | HASH JOIN | | 1 | 14 | 15 | 1321K|
| 2 | TABLE ACCESS FULL| DEPT | 1 | 4 | 7 | |
| 3 | TABLE ACCESS FULL| EMP | 1 | 14 | 8 | |
-----------------------------------------------------------------------
Hash Join
> Builds a hash table with the inner row source
> Probes it from the outer row source
The order of tables can be swapped
> The smaller one is chosen to be the hash table

19.11.15
Join Methods
Demo
Check number of lines from SALES and CUSTOMERS
SQL> connect demo/demo
SQL> select table_name,num_rows,blocks from user_tables
where table_name in('SALES','CUSTOMERS');
Run a join with different number of rows

SQL> select
count(*),min(cust_year_of_birth),max(cust_year_of_birth)
from SALES join CUSTOMERS using(cust_id)
where amount>10;
SQL> select
count(*),min(cust_year_of_birth),max(cust_year_of_birth)
from SALES join CUSTOMERS using(cust_id)
where prod_id=20 and quantity>1;

19.11.15
Join Methods
Adaptive Plans (1)
The execution plan contains two different paths
> Oracle evaluates an inflection point and will choose during the execution
> New operation statistics collector will buffer rows during table scan
Nested
Hash Join
Loop
Stats collector
Table scan Index scan Table scan
TABLE 1 TABLE 2

19.11.15
Join Methods
Adaptive Plans (2)
If the number of rows is less than the inflection point
> Oracle executes the default plan
> All needed rows have been read and they are sent to the next operation
Nested
Hash Join
Loop
Stats collector
TABLE 1 TABLE 2

19.11.15
Join Methods
Adaptive Plans (3)
If the number of rows is bigger than an inflection point
> Oracle switches to the alternative plan
> Statistics collector is disabled and rows are sent to the next operation
Nested
Hash Join
Loop
Stats collector
TABLE 1 TABLE 2

19.11.15
Join Methods
Adaptive Plans
Plan is adaptive only on first execution
Two adaptive methods
> Join method
> Parallel distribution
> Bitmap pruning (start transformation)
New information with dbms_xplan package
> Display a note when execution plan is adaptive
Note
-----
- this is an adaptive plan
New option to display adaptive steps in execution plans

SQL> select * from table (
dbms_xplan.display(format=>'LAST ADAPTIVE'));

19.11.15
Join Methods
Demo: Adaptive Plans
Objective
> Display the default execution plan
> Display full execution plan including adaptive steps
> Execute the statement
> Display the executed execution plan
Statement used for the exercise

> Schema HR
SQL> select distinct DEPARTMENT_NAME from DEPARTMENTS
join EMPLOYEES using(DEPARTMENT_ID)
where LOCATION_ID like '%0' and SALARY>2000;
> A lot of location id end with ‘0’ but the optimizer is not aware of it.

19.11.15
Access Path
> I/O mechanisms

> Table Access
> Index Access
> Join Methods
> Sorts and Hash
> Hints

19.11.15
Sorts and Hash
Workarea for ORDER BY, GROUP BY and Hash Joins
Some operations need to buffer data
> Sort rows (ORDER BY, Index creation)
> Deduplicate rows (DISTINCT)
> Build hash tables (HASH JOIN)
> The memory is private to the process: PGA

> When larger than memory swap to tempfiles
workarea_size_policy=auto
> The workarea will be allocated, trying keep the sum of all workareas
around pga_aggregate_target
> Limited by internal values (pga limited to 200MB per process)
workarea_size_policy=manual
> The workarea is defined by sort_area_size, hash_area_size

19.11.15
Sorts and Hash
Workarea (optimal)
106 106 101

107 107 106
101 101 107
108 buffer 108 sort 108
When all the rows (workarea) fit in memory (PGA)

> They are sorted in memory only (optimal)
If they do not fit:
> Buffers will be stored in tempfiles, then chunks are merged (onepass)
Merge itself needs space, if not enough memory:
> The merge put new (larger) chunks in tempfile (multipass)

19.11.15
Sorts and Hash
Workarea (one-pass)
106 100
106 101 101 101
107 107 106 102
101 102
101 107 100
108 Sort to tempfile 102
buffer 108 108 102 sort
104 103
104 102 104
104 106
104 104 104
105 104
105 104 106
102 buffer Sort to tempfile 104
102 105 sort
107 103
100 107 100
100 107
103
103
buffer 103 Sort to tempfile 103
107
109
109 109
108
102 108 102
102 108
buffer Sort to tempfile

19.11.15
Sorts and Hash
Workarea (multi-pass) 103
100
101
2nd pass 104 102
104 102
101 sort
106
Sort to tempfile 106 103
106
107 … 103
107
sort
101 108 103
108 1st pass 104
102
104 Sort to tempfile 106 sort 104
104
104 104 103 105
104
105 104 105 105
105 sort
102 103 104 105
107 100 106
107
103 103 …
100 107
103
104 105 107
103
109 104 Sort to tempfile 108
109
102 … 108
108
102 108
103 109
103 105
105 108
The merge put new (larger) chunks in tempfile which are merged again
To be avoided (set larger PGA target)

19.11.15
Sorts and Hash
How to estimate the size?
Explain Plan show the estimated workarea usage:
SQL> explain plan for select * from demo.test order by a;
SQL> select * from table(dbms_xplan.display);
-----------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc|
-----------------------------------------------------------
| 0 | SELECT STATEMENT | | 1000 | 3907K| |
| 1 | SORT ORDER BY | | 1000 | 3907K| 4008K|
| 2 | TABLE ACCESS FULL| TEST | 1000 | 3907K| |
-----------------------------------------------------------
Frequent small sorts/hash

> Should be optimal
Large sorts/hash
> Can be done in 1 pass (batch, reporting)
> Multipass or high tempfile usage is probably sign of poor execution plan
> Think about partitioning, parallel query, manual sort_area_size

19.11.15
Sorts and Hash
How to view the size?
For current execution:
> V$SQL_WORKAREA_ACTIVE
For recent execution:
> dbms_xplan.display_cursor(format=>’memstat last’)
---------------------------------------
| OMem | 1Mem | Used-Mem | Used-Tmp|
---------------------------------------
| | | | |
| 4500K| 893K| 509K (1)| 4096 |
| | | | |
---------------------------------------
Note that Used-Tmp is in KB instead of bytes (bug – not fixed yet)

For past execution, or for failed statements:
> SQL Monitoring or ASH (TEMP_SPACE_ALLOCATED)

19.11.15
Sorts and Hash
Workarea size recommendation
Recommended value
> Workarea_policy=auto at system level
> Good for OLTP
> Still good for large volume if Parallel Query is used
Workarea_policy=manual
> When we can allocate 1 our 2 GB
> At session level only, and controlling the total number of session
> Set sort_area_size and hash_area_size as needed
Always be sure that enough physical RAM is available

19.11.15
Access Path
> I/O mechanisms

> Table Access
> Index Access
> Join Methods
> Sorts and Hash
> Hints

19.11.15
Hints
Why do we need hints?
SQL is a declarative language
> We specify only WHAT we want, not the way to do it
> The optimizer chooses HOW to get it
Hints are specified as special comments /*+ */
> Specify a special behavior ( APPEND, PARALLEL )
> Specify additional behavior ( RESULT_CACHE, MONITOR )
> Change parameters at query level ( FIRST_ROWS, DYNAMIC_SAMPLING )
> Test a different execution plan ( joins, access, transformations )
> Least resort to workaround a bad CBO choice
Hint behavior change through versions:

Document then, re-evaluate them at each upgrade

19.11.15
Hints
Few important hints
FIRST_ROWS(n)
> Optimize to get first rows quickly (pagination)
often favors nested loops and index access
RESULT_CACHE
> Enables result caching at statement level
APPEND
> Inserts after High Water Mark
direct path, don’t reuse free space, locks the table
DRIVING_SITE
> Determines where the joins are done when involving db links
When DML, the driving site is always where the DML is done

19.11.15
Hints
Demo: Hinting Joins
1. Run the following
SQL> connect / as sysdba
SQL> alter session set current_schema=SCOTT
statistics_level=all;
SQL> select *
from dept join emp using(deptno) join bonus using(ename);
> What are the join method chosen?
2. Add hints to the query in order to get

1. Full scan EMP
2. For each employee, get the DEPT by index
3. For each employee get to the BONUS by hash
Solution: the plan hash value should be 135669890
3. Show all the hints with ‘+outline’ format

19.11.15
Access Path
Core Message
The optimizer chooses the access path
> But we have to provide the right structures, and accurate statistics
> Hints are not a long-term solution and must be documented
A bad join can change the response time to 1000x

> Adaptive join helps, but doesn’t solve all issues
Indexing must be done at design time

> Too many indexes is overhead for inserts, updates, deletes
> Too few probably miss some efficient access path for queries

19.11.15
Oracle Performance Tuning – Monitoring Performance

Agenda
1. Introduction
3. Access Path
5. Conclusion
Oracle Performance Tuning – Monitoring Performance Page 2

19.11.15
Monitoring Performance
> Database Time

> Application instrumentation
> dbms_xplan
> SQL Monitoring
> Statspack
> AWR, ASH, ADDM
> SQL Trace, tkprof

19.11.15
Database Time
User calls
The databases serves user calls
> SQL or PL/SQL parsing
> SQL, PL/SQL, Java,… execution
> SQL fetch,...
The database user is:
> A real user in Client/Server (e.g sqlplus)
> An application server (e.g. one connection from connection pool)
User Database
execute() SQL*Net message from client
DB Time
cursor
SQL*Net message from client

19.11.15
Database Time
Timed foreground event
The databases uses server resources
> CPU (running or waiting in runqueue)
> System calls (network, i/o, timers)
The databases measures time
> CPU Time: time running in CPU (not including waiting)
> Wait Events: system calls (including CPU runqueue when CPU is busy )
Database OS storage
io_call()
db file sequential read
block
DB Time

19.11.15
Database Time
DB time
Measures the response time
> Detailed in Time Model
Measures resource consumption
> DB Time = CPU + Wait Events + (some wait in runqueue)
User Database OS storage

execute() SQL*Net message from client
io_call()
db file sequential read

DB Time DB Time
block
cursor
SQL*Net message from client

19.11.15
Database Time
Average Active Session
During 1 hour of elapsed time
> One user can use 1 hour of DB Time
> N users can use N hours of DB Time
> The average active session is DB Time / elapsed time
Snap Id Snap Time Sessions Curs/Sess
--------- ------------------- -------- ---------
Begin Snap: 330 11-Mar-14 15:18:53 40 5.4
End Snap: 336 11-Mar-14 15:34:32 55 4.7
Elapsed: 15.64 (mins)
DB Time: 76.48 (mins)
Database load= 76.48 / 15.64 = 4.9 Average Active Session
It’s an average and can mean: 5 users 99% busy
or 10 users half idle or …

19.11.15
Database Time
Statistics and Wait Events
Oracle gathers statistics about:
> Time spent in user calls (v$sess_time_model)
> Time spent in system calls (v$session_wait)
> Time running in CPU (as reported by the OS)
> Various non-time statistics about the activity
Most statistics are cumulative

> From instance startup
> Exposed in V$ views
> Regular snapshots historized (AWR or Statspack)
> We analyze the delta between two snapshots

19.11.15
Database Time
DB CPU
DB CPU
> Is the time spend in CPU
> Waiting in runqueue is not accounted here
Facts to know
> Everything needs CPU: you will always have CPU consumption
> One session cannot use more than one CPU (except parallel query)
Main responsible of CPU consumption

> Parsing: should be avoided (bind variables)
> Sorting: can be tuned (workarea size)
> Block reads: lowering the logical reads will decrease CPU usage

19.11.15
Database Time
User I/O
User I/O
> db file sequential read: read one block to buffer cache
(typical of index access)
> db file squattered read: read multiple contiguous blocks to buffer cache
(typical of full table scan)
> db file direct path read: read contiguous blocks directly to PGA
(full table scan of very large tables)
Average time should be know

> Example: 4ms for 15000 RPM, 0.1ms for SSD

19.11.15
Database Time
CPU runqueue
When there are more processes running than available CPU,
the system schedules CPU resource sharing:
Process 1 Process 3 Process 1 Process 3

Process 4 Process 2 Process 4
> During the 6 time unit call

> Process 2 CPU Time = 4 (runqueue not accounted)

19.11.15
Database Time
CPU runqueue
When in runqueue after a system call (wait event)

Process 4 Process 2
Process 2
> During the 8 time unit call

> Process 2 CPU Time = 4
> Process 2 I/O Time = 4 (wait event inflated by runqueue)

19.11.15
Database Time
Host CPU
CPU utilization %
> Is calculated on threads
> You cannot run at 100%
An example of 75% idle system:

> IBM Power 7 with 4-way SMT
> 5 cores - 20 ‘CPU’
> With load average of 10 all cores are overloaded despites the ‘75%’ idle

19.11.15
Database Time
Host CPU
Before tuning DB Time, check there is no CPU contention:
> Check that DB Time = DB CPU + sum (wait events)

> Check host CPU
> Compare load average to number of cores

19.11.15
> Database Time

> dbms_xplan
> SQL Monitoring
> Statspack
> AWR, ASH, ADDM
> SQL Trace, tkprof

19.11.15
Application instrumentation
Why?
Identify who, what, which, and how
> Who is the end-user even if we use connection pool: CLIENT_ID
> What program: MODULE
> Which par of code: ACTION
> How it has been run: CLIENT_INFORMATION
Because:
> We want to debug, trace, get statistics, see who is locking, etc.
Example:
> User Smith is blocked when creating an order
> How much time is spent in the creation order
> Where is the code for that long running query

19.11.15
dbms_session and dbms_application_info
Using dbms_session package to identify client
> client_identifier
> 64 bytes to identify the final user
> Propagated through database links
Using dbms_application_info to identify tasks (e.g. New Order)
> module_name
> 48 bytes to describe a unit task. Example: the java class
> action_name
> 32 bytes to describe a task step. Example: the method
> client_info
> 64 bytes to describe the context. Example: the use case and scenario
Also available from Java easily

> Connection.setClientInfo([OCSID.CLIENTID|MODULE|ACTION],”value”)

19.11.15
dbms_session and application instrumentation
Available with SYS_CONTEXT function
SQL> select
sys_context('userenv','client_identifier') AS client_identifier,
sys_context('userenv','client_info') AS client_info,
sys_context('userenv','module') AS module_name,
sys_context('userenv','action') AS action_name
from dual;
Used/View in several places

> Performance views (V$SESSION)
> Use with dbms_monitor
> To set sql_trace for specific part of the code
> To gather some statistics for specific part of the code
It’s at a lower level than SERVICE_NAME

19.11.15
> Database Time

> dbms_xplan
> SQL Monitoring
> Statspack
> AWR, ASH, ADDM
> SQL Trace, tkprof

19.11.15
dbms_xplan
Execution plans
Reason:
> The CBO chooses the execution plan but we have to check it
> Understand bad choices (cardinality)
> Understand access path (predicates)
> Get optimizer information
dbms_xplan.display:
> Display from PLAN_TABLE (result from EXPLAIN PLAN)
dbms_xplan.display_cursor:
> Display from V$SQL_PLAN (already executed cursor child)
dbms_xplan.display_AWR:
> Display from DBA_HIST_SQL_PLAN (stored by AWR)

19.11.15
dbms_xplan
Display from PLAN_TABLE
SQL> EXPLAIN PLAN FOR

2 select job,dname,count(*) from EMP join DEPT using(deptno)
3 where deptno=:d group by job,dname;
Explained.
SQL> select * from table(dbms_xplan.display(format=>'basic +cost'));
PLAN_TABLE_OUTPUT
----------------------------------------------------------------------
Plan hash value: 3315835386
--------------------------------------------------------------
| Id | Operation | Name | Cost (%CPU)|
--------------------------------------------------------------
| 0 | SELECT STATEMENT | | 5 (20)|
| 1 | HASH GROUP BY | | 5 (20)|
| 2 | NESTED LOOPS | | 4 (0)|
| 3 | TABLE ACCESS BY INDEX ROWID| DEPT | 1 (0)|
| 4 | INDEX UNIQUE SCAN | PK_DEPT | 1 (0)|
| 5 | TABLE ACCESS FULL | EMP | 3 (0)|
--------------------------------------------------------------

19.11.15
dbms_xplan
Display from V$SQL_PLAN (+peeked_binds)
SQL> variable d number;

SQL> exec :d:=10;
PL/SQL procedure successfully completed.
SQL>
SQL> select job,dname,count(*) from EMP join DEPT using(deptno)
JOB DNAME COUNT(*)

--------- -------------- ----------
MANAGER ACCOUNTING 1
PRESIDENT ACCOUNTING 1
CLERK ACCOUNTING 1
SQL> select * from table(

2 dbms_xplan.display_cursor(format=>'basic +peeked_binds')
3 );
By default takes the latest executed cursor from the session

serveroutput must be off or the last statement is wrong

19.11.15
dbms_xplan
Display from V$SQL_PLAN (+peeked_binds)
EXPLAINED SQL STATEMENT:

------------------------
select job,dname,count(*) from EMP join DEPT using(deptno) where
deptno=:d group by job,dname
-------------------------------------------------
| Id | Operation | Name |
-------------------------------------------------
| 0 | SELECT STATEMENT | |
| 1 | HASH GROUP BY | |
| 2 | NESTED LOOPS | |
| 3 | TABLE ACCESS BY INDEX ROWID| DEPT |
| 4 | INDEX UNIQUE SCAN | PK_DEPT |
| 5 | TABLE ACCESS FULL | EMP |
-------------------------------------------------
Peeked Binds (identified by position):

--------------------------------------
1 - :D (NUMBER): 10

19.11.15
dbms_xplan
Display from V$SQL_PLAN (allstats)
SQL> alter session set statistics_level=all;
Session altered.
SQL> select job,dname,count(*) from EMP join DEPT using(deptno)

JOB DNAME COUNT(*)

--------- -------------- ----------
MANAGER ACCOUNTING 1
PRESIDENT ACCOUNTING 1
CLERK ACCOUNTING 1
SQL> select * from table(

2 dbms_xplan.display_cursor(format=>'basic iostats last')
3 );
Need to set statistics_level to all or use gather_plan_statistics

19.11.15
dbms_xplan
Display from V$SQL_PLAN (allstats)
SQL_ID c00n45rgsa03h, child number 1

-------------------------------------
select job,dname,count(*) from EMP join DEPT using(deptno) where
deptno=:d group by job,dname

-----------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
-----------------------------------------------------------------------------------
| 0 | SELECT STATEME| | 1 | | 3 |00:00:00.01 | 9 |
| 1 | HASH GROUP BY| | 1 | 3 | 3 |00:00:00.01 | 9 |
| 2 | NESTED LOOPS| | 1 | 3 | 3 |00:00:00.01 | 9 |
| 3 | TABLE ACCES| DEPT | 1 | 1 | 1 |00:00:00.01 | 2 |
|* 4 | INDEX UNIQ| PK_DEPT | 1 | 1 | 1 |00:00:00.01 | 1 |
|* 5 | TABLE ACCES| EMP | 1 | 3 | 3 |00:00:00.01 | 7 |
-----------------------------------------------------------------------------------
Predicate Information (identified by operation id):

---------------------------------------------------
4 - access("DEPT"."DEPTNO"=:D)
5 - filter("EMP"."DEPTNO"=:D)
Note
Oracle Performance Tuning – Monitoring Performance
----- Page 25
19.11.15
- dynamic statistics used: dynamic sampling (level=2)
dbms_xplan
How to read an execution plan?
--------------------------------------------------------------
| Id | Operation | Name | Cost (%CPU)|
--------------------------------------------------------------
| 0 | SELECT STATEMENT | | 5 (20)|
| 1 | HASH GROUP BY | | 5 (20)|
| 2 | NESTED LOOPS | | 4 (0)|
| 3 | TABLE ACCESS BY INDEX ROWID| DEPT | 1 (0)|
| 4 | INDEX UNIQUE SCAN | PK_DEPT | 1 (0)|
| 5 | TABLE ACCESS FULL | EMP | 3 (0)|
--------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("DEPT"."DEPTNO"=:D)
5 - filter("EMP"."DEPTNO"=:D)
> Start with the first operation at the deepest level

> Send resulted rows to the parent
> Process next child (NESTED LOOP: for each row for 1st execute the 2nd)
> Send rows to the parent
> Continue (NESTED LOOP)
> Send rows to the parent (GROUP BY is a blocking operation)

19.11.15
> Database Time

> dbms_xplan
> SQL Monitoring
> Statspack
> AWR, ASH, ADDM
> SQL Trace, tkprof

19.11.15
SQL Monitoring
Real-Time monitoring
SQL Monitoring is triggered for:

> All parallel queries
> Statements with more than a few seconds DB Time
> /*+ MONITOR */ hint
> It’s real-time, even if the SQL is running or failed
> Based on V$SQL_PLAN_STATISTICS + ASH
> Works for failed statements
> Easy with parallel query as well
> Integrated with EM or standalone
set pagesize 0 linesize 10000 trimspool on serveroutput off long 10000000

longc 10000000 echo off feedback off
alter session set events='emx_control compress_xml=none';
spool plan.htm
select dbms_sqltune.report_sql_monitor(report_level=>'all',type=>'active')
from dual;
spool off

19.11.15
SQL Monitoring
Example: Nested Loop

19.11.15
SQL Monitoring
Overview:
> Most of the time is I/O
> We need to improve the part of the plan that is doing lot of I/O

19.11.15
SQL Monitoring
3. Lot of
2. Nested executions
Loops
4. I/O waits
1. Root cause:
Cardinality under estimated
19.11.15
SQL Monitoring
It’s long because:

> An operation response time is too high or
> A short operation is called too many times
SQL Monitoring shows:

> Each operation with it’s time (samples) and number of calls (executions)
> Even when it is running
> Without any overhead
> Can be saved to interactive html
Requires Diagnostics + Tuning Pack

> Without it, need to use dbms_xplan.display_cursor with
statistics_level=all

19.11.15
> Database Time

> dbms_xplan
> SQL Monitoring
> Statspack
> AWR, ASH, ADDM
> SQL Trace, tkprof

19.11.15
Statspack
Installation
Statspack is free of use – even on Standard Edition
Install :
SQL> @?/rdbms/admin/spcreate
> Documented in $ORACLE_HOME/rdbms/admin/spdoc.txt

> Can be installed in SYSAUX but better to
create a STATSPACK tablespace (2GB) in case the purge is failing.
> We like to have no gap for snap_id:

SQL> ALTER SEQUENCE stats$snapshot_id NOCACHE;
> And gather segment statistics as well:

SQL> exec STATSPACK.MODIFY_STATSPACK_PARAMETER (i_snap_level=>7,
i_instance_number=>null);
(In RAC, must be run in each instance, with the right instance_number)

19.11.15
Statspack
Scheduling
Schedule :
> The spauto.sql doesn’t schedule purges, and is not RAC aware
dbi services recommends, for each instance, connected as perfstat:
variable jobno number
variable instno number
begin
select instance_number into :instno from v$instance;
dbms_job.submit(:jobno, 'statspack.snap;', trunc(sysdate+1/24,'HH'),
'trunc(SYSDATE+1/24,''HH'')', TRUE, :instno);
dbms_job.submit(:jobno,
'statspack.purge(i_num_days=>45,i_extended_purge=>true);',
trunc(SYSDATE)+7, 'trunc(SYSDATE)+7', TRUE, :instno);
commit;
end;
/
select last_sec,next_date,next_sec,log_user,what from dba_jobs;
> (for each instance when in RAC)

19.11.15
Statspack
Statspack reports
Run spreport
SQL> @ ?/rdbms/admin/spreport
> Select the snap id

Snap
Instance DB Name Snap Id Snap Started Level Comment
------------ ------------ --------- ----------------- ----- ----------
DB1 DB1 1 07 Nov 2014 14:16 7
2 07 Nov 2014 14:19 7
Specify the Begin and End Snapshot Ids

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for begin_snap: 1
Begin Snapshot Id specified: 1
Enter value for end_snap: 2

End Snapshot Id specified: 2
> View the report

19.11.15
Statspack
Statspack vs AWR
Reports:
> Statspack reports is only text (AWR has html)
> Statspack has no GUI (EM shows only AWR) and no ASH
> Need to use third party tools:
> www.orachrome.com
> www.lab128.com
> etc.
19.11.15
> Database Time

> dbms_xplan
> SQL Monitoring
> Statspack
> AWR, ASH, ADDM
> SQL Trace, tkprof

19.11.15
AWR, ASH, ADDM
Automatic Workload Repository
AWR – Automatic Workload Repository
> First introduced with Oracle 10g
> Statistics accumulated in memory saved as snapshots in the AWR
> Provides long term record of database state
> Depends of STATISTICS_LEVEL instance parameter (≠ BASIC)
> Requires Diagnostics Pack
Set of tables and objects

> Stored in SYSAUX tablespace, in SYS schema
Access through Enterprise Manager
> Database control or Grid control
> But also text and html reports
> And queries on DBA_HIST_ views

19.11.15
AWR, ASH, ADDM
Create and configure AWR snapshots
Snapshots generated by MMON process
> On DBA demand
> Automatically every 60 minutes. Default retention of 8 days
SQL> Select extract( day from snap_interval) *24*60
+ extract( hour from snap_interval) * 60
+ extract( minute from snap_interval ) "Snapshot Interval (Min.)",
extract( day from retention) *24*60
+ extract( hour from retention) *60
+ extract( minute from retention ) "Retention (Min)"
from dba_hist_wr_control
Snapshot Interval (Min.) Retention (Min)

------------------------ ---------------
60 11520

19.11.15
AWR, ASH, ADDM
Generate an AWR report
Create an AWR report with awrrpt.sql
SQL> @?/rdbms/admin/awrrpt.sql
…
Specify the Report Type
~~~~~~~~~~~~~~~~~~~~~~~
AWR reports can be generated in the following formats. Please enter
the
name of the format at the prompt. Default value is 'html'.
'html' HTML format (default)

'text' Text format
'active-html' Includes Performance Hub active report
…
Specify the Begin and End Snapshot Ids
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Enter value for begin_snap:
Enter value for end_snap:
…

19.11.15
AWR, ASH, ADDM
Read an AWR report
First sections
> Check report duration (must not be too long)
> Check database load (must match the user activity)
Time Model
> Check user calls
Check OS CPU utilization
> Don’t count SMT or Hyper Threading as doubling core power
Foreground Timed Events
> Check most relevant ones
> A database should do CPU and I/O
> Check averages, and go to relevant sections

19.11.15
AWR, ASH, ADDM
ASH: Sampling approach
V$SESSION has more and more information
> About user, statement, wait event, user call
> ASH samples V$SESSION every 1 second for active foreground sessions
available in V$ACTIVE_SESSION_HISTORY
AWR
> Stores 1 sample every 10 in DBA_HIST_ACTIVE_SESS_HISTORY
Usage
> When Diagnostics Pack is licensed
> When investigating short issues (few seconds to few minutes)
> Easy to make load graphs (one row per sample / active session)

19.11.15
AWR, ASH, ADDM
ADDM: Automatic analysis
ADDM analyses two snapshots and gives
> findings
> recommendations
FINDING 1: 31% impact (7798 seconds)

------------------------------------
SQL statements were not shared due to the usage of literals. This
resulted in additional hard parses which were consuming significant
database time.
RECOMMENDATION 1: Application Analysis, 31% benefit (7798 seconds)

ACTION: Investigate application logic for possible use of bind
variables
instead of literals. Alternatively, you may set the parameter
"cursor_sharing" to "force".
RATIONALE: SQL statements with PLAN_HASH_VALUE 3106087033 were found
to be
using literals. Look in V$SQL for examples of such SQL statements.

19.11.15
AWR, ASH, ADDM
Demo
Start EM Express
> Check the port
SQL> select dbms_xdb_config.gethttpsport() from dual;
> Connect to https://192.168.22.10x:5501/em

Run some activity
/home/oracle/swingbench/bin/charbench -cs //192.168.22.10x:1521/APP -u
soe -p soe -uc 10 -min 5 -max 50 -a -v -rt 00:05
> See performance tabs

Take an AWR snapshot
> And run a report
SQL> exec dbms_workload_repository.create_snapshot;
SQL> start ?/rdbms/admin/awrrpt

19.11.15
> Database Time

> dbms_xplan
> SQL Monitoring
> Statspack
> AWR, ASH, ADDM
> SQL Trace, tkprof

19.11.15
SQL Trace, tkprof
Create tracefile using oradebug
Session information
select s.username,p.spid,s.program,s.terminal
from v$session s, v$process p
where s.username ='<username>'
and s.paddr=p.addr and lower(s.program) like '%sqlplus%'
/
USERNAME SPID PROGRAM
----------------------------- -------- --------
<username> 5296268 sqlplus@srvdbitest1
Enable trace mode for this session

SQL> oradebug setospid 5296268
SQL> oradebug event 10046 trace name context forever, level 12
Disable trace mode for this session
SQL> oradebug event 10046 trace name context off
Find out where the tracefile is located

SQL> oradebug TRACEFILE_NAME
/u01/app/oracle/diag/rdbms/testdb/TESTDB/trace/TESTDB1_ora_5296268.trc

19.11.15
SQL Trace, tkprof
Create tracefile using dbms_system.set_ev
How retrieve session information
select username,sid,serial#,program
from v$session
where username='<Username>' and lower(program) like '%sqlplus%'
USERNAME SID SERIAL# PROGRAM

------------ ------ ---------- -------------- ----------------
<Username> 187 46136 extract@chbsslargus01(TNS V1-V3
<Username> 213 56816 sqlplus@<Hostname>(TNS V1-V3
Enable trace mode for this session

SQL> EXECUTE dbms_system.set_ev(213,56816,10046,12, '');
Disable trace mode for this session

SQL> EXECUTE dbms_system.set_ev(213,56816,10046,0,'');
Tracefile location
with 10g:${ORA_ADMIN_SID}/udump
with 11g:_${ORACLE_DIAG}/diag/rdbms/…/<SID>/trace/<SID>_ora_<ID>.trc

19.11.15
SQL Trace, tkprof
Format tracefile using TKPROF
Tkprof allow us to read a tracefile into an human readable format
$ tkprof trace_file.trc formated_file.tkprof [options]
Most important tkprof options parameters

> SORT
> Allowing sorting the tkprof file content using many criteria
> To sort by elapsed time sort=prsela,exeela,fchela
> SYS
> Enables or disables the SYS executed statements
> In some situation it can be interesting to activate it, but mostly of the
time we use sys=no
> EXPLAIN
> Execute the explain plan for specified user
> Can also be used in some case if plan is not displayed
explain=user/passwd

19.11.15
SQL Trace, tkprof
Example of tkprof output
$ tkprof tracefile.trc output.tkprof sort=prsela,exeela,fchela sys=no
$ tail output.tkprof
SELECT emp.ename, dept.dname

FROM emp, dept
WHERE emp.deptno = dept.deptno
call count cpu elapsed disk query current rows

------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.11 0.13 2 0 1 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 1 0.00 0.00 2 2 4 14
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 3 0.11 0.13 4 2 5 14
Misses in library cache during parse: 1

Optimizer goal: ALL_ROWS
Rows Execution Plan
------- ---------------------------------------------------
0 SELECT STATEMENT GOAL: CHOOSE
14 MERGE JOIN
4 SORT (JOIN)
4 TABLE ACCESS (FULL) OF 'DEPT'
14 SORT (JOIN)
14 TABLE ACCESS (FULL) OF 'EMP'

19.11.15
SQL Trace, tkprof
Demo: Trace service and module
Start trace for service APP and module ‘New Order’
SQL> exec
sys.dbms_monitor.serv_mod_act_trace_enable(service_name=>'APP',module_
name =>'New Order',waits=>TRUE);
Run some activity

/home/oracle/swingbench/bin/charbench -cs //192.168.22.10x:1521/APP -u
soe -p soe -uc 10 -min 5 -max 50 -a -v -rt 00:01
Stop trace
SQL> exec
sys.dbms_monitor.serv_mod_act_trace_disable(service_name=>'APP',module
_name =>'New Order')
SQL> select * from v$diag_info where name='Diag Trace';
Go to trace directory and use tkprof on one .trc

> You can also group several .trc with trcsess
trcsess service=APP module="New Order" $(find -name "DB1_ora_*.trc" -
ctime -1) > ALL.TRC
tkprof ALL.TRC ALL.TXT sort='(exeela,fchela)'

19.11.15
Monitoring performance
Core Message
Oracle is very well instrumented
> Tune from DB Time down to more detail
> Focus only on what can improve performance significantly
> Add your own information (action/module/client_info)
AWR / Statspack
> If you don’t have Diagnostics Pack install Statspack
> It’s mandatory to analyze what happened in the past
Understand and test
> Check execution plan cardinality estimations
> Try other plans to see where the problem is

19.11.15
Oracle Performance Tuning – Conclusion

Agenda
1. Introduction
3. Access Path
5. Conclusion
Oracle Performance Tuning – Conclusion Page 2

19.11.15
Conclusion
Methodology
We talked a lot about
> Execution plans
> DB time
What about
> Ratios?
> Rules of thumbs?
> Silver bullets?

19.11.15
Methodology
Danger of ratios
Do you remember tuning by ratios in 90’s?
> Run the following
SQL> declare
x char;
begin
loop
select dummy into x from dual;
end loop;
end;
SQL> /
Instance Efficiency Percentages (Target 100%)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Buffer Nowait %: 100.00 Redo NoWait %: 100.00
Buffer Hit %: 100.00 In-memory Sort %: 100.00
Library Hit %: 99.93 Soft Parse %: 79.24
Execute to Parse %: 99.90 Latch Hit %: 100.00
Parse CPU to Parse Elapsd %: 22.22 % Non-Parse CPU: 99.94
> Is this good ? Good ratios for unnecessary work…

19.11.15
Methodology
Danger of averages
All have the same average

Which one is better?

19.11.15
Methodology
Why we use the DB Time approach?
Your goal is to
> Reduce response time?
> Increase throughput?
> Achieve better scalability?
> Reduce resource consumption?
Then your goal is to

> Reduce DB Time
And you can quantify the gain

> Before implementation (expectation)
> After implementation (verification)

19.11.15
Methodology
Why we use the DB Time approach?
With DB time you set a tuning goal
> Know what you want to tune
> Know where to stop
Don’t do the following without a reason for it:

> Rebuild indexes
> Reorganize tables
> Prevent all full table scan
> Implement SQL Profile
> Set instance parameters with arbitrary values
> Use deprecated features, disable new features
> Change block size
> Add CPU

19.11.15
Methodology
Which features to use?
You don’t have to
> Create all kind of table and index types
> Define each instance parameter
But you have to know them

> Know the available table/index types and how they access data
> Know what can be configured at instance/session/query level
Your knowledge is strengthen by

> Documentation
> Tests on small testcase
> Experience (but experience is linked to one version and one application)

19.11.15
Documentation
In 12c: split in 2 books
Performance Tuning guide

> Methodology, System resources, …
SQL tuning Guide
> Optimizer, Access path, …
Oracle Database Concepts

> Describes Oracle Database architecture
Oracle Database VLDB and Partitioning guide
> Describes partitioning and parallel execution
Oracle Database Reference
> Parameters, dictionary views, wait events and statistics

19.11.15
Design for performance
Don’t wait for the application to be in production

> Think about design
> Check execution plans
> Have relevant test/qualification database
But don’t tune everything
> Need to know the critical use-cases
Project management must equilibrate
> Generic code for better code maintenance
> Specific code for performance critical cases
Hardware cannot solve performance issues

> It just lowers their consequences in short term

19.11.15
References
To go further
dbi services
> Workshops http://www.dbi-services.com/trainings
> Blogs http://blog.dbi-services.com
> Articles
major books:
> Jonathan Lewis - Cost Base Oracle Fundamentals
> Chris Antognini - Troubleshooting Oracle Performance
> Markus Winand - SQL Explained
Learn and practice before you need it

19.11.15

2015-K-Db-Herv Schweitzer-Oracle Database Perfomance Tuning - Wie Angehen Fa Dbi Services - Praesentation

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

2015-K-Db-Herv Schweitzer-Oracle Database Perfomance Tuning - Wie Angehen Fa Dbi Services - Praesentation

Uploaded by

Copyright:

Available Formats

Infrastructure at your Service.

Oracle Perfomance Tuning Workshop

Oracle Performance Tuning

Your workshop instructor

Mobile +41 79 963 43 67

Oracle Performance Tuning Page 2

Your workshop instructor

Mobile +41 79 835 02 95

Oracle Performance Tuning Page 3

09:00 – 10:30 : Workshop part 1

12h15 – 13h30 : Lunch

13:30 – 15:00 : Workshop part 3

Oracle Performance Tuning Page 4

dbi services is hiring in Basel & Zürich (career@dbi-services.com)

Oracle Performance Tuning Page 5

Oracle Performance Tuning Page 6

Oracle Performance Tuning Page 7

Oracle Performance Tuning Page 8

Oracle Performance Tuning Page 9

Oracle Performance Tuning Workshop

Oracle Performance Tuning – Introduction

Oracle Performance Tuning – Introduction Page 2

> Performance requirements should be defined with percentiles

How the end-user feels the performance

Oracle Performance Tuning – Introduction Page 3

The user will probably not call you

It’s always a good idea to meet the end user

Oracle Performance Tuning – Introduction Page 4

Oracle Performance Tuning – Introduction Page 5

You can improve throughput

> But response time increases PROC PROC PROC

Oracle Performance Tuning – Introduction Page 6

Tuning only from system is very limited

When an operation is slow

The major potential improvement is from design

Oracle Performance Tuning – Introduction Page 7

Understand how it works

Oracle Performance Tuning – Introduction Page 8

Oracle Performance Tuning – Introduction Page 9

Oracle Performance Tuning Workshop

Oracle Performance Tuning – Cost Based Optimizer

Oracle Performance Tuning – Cost Based Optimizer Page 2

> Optimizer overview

Oracle Performance Tuning – Cost Based Optimizer Page 3

There are several ways to retrieve data (access path)

Oracle Performance Tuning – Cost Based Optimizer Page 4

Two main versions

Cost Based Optimizer (CBO)

Oracle Performance Tuning – Cost Based Optimizer Page 5

> Heuristic based optimizer > Evaluates different access paths

Oracle Performance Tuning – Cost Based Optimizer Page 7

> The cost is an estimation used by the optimizer.

Oracle Performance Tuning – Cost Based Optimizer Page 8

Oracle Performance Tuning – Cost Based Optimizer Page 9

Two available ways

dbi services recommends to keep the default value at instance level:

Oracle Performance Tuning – Cost Based Optimizer Page 10

It’s not advised to change parameters

Some parameters can be pushed using hint if really needed

Oracle Performance Tuning – Cost Based Optimizer Page 11

> Optimizer overview

Oracle Performance Tuning – Cost Based Optimizer Page 12