+ All Categories
Home > Technology > Why You May Not Need Offloading

Why You May Not Need Offloading

Date post: 21-Jun-2015
Category:
Upload: enkitec
View: 224 times
Download: 8 times
Share this document with a friend
Popular Tags:
31
Why You May Not Need Offloading January 20, 2013 Presented by: Alex Fatkulin Senior Consultant
Transcript
Page 1: Why You May Not Need Offloading

Why You May Not Need Offloading

January 20, 2013

Presented by: Alex Fatkulin

Senior Consultant

Page 2: Why You May Not Need Offloading

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

Page 3: Why You May Not Need Offloading

Why This Presentation?

4

Page 4: Why You May Not Need Offloading

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

Page 5: Why You May Not Need Offloading

What is offload ratio?

The amount of work performed on the storage cells

relative to the total amount of work

6

𝑅 = 𝑊(𝐶𝐸𝐿𝐿)

𝑊 𝐶𝐸𝐿𝐿 + 𝑊(𝑅𝐷𝐵𝑀𝑆)

Page 6: Why You May Not Need Offloading

I/O Saved (MOS)

MOS Doc ID 1438173.1

7

𝐼𝑂_𝑆𝐴𝑉𝐸𝐷 =𝐼𝑂_𝐶𝐸𝐿𝐿_𝑂𝐹𝐹𝐿𝑂𝐴𝐷_𝐸𝐿𝐼𝐺𝐼𝐵𝐿𝐸_𝐵𝑌𝑇𝐸𝑆 − 𝐼𝑂_𝐼𝑁𝑇𝐸𝑅𝐶𝑂𝑁𝑁𝐸𝐶𝑇_𝐵𝑌𝑇𝐸𝑆

𝐼𝑂_𝐶𝐸𝐿𝐿_𝑂𝐹𝐹𝐿𝑂𝐴𝐷_𝐸𝐿𝐼𝐺𝐼𝐵𝐿𝐸_𝐵𝑌𝑇𝐸𝑆

= 1 − 𝐼𝑂_𝐼𝑁𝑇𝐸𝑅𝐶𝑂𝑁𝑁𝐸𝐶𝑇_𝐵𝑌𝑇𝐸𝑆

𝐼𝑂_𝐶𝐸𝐿𝐿_𝑂𝐹𝐹𝐿𝑂𝐴𝐷_𝐸𝐿𝐼𝐺𝐼𝐵𝐿𝐸_𝐵𝑌𝑇𝐸𝑆

IO_INTERCONNECT_BYTES

Includes all types of I/O against any storage

Includes mirrored data

Compressed vs Uncompressed data

Page 7: Why You May Not Need Offloading

Cell Offload Efficiency (SQLMON)

SQL Monitor

8

C = 1 − 𝐼𝑂_𝐼𝑁𝑇𝐸𝑅𝐶𝑂𝑁𝑁𝐸𝐶𝑇_𝐵𝑌𝑇𝐸𝑆

𝑃𝐻𝑌𝑆𝐼𝐶𝐴𝐿_𝑅𝐸𝐴𝐷_𝐵𝑌𝑇𝐸𝑆 + 𝑃𝐻𝑌𝑆𝐼𝐶𝐴𝐿_𝑊𝑅𝐼𝑇𝐸_𝐵𝑌𝑇𝐸𝑆

Only considers data volumes

Page 8: Why You May Not Need Offloading

Offload Ratio

Two SQL statements return the same data but have

different plans and offload ratios

9

SQL Statement Offload ratio

A 90%

B 0%

Which one is better?

Page 9: Why You May Not Need Offloading

Offload Ratio

Two SQL statements return the same data but have

different plans and offload ratios

10

SQL Statement Offload ratio Scanned Returned

A 90% 100GB 10GB

B 0% 10GB 10GB

Using offload ratio alone is unreliable indicator for

performance

Page 10: Why You May Not Need Offloading

90% Offload Ratio

11

SELECT * FROM TRANS_DATA WHERE STATE=‘NJ’

RDBMS

100%

CELLSRV

10% (STATE=‘NJ’)

Page 11: Why You May Not Need Offloading

