Understanding Query Optimization with ‘regular’ and ‘Exadata’ Oracle

Copyright © 2012, Oracle and/or its affiliates. All rights
reserved.
Understanding Query Optimization
with ‘regular’ and ‘Exadata’ Oracle
Thomas Kyte
http://asktom.oracle.com/

reserved.
Statement Processing and the Optimizer
What Happens when a SQL statement is issued?
User
Library Cache
Shared SQL Area
Shared Pool
CnC1 C2 …
3
Cost Estimator
Query Transformation
Plan Generator
Optimizer
Oracle Database
1
Syntax Check
Semantic Check
Shared Pool check
2
Parsing
4
SQL Execution
Code Generator Decision on what processing is
offloaded occurs here

<Insert Picture Here>
What is an execution
plan and how to
generate one

What is an Execution plan?
• Execution plans show the detailed steps necessary to
execute a SQL statement
• These steps are expressed as a set of database
operators that consumes and produces rows
• The order of the operators and their implementation is
decided by the optimizer using a combination of query
transformations and physical optimization techniques
• The display is commonly shown in a tabular format,
but a plan is in fact tree-shaped

Group By
HASH JOIN
TABLE ACCESS
SALES
TABLE ACCESS
PRODUCTS
What is an Execution plan?
Query
SELECT prod_category, avg(amount_sold)
FROM sales s, products p
WHERE p.prod_id = s.prod_id
GROUP BY prod_category;
Tabular representation of plan
-----------------------------------------
Id Operation Name
-----------------------------------------
0 SELECT STATEMENT
1 HASH GROUP BY
2 HASH JOIN
3 TABLE ACCESS FULL PRODUCTS
4 PARTITION RANGE ALL
5 TABLE ACCESS FULL SALES
-----------------------------------------
Tree-shaped representation of plan

How to get an Execution Plan
Two methods for looking at the execution plan
1.EXPLAIN PLAN command
• Displays an execution plan for a SQL statement without actually
executing the statement
2.V$SQL_PLAN
• A dictionary view introduced in Oracle 9i that shows the execution
plan for a SQL statement that has been compiled into a cursor in
the cursor cache
Use DBMS_XPLAN package to display plans
Under certain conditions the plan shown with EXPLAIN PLAN
can be different from the plan shown using V$SQL_PLAN

Example 1 EXPLAIN PLAN command & dbms_xplan.display function
SQL> EXPLAIN PLAN FOR SELECT prod_category, avg(amount_sold)
Explained
SQL> SELECT plan_table_output
FROM table(dbms_xplan.display('plan_table',null,'basic'));
------------------------------------------
Id Operation Name
------------------------------------------
0 SELECT STATEMENT
1 HASH GROUP BY
2 HASH JOIN
-------------------------------------------

Explain Plan “lies”
• Explain plan should hardly ever be used…
• You have to be careful when using autotrace and
related tools
• Never use “explain=u/p” with tkprof
• Avoid dbms_xplan.display, use display_cursor

Explain plan lies…
ops$tkyte%ORA11GR2> create table t
2 as
3 select 99 id, to_char(object_id) str_id, a.*
4 from all_objects a
5 where rownum <= 20000;
Table created.
ops$tkyte%ORA11GR2> update t
2 set id = 1
3 where rownum = 1;
1 row updated.
ops$tkyte%ORA11GR2> create index t_idx on t(id);
Index created.
ops$tkyte%ORA11GR2> create index t_idx2 on t(str_id);
Index created.

ops$tkyte%ORA11GR2> begin
2 dbms_stats.gather_table_stats
3 ( user, 'T',
4 method_opt=>'for all indexed columns size 254',
5 estimate_percent => 100,
6 cascade=>TRUE );
7 end;
8 /
PL/SQL procedure successfully completed.

Need a volunteer

Need a volunteer
select count(*) from t where id = :n;
What cardinality would you estimate
and why?

ops$tkyte%ORA11GR2> variable n number
ops$tkyte%ORA11GR2> exec :n := 1;
ops$tkyte%ORA11GR2> set autotrace on explain
ops$tkyte%ORA11GR2> select count(subobject_name) from t where id = :n;
---------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 20 | 86 (0)| 00:00:02 |
| 1 | SORT AGGREGATE | | 1 | 20 | | |
|* 2 | TABLE ACCESS FULL| T | 10000 | 195K| 86 (0)| 00:00:02 |
---------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
2 - filter("ID"=TO_NUMBER(:N)) <<<<===== to_number?

