Why You May Not Need Offloading
Upcoming SlideShare
Loading in...5
×
 

Why You May Not Need Offloading

on

  • 211 views

 

Statistics

Views

Total Views
211
Views on SlideShare
199
Embed Views
12

Actions

Likes
0
Downloads
8
Comments
0

1 Embed 12

https://www.enkitec.com 12

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Why You May Not Need Offloading Why You May Not Need Offloading Presentation Transcript

  • Why You May Not Need Offloading Presented by: Alex Fatkulin Senior Consultant January 20, 2013
  • 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
  • Why This Presentation? 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
  • What is offload ratio?  The amount of work performed on the storage cells relative to the total amount of work 𝑊(𝐶𝐸𝐿𝐿) 𝑅= 𝑊 𝐶𝐸𝐿𝐿 + 𝑊(𝑅𝐷𝐵𝑀𝑆) 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
  • Cell Offload Efficiency (SQLMON)  SQL Monitor C=1 − 𝐼𝑂_𝐼𝑁𝑇𝐸𝑅𝐶𝑂𝑁𝑁𝐸𝐶𝑇_𝐵𝑌𝑇𝐸𝑆 𝑃𝐻𝑌𝑆𝐼𝐶𝐴𝐿_𝑅𝐸𝐴𝐷_𝐵𝑌𝑇𝐸𝑆 + 𝑃𝐻𝑌𝑆𝐼𝐶𝐴𝐿_𝑊𝑅𝐼𝑇𝐸_𝐵𝑌𝑇𝐸𝑆  Only considers data volumes 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
  • 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
  • 90% Offload Ratio SELECT * FROM TRANS_DATA WHERE STATE=‘NJ’ 100% CELLSRV 10% (STATE=‘NJ’) RDBMS 11
  • 90% Offload Ratio SELECT * FROM TRANS_DATA WHERE STATE=‘NJ’ 100% CELLSRV 10% DISCARDED 90% RDBMS 12
  • 90% Offload Ratio SELECT * FROM TRANS_DATA WHERE STATE=‘NJ’ 100% (input) CELLSRV 10% (output) DISCARDED 90% (overhead) RDBMS 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
  • 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
  • Cell Offload Efficiency (SQLMON) SELECT * FROM TRANS_DATA WHERE STATE=‘NJ’ C=1 − 𝐼𝑂_𝐼𝑁𝑇𝐸𝑅𝐶𝑂𝑁𝑁𝐸𝐶𝑇_𝐵𝑌𝑇𝐸𝑆 𝑃𝐻𝑌𝑆𝐼𝐶𝐴𝐿_𝑅𝐸𝐴𝐷_𝐵𝑌𝑇𝐸𝑆 + 𝑃𝐻𝑌𝑆𝐼𝐶𝐴𝐿_𝑊𝑅𝐼𝑇𝐸_𝐵𝑌𝑇𝐸𝑆 →1− OUTPUT INPUT  Efficiency  Overhead 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
  • 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
  • Exadata Design Disaster The easiest way to archive high offload ratios is to make all your SQLs to be very data unselective 19
  • The Year is 2001… 20
  • The Year is 2001… “Buffer Cache Hit Ratio Tuning is Rampant…” 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
  • The Year is 2001… “Database buffer cache hit ratios are useless!!!” 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
  • Bump Your Offload Ratio If you’re still unconvinced… 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
  • Limitations 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
  • 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
  • Trade-Offs 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
  • Q&A Email: afatkulin@enkitec.com Blog: http://afatkulin.blogspot.com 32