Exadata and the Oracle Optimizer: The Untold Story

Exadata And The Oracle Optimizer
The untold story

Copyright © 2012, Oracle and/or its affiliates. All rights reserved.

Oracle safe harbor statement

All information provided outlines our general product
direction. It's intended for information purposes only, and
may not be incorporated into any contract. It is not a
commitment to deliver any material, code or functionality,
and should not be relied upon in making a purchasing
decision. The development, release, and timing of any
features or functionality described for Oracle's products
remains at the sole discretion of Oracle.


Exadata and the Optimizer
History
•  Originally plan was the Optimizer shouldn’t change
–  Optimizer should not cost smart scan
–  Same plan should be chosen regardless of platform
–  Easier for migrations
–  Exadata will speed up all scan operations automatically by
offloading them to the storage


What Happens when a SQL statement is issued?
1
User 2 Oracle Database
Syntax Check
SQL Execution Parsing
Semantic Check

4 Shared Pool check

Shared Pool 3 Query Transformation
Library Cache
Plan Generator Cost Estimator
Shared SQL Area
… Optimizer
C1 C2 Cn
Code Generator Decision on what processing is
offloaded occurs here


History
•  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
•  The plan always shows an eligible operation is offloaded

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


History
•  The plan always shows an eligible operation is offloaded

The word STORAGE is in the predicate
information is controlled by another
internal optimizer parameter


Ideally
I want an Exadata aware Optimizer

Actual
Translation

Optimizer should pick operations that perform best on Exadata


In reality
I want an Exadata aware Optimizer

Actual
Translation

Optimizer should pick a full table scan instead of index access


Overview
Optimizer selects the
wrong plan because

Incorrect Not accounting Not accounting
cardinality correctly for for HCC
estimate speed of scans decompression



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


Check Cardinality Estimates
SELECT /*+ gather_plan_statistics */ p.prod_name, SUM(s.quantity_sold)
FROM sales s, products p
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

Checking Cardinality estimates for PE
SELECT /*+ gather_plan_statistics */ p.prod_name, SUM(s.quantity_sold)
FROM sales s, products p
WHERE s.prod_id =p.prod_id GROUP By p.prod_name ;

SELECT * FROM table (
ALLSTATS ALL
DBMS_XPLAN.DISPLAY_CURSOR(FORMAT=>'ALLSTATS LAST'));

Note: a lot of the data is zero in
the A-rows column because we
only show last executed cursor
which is the QC. Need to use
ALLSTATS ALL to see info on all
parallel server cursors


Check Cardinality using SQL Monitor

SQL Monitor is the easiest way to compare the estimated number of rows returned for each operation
in a parallel plan to actual rows returned

The Optimizer and Exadata
Incorrect cardinality estimates
Common causes for cardinality issues Solutions

Stale or missing statistics DBMS_STATS using AUTO_SAMPLE_SIZE

Data Skew Re-gather statistics to get histograms

Multiple single column predicates on a Create a column group using
table DBMS_STATS.CREATE_EXTENDED_STATS
Function wrapped column Create statistics on the function wrapped column using
DBMS_STATS.CREATE_EXTENDED_STATS

Multiple columns used in a join Create a column group on join columns using
DBMS_STATS.CREATE_EXTENDED_STAT
Complicated expression containing Use dynamic sampling level 4 or higher
columns from multiple tables


The Optimizer and Exadata
Dynamic Sampling In Oracle Database 11g Release 2
•  Optimizer automatically decide if dynamic sampling will
be useful & what level for parallel SQL statements
–  Decision is based on size of the tables in the statement
–  The complexity of the predicates
•  If OPTIMIZER_DYNAMIC_SAMPLING is explicitly set then
that specified value will be honored
•  You can tell if dynamic sampling kicks in by looking in the
note section of the execution plan


Overview
wrong plan because


Stale Incomplete Complex
Stats stats Expressions


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

•  Typically the elapse times
follows suit

Full Table Scan
Index Scan
Rows


•  On an Exadata system the
Exadata System: Indexes vs. FTS cost of the full table scan still
excesses the cost of an index
scan
•  BUT in reality the elapse time
Time
Cost

can often be much faster

Full Table Scan
Index Scan
Rows


Not accounting correctly for the speed of scan
•  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


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

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

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