ops$tkyte%ORA11GR2> select * from
table(dbms_xplan.display_cursor('98mx7jbn7jpm8', '', '+peeked_binds'));
select count(subobject_name) from t where id = :n
--------------------------------------------------------------------------------------
--------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 2 (100)| |
| 1 | SORT AGGREGATE | | 1 | 20 | | |
| 2 | TABLE ACCESS BY INDEX ROWID| T | 1 | 20 | 2 (0)| 00:00:01 |
|* 3 | INDEX RANGE SCAN | T_IDX | 1 | | 1 (0)| 00:00:01 |
--------------------------------------------------------------------------------------
Peeked Binds (identified by position):
--------------------------------------
1 - :N (NUMBER): 1
---------------------------------------------------
3 - access("ID"=:N)

ops$tkyte%ORA11GR2> set autotrace traceonly explain
ops$tkyte%ORA11GR2> select object_id from t where str_id = :n;
--------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
--------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 19 | 2 (0)| 00:0
| 1 | TABLE ACCESS BY INDEX ROWID| T | 1 | 19 | 2 (0)| 00:0
|* 2 | INDEX RANGE SCAN | T_IDX2 | 1 | | 1 (0)| 00:0
--------------------------------------------------------------------------------
---------------------------------------------------
2 - access("STR_ID"=:N) <<== interesting…

ops$tkyte%ORA11GR2> select object_id from t where str_id = :n;
OBJECT_ID
----------
99
ops$tkyte%ORA11GR2> select * from table(dbms_xplan.display_cursor);
--------------------------------------------------------------------------
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | 86 (100)| |
|* 1 | TABLE ACCESS FULL| T | 1 | 19 | 86 (0)| 00:00:02 |
--------------------------------------------------------------------------
---------------------------------------------------
1 - filter(TO_NUMBER("STR_ID")=:N) <<= string has to convert..

1 - filter(TO_NUMBER("STR_ID")=:N) <<= string has to convert..
STR_ID
------
0
00
000
0.00
+0
-0
1,000
1.000

Example 2 Generate & display execution plan for the last SQL stmts
executed in a session
SQL>SELECT prod_category, avg(amount_sold)
no rows selected
FROM table(dbms_xplan.display_cursor(null,null,'basic'));
------------------------------------------
Id Operation Name
------------------------------------------
0 SELECT STATEMENT
1 HASH GROUP BY
2 HASH JOIN
-------------------------------------------

Example 3 Displaying execution plan for any other statement from
V$SQL_PLAN
1.Directly:
SQL> SELECT plan_table_output FROM
table(dbms_xplan.display_cursor('fnrtqw9c233tt',null,'basic'));
2.Indirectly:
FROM v$sql s,
TABLE(dbms_xplan.display_cursor(s.sql_id,s.child_number, 'basic')) t
WHERE s.sql_text like 'select PROD_CATEGORY%';

reserved.
Exadata and the Optimizer
• So what operations can actually be offloaded?
– Full table scan
– Fast full index scan of a B-Tree or bitmap index
– Bloom filters
• But not all predicates can be offloaded
– V$SQLFN_METADATA has a column called offloadable
– Indicates if SQL function is offloadable or not
– With each new release more function can be offloaded
– For example TRUNC is but RANK is not offloadable
History

reserved.
• The plan always shows an eligible operation is offloaded
History
The display of the word STORAGE is
actually controlled by the parameter
cell_offload_plan_display it is not an
indication that offloading will or has
occurred, just that it is possible

reserved.
• The plan always shows an eligible operation is offloaded
History
The word STORAGE in the predicate
information is controlled by another
internal optimizer parameter

What is a good plan
for the optimizer

What’s a Good Plan for the Optimizer?
The Optimizer has two different goals
• Serial execution: It’s all about cost
• The cheaper, the better
• Parallel execution: it’s all about performance
• The faster, the better
Two fundamental questions:
• What is cost?
• What is performance?

What is Cost?
• A magically number the optimizer makes up?
• Resources required to execute a SQL statement?
• Result of complex calculations?
• Estimate of how long it will take to execute a statement?
Actual Definition
• Cost represents units of work or resources used
• Optimizer uses CPU & memory usage plus IO as units of work
• Cost is an estimate of the amount of CPU and memory plus the number of
disk I/Os, used in performing an operation
Cost is an internal Oracle measurement