90% Offload Ratio

12

SELECT * FROM TRANS_DATA WHERE STATE=‘NJ’

CELLSRV

10%

100%

DISCARDED 90%

RDBMS

Page 12: Why You May Not Need Offloading

90% Offload Ratio

13

SELECT * FROM TRANS_DATA WHERE STATE=‘NJ’

CELLSRV

10%

(output)

100% (input)

DISCARDED 90%

(overhead)

RDBMS

Page 13: Why You May Not Need Offloading

Offload Ratio

14

create table trans_data

(

...

state varchar2(2),

...

) partition by list (state)

(

...

partition NJ values ('NJ'),

partition NY values ('NY'),

...

);

What if we partition the table?

Page 14: Why You May Not Need Offloading

0% Offload Ratio

15

SELECT * FROM TRANS_DATA WHERE STATE=‘NJ’

CELLSRV

100% (input)

NOTHING DISCARDED 0%

(overhead)

RDBMS

100%

(output)

Eliminated by Partition Pruning

Page 15: Why You May Not Need Offloading

Cell Offload Efficiency (SQLMON)

16

Efficiency

Overhead

C = 1 − 𝐼𝑂_𝐼𝑁𝑇𝐸𝑅𝐶𝑂𝑁𝑁𝐸𝐶𝑇_𝐵𝑌𝑇𝐸𝑆

𝑃𝐻𝑌𝑆𝐼𝐶𝐴𝐿_𝑅𝐸𝐴𝐷_𝐵𝑌𝑇𝐸𝑆 + 𝑃𝐻𝑌𝑆𝐼𝐶𝐴𝐿_𝑊𝑅𝐼𝑇𝐸_𝐵𝑌𝑇𝐸𝑆

→ 1 −OUTPUT

INPUT

SELECT * FROM TRANS_DATA WHERE STATE=‘NJ’

Page 16: Why You May Not Need Offloading

Data Selectivity

Selective data – data SQL statement needs for the final

result

Unselective data – data SQL statement has to go through

17

SQL Input Output Data Selectivity

A 100GB 10GB 10%

B 10GB 10GB 100%

Page 17: Why You May Not Need Offloading

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

18

0 10 20 30 40 50 60 70 80 90 100

SQL B

SQL B Exadata

SQL A

SQL A Exadata

Response Time %

Unselective Data Selective Data

Page 18: Why You May Not Need Offloading

Exadata Design Disaster

The easiest way to archive high offload ratios is to make

all your SQLs to be very data unselective

19

Page 19: Why You May Not Need Offloading

The Year is 2001…

20

Page 20: Why You May Not Need Offloading

The Year is 2001…

“Buffer Cache Hit Ratio Tuning is

Rampant…”

21

Page 21: Why You May Not Need Offloading

The Year is 2001…

Why a 99%+ Database Buffer Cache Hit Ratio is NOT Ok (*)

Cary Millsap/Hotsos Enterprises Ltd.

22

(*) used here with Cary’s permission

Page 22: Why You May Not Need Offloading

The Year is 2001…

“Database buffer cache hit ratios are

useless!!!”

23

Page 23: Why You May Not Need Offloading

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

Page 24: Why You May Not Need Offloading

Bump Your Offload Ratio If you’re still unconvinced…

25

Page 25: Why You May Not Need Offloading

Bump Your Offload Ratio

Improves your offload ratio to 99%+ percent!!! (*)

26

--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

Page 26: Why You May Not Need Offloading

Limitations

27

Page 27: Why You May Not Need Offloading

Data Processing

28

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

Page 28: Why You May Not Need Offloading

Data Processing

29

SELECT STATE, STORE_ID, DATE_ID, SUM(AMOUNT), COUNT(DISTINCT CART_ID)

FROM TRANS_DATA

GROUP BY STATE, STORE_ID, DATE_ID

Page 29: Why You May Not Need Offloading

Trade-Offs

30

Page 30: Why You May Not Need Offloading

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

Page 31: Why You May Not Need Offloading

Q & A

Email: [email protected]

Blog: http://afatkulin.blogspot.com

32


Recommended