1. Why You May Not Need Offloading
Presented by: Alex Fatkulin
Senior Consultant
January 20, 2013

2. Who am I ?
 Senior Technical Consultant at Enkitec
 12 years using Oracle
 Clustered and HA solutions
 Database Development and Design
 Technical Reviewer
 Blog at http://afatkulin.blogspot.com
3

3. Why This Presentation?
4

4. Sounds familiar?
(tongue in cheek)
 My SQL is slow but it’s offload ratio is 95%+
 This just can’t be!
 My SQL is slow and it must be because it has a low
offload ratio
 This ought to be it!
 Offload ratio is the only thing to worry about
 Nothing else matters!
5

5. What is offload ratio?
 The amount of work performed on the storage cells
relative to the total amount of work
𝑊(𝐶𝐸𝐿𝐿)
𝑅=
𝑊 𝐶𝐸𝐿𝐿 + 𝑊(𝑅𝐷𝐵𝑀𝑆)
6

6. I/O Saved (MOS)
 MOS Doc ID 1438173.1
𝐼𝑂_𝑆𝐴𝑉𝐸𝐷 =
𝐼𝑂_𝐶𝐸𝐿𝐿_𝑂𝐹𝐹𝐿𝑂𝐴𝐷_𝐸𝐿𝐼𝐺𝐼𝐵𝐿𝐸_𝐵𝑌𝑇𝐸𝑆 − 𝐼𝑂_𝐼𝑁𝑇𝐸𝑅𝐶𝑂𝑁𝑁𝐸𝐶𝑇_𝐵𝑌𝑇𝐸𝑆
𝐼𝑂_𝐶𝐸𝐿𝐿_𝑂𝐹𝐹𝐿𝑂𝐴𝐷_𝐸𝐿𝐼𝐺𝐼𝐵𝐿𝐸_𝐵𝑌𝑇𝐸𝑆
=1 −
𝐼𝑂_𝐼𝑁𝑇𝐸𝑅𝐶𝑂𝑁𝑁𝐸𝐶𝑇_𝐵𝑌𝑇𝐸𝑆
𝐼𝑂_𝐶𝐸𝐿𝐿_𝑂𝐹𝐹𝐿𝑂𝐴𝐷_𝐸𝐿𝐼𝐺𝐼𝐵𝐿𝐸_𝐵𝑌𝑇𝐸𝑆
 IO_INTERCONNECT_BYTES
 Includes all types of I/O against any storage
 Includes mirrored data
 Compressed vs Uncompressed data
7

7. Cell Offload Efficiency (SQLMON)
 SQL Monitor
C=1 −
𝐼𝑂_𝐼𝑁𝑇𝐸𝑅𝐶𝑂𝑁𝑁𝐸𝐶𝑇_𝐵𝑌𝑇𝐸𝑆
𝑃𝐻𝑌𝑆𝐼𝐶𝐴𝐿_𝑅𝐸𝐴𝐷_𝐵𝑌𝑇𝐸𝑆 + 𝑃𝐻𝑌𝑆𝐼𝐶𝐴𝐿_𝑊𝑅𝐼𝑇𝐸_𝐵𝑌𝑇𝐸𝑆
 Only considers data volumes
8

8. Offload Ratio
 Two SQL statements return the same data but have
different plans and offload ratios
SQL Statement
Offload ratio
A
90%
B
0%
 Which one is better?
9

9. Offload Ratio
 Two SQL statements return the same data but have
different plans and offload ratios
SQL Statement
Offload ratio
Scanned
Returned
A
90%
100GB
10GB
B
0%
10GB
10GB
 Using offload ratio alone is unreliable indicator for
performance
10

10. 90% Offload Ratio
SELECT * FROM TRANS_DATA WHERE STATE=‘NJ’
100%
CELLSRV
10% (STATE=‘NJ’)
RDBMS
11

11. 90% Offload Ratio
SELECT * FROM TRANS_DATA WHERE STATE=‘NJ’
100%
CELLSRV
10%
DISCARDED
90%
RDBMS
12

12. 90% Offload Ratio
SELECT * FROM TRANS_DATA WHERE STATE=‘NJ’
100% (input)
CELLSRV
10%
(output)
DISCARDED
90%
(overhead)
RDBMS
13

13. Offload Ratio
 What if we partition the table?
create table trans_data
(
...
state varchar2(2),
...
) partition by list (state)
(
...
partition NJ values ('NJ'),
partition NY values ('NY'),
...
);
14