Clustering Factor and Cost Example
ops$tkyte%ORA11GR2> create table organized
2 as
3 select x.*
4 from (select * from stage order by object_name) x
5 /
Table created.
ops$tkyte%ORA11GR2> create table disorganized
2 as
3 select x.*
4 from (select * from stage order by dbms_random.random) x
5 /
Table created.

ops$tkyte%ORA11GR2> create index organized_idx on
organized(object_name);
Index created.
ops$tkyte%ORA11GR2> create index disorganized_idx on
disorganized(object_name);
Index created.

3 ( user, 'ORGANIZED',
5 method_opt=>'for all indexed columns size 254'
6 );
8 ( user, 'DISORGANIZED',
10 method_opt=>'for all indexed columns size 254'
11 );
12 end;
13 /

ops$tkyte%ORA11GR2> select table_name, blocks, num_rows, 0.05*num_rows,
0.10*num_rows from user_tables
2 where table_name like '%ORGANIZED' order by 1;
TABLE_NAME BLOCKS NUM_ROWS 0.05*NUM_ROWS 0.10*NUM_ROWS
------------------------------ ---------- ---------- ------------- -------------
DISORGANIZED 1062 72774 3638.7 7277.4
ORGANIZED 1062 72774 3638.7 7277.4
ops$tkyte%ORA11GR2> select table_name, index_name, clustering_factor
from user_indexes
2 where table_name like '%ORGANIZED' order by 1;
TABLE_NAME INDEX_NAME CLUSTERING_FACTOR
------------------------------ ------------------------------ -----------------
DISORGANIZED DISORGANIZED_IDX 72727
ORGANIZED ORGANIZED_IDX 1036

ops$tkyte%ORA11GR2> select /*+ index( organized organized_idx) */
2 count(subobject_name)
3 from organized;
COUNT(SUBOBJECT_NAME)
---------------------
542
ops$tkyte%ORA11GR2> select /*+ index( disorganized disorganized_idx) */
2 count(subobject_name)
3 from disorganized;
COUNT(SUBOBJECT_NAME)
---------------------
542