•  With Exadata the number of
Performance of concurrent Full Table scan concurrent scan operations
that can be sustained before
the elapse time gets too high
is greater due to offload
Time

•  Predicate push-down

Non-Exadata •  Column projection
Exadata •  But at some point it stops
scaling
•  Optimizer needs to be aware
of this too
# of concurrent scans


•  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


•  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 always uses MBRC of 8


•  By default Optimizer uses MBRC of 8 instead 128
•  In 8.1.6. wanted to decouple Optimizer MBRC from the
parameter DB_FILE_MULTI_BLOCK_READ_COUNT
–  This was to allowed the database to request larger IOs without
changing any of the existing execution plans
•  Cost of full table scan becomes expensive to soon on
Exadata
How do you tell the Optimizer what IO a hardware system can do?


•  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


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
•  Requires patch for Bug
10248538


Accounting for speed of scans
Default plans after
exec dbms_stats.gather_system_stats('EXADATA');

Cost of full table can is now
lower than the index range
scan of 21120


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

Full table scan plan with EXADATA system statistics


•  With the correct system
Exadata System: Indexes vs. FTS statistics in place the cost for a
full table scan more accurately
reflects the expected
performance
Cost

•  This will not prevent the
Optimizer from selecting an
index
•  It just lowers the inflection
Full Table Scan point where the plan will
switch from an index access to
Index Scan
a full table scan
Rows


Overview
wrong plan because


Stale Incomplete Complex By default
Stats stats Expressions Optimizer
assumes
MBRC = 8


How HCC decompression works
Buffer Cache •  For single block access
decompression happens on
Compression
Unit database server
Column 1

Column 2

Column 3

•  Compression Unit is read from
disk and stored compressed in
buffer cache
•  Decompression occurs in the
PGA and decompressed data
PGA
is not shared
Compression
Unit
•  Only one Compression Unit
Column 1

Column 2

Column 3

Decompression
can be decompressed at a
time


Not accounting for HCC decompression

Query: Select * from test_tbl where UK < 96;
Plan:
TEST_TBL
Access by rowid

UK_IND
Range Scan


Exadata and the Optimizer Data in UK_ID
HCC decompression with index access index ordered
sequentially
Buffer Cache Index on
UK
Compression Compression
1
Compression Unit Unit 1 Unit 2
is read from 1 2

Column 1

Column 2

Column 1

Column 2
2
disk & stored 3 4
compressed in 5 6
3
7 8
buffer cache
4

TEST_TBL TABLE PGA 5
Query high HCC
Compression Compression Compression 6
sorts data before Unit 1 Unit 2 Unit 2
1
compressing it odd 1 2 2

Column 1

Column 2
Column 1

Column 2

1

Column 1

Column 2
Column 1

Column 2

7
numbers in one 3 4 Decompress 4
3
Better yet Optimizer
How does how do we prevent the repeated
compression unit &
7 8
Unit 2 decompression?
5 account for the repeated decompression?
6 1 6
5
8
8

even in the other 7


Overview
wrong plan because


Stale Incomplete Complex By default Decompress is
Stats stats Expressions Optimizer CPU intensive
assumes &results are
MBRC = 8 not shared


Summary
Exadata System baseline Accounting for speed of Scan Accounting for decompression

Cost
Cost
Cost

Full Table Scan Full Table Scan Full Table Scan

Index Scan Index Scan Index Scan

Rows Rows Rows


Summary
•  If you are getting an index access instead of a full table scan
–  Ensure the cardinality estimates are accurate
–  Confirm the full table scan is actually more performant
•  If so apply patch for 10248538
•  Gather system stats with EXADATA option
–  Should be available in Exadata patch bundles 18 on 11.2.0.2 (11.2.0.2.18
–  Should be available in Exadata patch bundles 8 on 11.2.0.3 (11.2.0.3.8)
•  If the index access is needed on a HCC table
–  Apply patch for 12780479 (available soon)


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/
index.html
–  http://www.oracle.com/technetwork/database/focus-areas/bi-
datawarehousing/dbbi-tech-info-optmztn-092214.html

Q&A


Exadata and the Oracle Optimizer: The Untold Story

In this document

More Related Content

What's hot

Viewers also liked

Similar to Exadata and the Oracle Optimizer: The Untold Story

More from Enkitec

Recently uploaded

Exadata and the Oracle Optimizer: The Untold Story