14. 0% Offload Ratio
SELECT * FROM TRANS_DATA WHERE STATE=‘NJ’
100% (input)
Eliminated by Partition Pruning
CELLSRV
100%
(output)
NOTHING DISCARDED
0%
(overhead)
RDBMS
15

15. Cell Offload Efficiency (SQLMON)
SELECT * FROM TRANS_DATA WHERE STATE=‘NJ’
C=1 −
𝐼𝑂_𝐼𝑁𝑇𝐸𝑅𝐶𝑂𝑁𝑁𝐸𝐶𝑇_𝐵𝑌𝑇𝐸𝑆
𝑃𝐻𝑌𝑆𝐼𝐶𝐴𝐿_𝑅𝐸𝐴𝐷_𝐵𝑌𝑇𝐸𝑆 + 𝑃𝐻𝑌𝑆𝐼𝐶𝐴𝐿_𝑊𝑅𝐼𝑇𝐸_𝐵𝑌𝑇𝐸𝑆
→1−
OUTPUT
INPUT
 Efficiency
 Overhead
16

16. Data Selectivity
 Selective data – data SQL statement needs for the final
result
 Unselective data – data SQL statement has to go through
SQL
Input
Output
Data Selectivity
A
100GB
10GB
10%
B
10GB
10GB
100%
17

17. Data Selectivity and Exadata
 Data selective query beats data unselective query any day of the
week (all other things equal)
 Data unselective queries tend to benefit the most from the Exadata
Response Time %
SQL A Exadata
SQL A
SQL B Exadata
SQL B
0
10
20
30
40
Unselective Data
50
60
70
80
90
100
Selective Data
18

18. Exadata Design Disaster
The easiest way to archive high offload ratios is to make
all your SQLs to be very data unselective
19

19. The Year is 2001…
20

20. The Year is 2001…
“Buffer Cache Hit Ratio Tuning is
Rampant…”
21

21. The Year is 2001…
 Why a 99%+ Database Buffer Cache Hit Ratio is NOT Ok (*)
 Cary Millsap/Hotsos Enterprises Ltd.
(*) used here with Cary’s permission
22

22. The Year is 2001…
“Database buffer cache hit ratios are
useless!!!”
23

23. Buffer Cache Hit Ratio
 One of the major ratios used to tune databases
 Displayed on the “front page” of most database tools
(Quest Spotlight, Oracle OEM, etc.)
 Choose any hit ratio (why BCHR is useless):
http://www.oracledba.co.uk/tips/choose.htm
 It took 10+ years to deal with it
24

24. Bump Your Offload Ratio
If you’re still unconvinced…
25

25. Bump Your Offload Ratio
 Improves your offload ratio to 99%+ percent!!! (*)
--One time setup
create table bump_my_offload nocompress as
select rpad('x', 4000, 'x') x
from dual
connect by level <= 200000;
--Main Loop
begin
execute immediate 'alter session set parallel_degree_policy=manual';
execute immediate 'alter session set "_parallel_cluster_cache_policy"=adaptive';
execute immediate 'alter session set "_kcfis_storageidx_disabled"=true';
loop
for cur in (select /*+ parallel(16) */ * from bump_my_offload where x is null)
loop
null;
end loop;
end loop;
end;
(*) if you don’t archive 99%+ offload ratio simply run more
copies of the “Main Loop” in parallel
26

26. Limitations
27

27. Data Processing
SELECT STATE, STORE_ID, DATE_ID, SUM(AMOUNT), COUNT(DISTINCT CART_ID)
FROM TRANS_DATA
GROUP BY STATE, STORE_ID, DATE_ID
CPU
User I/O
Raw Data Processing
Aggregation
Processing
Raw Data Processing Exadata
28

28. Data Processing
SELECT STATE, STORE_ID, DATE_ID, SUM(AMOUNT), COUNT(DISTINCT CART_ID)
FROM TRANS_DATA
GROUP BY STATE, STORE_ID, DATE_ID
29

29. Trade-Offs
30

30. Trade-Offs
 In-Memory PQ
 Does not work with smart scans (no direct path reads)
 Segment-level checkpoints
 Can introduce significant overhead
 OLTP activity
 Often does not mix well with smart scans
 In-memory database option
 Not in offloading territory
31

31. Q&A
Email: afatkulin@enkitec.com
Blog: http://afatkulin.blogspot.com
32