select /*+ index( organized organized_idx) */
count(subobject_name)
from organized
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.45 0.45 1036 1398 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 4 0.45 0.46 1036 1398 0 1
Row Source Operation
---------------------------------------------------
SORT AGGREGATE (cr=1398 pr=1036 pw=0 time=456653 us)
TABLE ACCESS BY INDEX ROWID ORGANIZED (cr=1398 pr=1036 pw=0 time=376835 us cos…
INDEX FULL SCAN ORGANIZED_IDX (cr=362 pr=0 pw=0 time=98362 us cost=363 …
1,398-362 = 1,036 - the Clustering Factor and Cost Example…

select /*+ index( disorganized disorganized_idx) */
count(subobject_name)
from disorganized
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 2 0.83 0.83 1036 73089 0 1
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 4 0.83 0.83 1036 73089 0 1
Row Source Operation
---------------------------------------------------
SORT AGGREGATE (cr=73089 pr=1036 pw=0 time=835554 us)
TABLE ACCESS BY INDEX ROWID DISORGANIZED (cr=73089 pr=1036 pw=0 time=750651 us …
INDEX FULL SCAN DISORGANIZED_IDX (cr=362 pr=0 pw=0 time=96421 us cost=363 …
73,089-362 = 72,727 - the Clustering Factor and Cost Example…

ops$tkyte%ORA11GR2> select * from organized where object_name like 'F%';
Execution Plan
----------------------------------------------------------
Plan hash value: 1925627673
-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CP
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 149 | 14453 | 6 (
| 1 | TABLE ACCESS BY INDEX ROWID| ORGANIZED | 149 | 14453 | 6 (
|* 2 | INDEX RANGE SCAN | ORGANIZED_IDX | 149 | | 3 (
-------------------------------------------------------------------------------
---------------------------------------------------
2 - access("OBJECT_NAME" LIKE 'F%')
filter("OBJECT_NAME" LIKE 'F%')

ops$tkyte%ORA11GR2> select * from disorganized where object_name like 'F%';
Execution Plan
----------------------------------------------------------
-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 149 | 14453 | 152
| 1 | TABLE ACCESS BY INDEX ROWID| DISORGANIZED | 149 | 14453 | 152
|* 2 | INDEX RANGE SCAN | DISORGANIZED_IDX | 149 | | 3
-------------------------------------------------------------------------------
---------------------------------------------------
2 - access("OBJECT_NAME" LIKE 'F%')
filter("OBJECT_NAME" LIKE 'F%')

ops$tkyte%ORA11GR2> select * from organized where object_name like 'A%';
Execution Plan
----------------------------------------------------------
-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CP
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1824 | 172K| 38 (
| 1 | TABLE ACCESS BY INDEX ROWID| ORGANIZED | 1824 | 172K| 38 (
|* 2 | INDEX RANGE SCAN | ORGANIZED_IDX | 1824 | | 12 (
-------------------------------------------------------------------------------
---------------------------------------------------
2 - access("OBJECT_NAME" LIKE 'A%')
filter("OBJECT_NAME" LIKE 'A%')

ops$tkyte%ORA11GR2> select * from disorganized where object_name like 'A%';
Execution Plan
----------------------------------------------------------
-------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
-------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1824 | 172K| 290 (1)| 00:00:0
|* 1 | TABLE ACCESS FULL| DISORGANIZED | 1824 | 172K| 290 (1)| 00:00:0
-------------------------------------------------------------------------------
---------------------------------------------------
1 - filter("OBJECT_NAME" LIKE 'A%')

reserved.
‘Regular’ and Exadata plans and the Optimizer
Overview
Optimizer selects the
wrong plan because
Incorrect
cardinality
estimate
Not accounting
correctly for
speed of scans

reserved.
Overview
wrong plan because
Incorrect
cardinality
estimate
Not accounting
correctly for
speed of scans

Understanding an
Execution Plan

SQL Execution Plan
When looking at a plan can you determine if the following is correct?
• Cardinality
• Are the correct number of rows coming out of each object?
• Access paths
• Is the data being accessed in the best way? Scan? Index lookup?
• Join order
• Are tables being joined in the correct order to eliminate as much data as early as possible?
• Join type
• Are the right join types being used?
• Partitioning pruning
• Did I get partition pruning? Is it eliminating enough data?
• Parallelism

Cardinality
What is it?
• Estimate of number rows that will be returned
• Cardinality for a single value predicate = num_rows total / num_distinct total
• E.g. 100 rows total, 10 distinct values => cardinality=10 rows
• OR if histogram present num_rows * Density
Why should you care?
• Influences everything! Access method, Join type, Join Order etc
What causes Cardinality to be wrong?
• Stale or no statistics
• Data Skews
• Multiple single column predicates on a table
• A function wrapped where clause predicate
• Complicated expressions that contain columns from different tables

“Wrong Plan =>
Wrong Cardinality”

Wrong Plan => Wrong Cardinality
ops$tkyte%ORA11GR2> create table t
2 as select decode( mod(rownum,2), 0, 'N', 'Y' ) flag1,
3 decode( mod(rownum,2), 0, 'Y', 'N' ) flag2, a.*
4 from all_objects a
5 /
Table created.
ops$tkyte%ORA11GR2> create index t_idx on t(flag1,flag2);
Index created.
3 ( user, 'T',
4 method_opt=>'for all indexed columns size 254' );
5 end;
6 /

ops$tkyte%ORA11GR2> select 'select * from t', num_rows
2 from user_tables where table_name = 'T'
3 union all
4 select 'select * from t where flag1 = "N"', num_rows/2
6 union all
7 select 'select * from t where flag2 = "N"', num_rows/2
9 union all
10 select 'select * from t where flag1 = "N" and flag2 = "N"', num_rows/2/2
11 from user_tables where table_name = 'T';
'SELECT*FROMT' NUM_ROWS
------------------------------------------------- ----------
select * from t 72726
select * from t where flag1 = "N" 36363
select * from t where flag2 = "N" 36363
select * from t where flag1 = "N" and flag2 = "N" 18181.5

ops$tkyte%ORA11GR2> set autotrace traceonly explain
ops$tkyte%ORA11GR2> select * from t where flag1='N';
Execution Plan
----------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 36499 | 3635K| 301 (1)| 00:00:04 |
--------------------------------------------------------------------------
---------------------------------------------------
1 - filter("FLAG1"='N')

ops$tkyte%ORA11GR2> select * from t where flag2='N';
Execution Plan
----------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------
---------------------------------------------------
1 - filter("FLAG2"='N')

ops$tkyte%ORA11GR2> select * from t where flag1='N' and flag2='N';
Execution Plan
----------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------
---------------------------------------------------
1 - filter("FLAG2"='N' AND "FLAG1"='N')

ops$tkyte%ORA11GR2> select /*+ gather_plan_statistics */ *
2 from t where flag1='N' and flag2='N';
no rows selected

ops$tkyte%ORA11GR2> select * from table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST'));
PLAN_TABLE_OUTPUT
------------------------------------------------------------------------------------
| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers |
------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | | 0 |00:00:00.02 | 1080 |
|* 1 | TABLE ACCESS FULL| T | 1 | 18181 | 0 |00:00:00.02 | 1080 |
------------------------------------------------------------------------------------
---------------------------------------------------
1 - filter(("FLAG2"='N' AND "FLAG1"='N'))
19 rows selected.

ops$tkyte%ORA11GR2> select /*+ dynamic_sampling(t 3) */ * from t where flag1='N' and flag2='N';
Execution Plan
----------------------------------------------------------
-------------------------------------------------------------------------------------
-------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 6 | 612 | 2 (0)| 00:00:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| T | 6 | 612 | 2 (0)| 00:00:01 |
|* 2 | INDEX RANGE SCAN | T_IDX | 6 | | 1 (0)| 00:00:01 |
-------------------------------------------------------------------------------------
---------------------------------------------------
2 - access("FLAG1"='N' AND "FLAG2"='N')
Note
-----
- dynamic sampling used for this statement (level=2)

SELECT /* OPT_DYN_SAMP */ /*+ ALL_ROWS IGNORE_WHERE_CLAUSE
NO_PARALLEL(SAMPLESUB) opt_param('parallel_execution_enabled', 'false')
NO_PARALLEL_INDEX(SAMPLESUB) NO_SQL_TUNE */
NVL(SUM(C1),:"SYS_B_00"), NVL(SUM(C2),:"SYS_B_01"), NVL(SUM(C3),:"SYS_B_02")
FROM
(SELECT /*+ IGNORE_WHERE_CLAUSE NO_PARALLEL("T") FULL("T")
NO_PARALLEL_INDEX("T") */
:"SYS_B_03" AS C1,
CASE WHEN "T"."FLAG1"= :"SYS_B_04" AND "T"."FLAG2"=:"SYS_B_05"
THEN :"SYS_B_06"
ELSE :"SYS_B_07"
END AS C2,
CASE WHEN "T"."FLAG2"=:"SYS_B_08" AND "T"."FLAG1"=:"SYS_B_09“
THEN :"SYS_B_10"
ELSE :"SYS_B_11"
END AS C3
FROM "OPS$TKYTE"."T"
SAMPLE BLOCK (:"SYS_B_12" , :"SYS_B_13") SEED (:"SYS_B_14") "T") SAMPLESUB

Check Cardinality using
SELECT /*+ gather_plan_statistics */
p.prod_name as product, sum(s.quantity_sold) as units,
WHERE s.prod_id =p.prod_id
GROUP BY p.prod_name;
SELECT * FROM table (
DBMS_XPLAN.DISPLAY_CURSOR(FORMAT=>'ALLSTATS LAST'));
compare the estimated number of rows returned for each operation in the plan to actual rows returned

Check Cardinality using SQL Monitor
SQL Monitor allows you to compare the
estimated number of rows returned for each
operation in the plan to actual rows returned

Suggestions for fixing Cardinality issues
Cause Solution
Stale or no statistics DBMS_STATS
Data Skew Create a histogram*
Multiple single column predicates on a
table
Create a column group using
DBMS_STATS.CREATE_EXTENDED_STATS
Multiple columns used in a join Create a column group using
Function wrapped column Create statistics on the function wrapped column using
Complicated expression containing
columns from multiple tables
Use dynamic sampling level 4 or higher

reserved.
Why the Optimizer picks the wrong
plan broken down by the percentage
Incorrect cardinality
estimate
Not accounting
correctly for speed of
scans
Not accounting for
HCC decompression
• More than 85% of the plan
problems reported on Exadata
are caused by Incorrect
cardinality estimates
• Fix cardinality estimates
before trying any other tuning
techniques
• Typically fixing the cardinality
estimates achieves the
desired plan

reserved.
Overview
wrong plan because
Incorrect
cardinality
estimate
Not accounting
correctly for
speed of scans
Complex
Expressions
Incomplete
stats
Stale
Stats

reserved.
Non-Exadata System: Indexes vs. FTS
Not accounting for speed of scans
• On a non-Exadata system the
cost of a full table scan far out
weighs the cost of an index
range scan or even a fast full
index scan
Rows
Full Table Scan
Index Scan
Cost

reserved.
Non-Exadata System: Indexes vs. FTS
• On a non-Exadata system the
cost of a full table scan far out
weighs the cost of an index
range scan or even a fast full
index scan
• Typically the elapse times
follows suit
Rows
Full Table Scan
Index Scan
Time

reserved.
Exadata System: Indexes vs. FTS
Rows
Full Table Scan
Index Scan
• On an Exadata system the
cost of the full table scan still
exceeds the cost of an index
scan
CostTime
• BUT in reality the elapse time
can often be much faster

reserved.
• TEST_TBL table contains 20 million rows
– 22 Columns consisting of numbers and string data types
• Compressed using HCC query high
• Index created on UK column
– This is a unique index
– Values range from 1 to 20 million
Not accounting correctly for the speed of scan

reserved.
Query: Create table <name> as
Select * from test_tbl t where UK <= :VAL;
Default plan is index range scan
Elapse time is 13.33 seconds

reserved.
Query: Create table <name>as
Select /*+ full(t) */ * from test_tbl t where UK <= :VAL;
Forced plan is full table scan
Elapse time is 5.8 seconds

reserved.
• So the answer is simple
• Drop all of the indexes
• Everything will be faster via a full table scan
• Not so fast
• What happens when you have multiple concurrent users?

reserved.
Non-Exadata
Exadata
Performance of concurrent Full Table scan
# of concurrent scans
• With Exadata the number of
concurrent scan operations
that can be sustained before
the elapse time gets too high
is greater due to offload
• Predicate push-down
• Column projection
• But at some point it stops
scaling
• Optimizer needs to be aware
of this too
Time

reserved.
• How can you influence the Optimizer to pick a full table
scan even with an index present?
• DO NOT use OPTIMIZER_INDEX_COST_ADJ
• It doesn’t influence full table scan cost
• It is a multiplier on the cost of an index access
• Setting it to 400 makes the index cost jump 4X from 2028 to 8114

reserved.
• Better to look at statistics that influence Optimizer’s
decisions
• Cost of scan determined by Number of blocks to read
MBRC
• What is Multi Block Read Count (MBRC)?
– Number of db blocks read in a single OS read command
– On Exadata one OS read is 1MB of data or 128 8KB db blocks
But the Optimizer uses MBRC of 8 by default

reserved.
• System statistics tell the
Optimizer about the speed of
IO on a system
• By default system statistics
does not gather MBRC
• Only buffer IO are monitored
• Direct path IO are excluded

reserved.
Accounting correctly for the speed of scan
• New GATHER_SYSTEM_STATS
mode exclusively for EXADATA
• Monitors and captures MBRC
• For 8KB block size captures
128
• New method for monitoring
IOTFRSPEED
• Captures roughly 200MB per
second per process

reserved.
Default plans after
exec dbms_stats.gather_system_stats('EXADATA');
Accounting for speed of scans
Cost of full table scan is now
lower than the index range
scan of 21120

reserved.
Query: Select * from test_tbl where UK <= :VAL;
Full table scan plan with default system statistics
Full table scan plan with EXADATA system statistics

reserved.
Exadata System: Indexes vs. FTS
• With the correct system
statistics in place the cost for a
full table scan more accurately
reflects the expected
performance
• This will not prevent the
Optimizer from selecting an
index
• It just lowers the inflection
point where the plan will
switch from an index access to
a full table scan
Rows
Full Table Scan
Index Scan
Cost

reserved.
Overview
wrong plan because
Incorrect
cardinality
estimate
Not accounting
correctly for
speed of scans
Complex
Expressions
Incomplete
stats
Stale
Stats
By default
Optimizer
assumes
MBRC = 8

reserved.
More Information
• White papers
– Technical overview of the Exadata Database Machine
– What to expect from the Oracle Optimizer in 11g
• Optimizer Blog
– http://blogs.oracle.com/optimizer
• Oracle.com
– http://www.oracle.com/us/products/database/exadata/overview/in
dex.html
– http://www.oracle.com/technetwork/database/focus-areas/bi-
datawarehousing/dbbi-tech-info-optmztn-092214.html

reserved.
Q&A

reserved.

Understanding Query Optimization with ‘regular’ and ‘Exadata’ Oracle

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (6)

Similar to Understanding Query Optimization with ‘regular’ and ‘Exadata’ Oracle

Similar to Understanding Query Optimization with ‘regular’ and ‘Exadata’ Oracle (20)

More from Guatemala User Group

More from Guatemala User Group (20)

Recently uploaded

Recently uploaded (20)

Understanding Query Optimization with ‘regular’ and ‘Exadata’ Oracle