© 2009 Quest Software, Inc. ALL RIGHTS RESERVED

Thanks for the MemoryGuy Harrison

Director, Melbourne R&D

guy.harrison@quest.com

www.guyharrison.net

2

Introductions

Buy Quest Products

3

Human memory is complex • Short Term Sensory Store:

~ 1 second uncompressed raw memory

• Working memory: Limited capacity, requires attention

• Long term memory: physically stored in brain structure; large capacity; indexed strangely

Beyond Bullets Points:

By: Cliff Atkinson

4

Oracle memory is much simpler• Buffer cache memory caches segment data to

avoid read IO.

• PGA is used for program working memory such as

sorting and hashing

• Other areas are less performance critical

Buffer pools

Program Global Area (PGA)Sort area

Hash Area

Data (USER) tablespace

Temporary tablespace

Oracle Session

5

Sort IO can easily dominate datafile IO

1 2 3 4 8 16 32 50 75 100 125 150 175 200 250 3000

10

20

30

40

50

60

70

80

90

100

Table/Index IO CPU Time Temp Segment IO

PGA Memory available (MB)

Tim

e (s

)

6

What consumes PGA memory• Sorts:

– ORDER BY – SORT-MERGE JOIN– UNION, INTERSECT, MINUS– Pre-10GR2 GROUP BY , DISTINCT– Analytic functions: OVER(), LEAD(), LAG(), etc

• Hash Operations:– Hash join– Hash GROUP BY, DISTINCT

• PL/SQL variables– Collections– BULK COLLECT– Parameter passing without NOCOPY

7

PGA Aggregate Target and session memory

0 200 400 600 800 1000 1200 1400 1600 1800 20000

200

400

600

800

1000

1200

Max process PGA Max workarea PGA Total Parallel workarea

PGA_AGGREGATE_TARGET (MB)

Siz

e L

imit

(M

B)

8

Optimal, one-pass, multi-pass

0.499999999999999 4.99999999999999 49.9999999999999 499.9999999999990

10

20

30

40

50

60

70

80

90

100

Sort Memory available (MB)

Tim

e (s

)

Optimal

Single Pass

Mu

lti-pa

ss

9

Sort merge and hash joins

1 10 100 10000

50

100

150

200

250

Hash Join Sort Merge Join

Workarea Memory (MB)

Ela

pse

d T

ime

(s)

10

Estimated SQL memory

11

Actual SQL Memory

12

PGA advice - manual

13

PGA advice - OEM

14

PGA and Sorts – Spotlight on Oracle

15

Opting out of PGA Aggregate Target• Default workarea sizing policies only allow for a session to get

10-20% of the PGA• If a single large sort is in progress, it makes sense to “opt out” of

automatic workarea sizing

16

Shared Memory

17

Modified LRU mechanism

Buffer CakeBuffer Cache

Oracle Session

18

Modified LRU mechanism: Table Scans

Buffer CakeBuffer Cache

Oracle Session

19

Impact of direct path IO

http://guyh.textdriven.com/OPSGSamples/Ch18/temporary_direct.sql

20

The buffer cache “hit rate”

http://guyh.textdriven.com/OPSGSamples/Ch18/hit_rate.sql

21

Multiple buffer pools

KEEP

DEFAULT

0 200 400 600 800 1,000 1,200

325

399

24

637

Other

IO Time

Average query time (ms)

Bu

ffer

Po

ol

22

Buffer Cache advisory: manual

23

Buffer cache advisory: OEM

24

Automatic Shared Memory management (ASMM)

• Default in 10g and recommended (with caveats):– Set Minimum values for key pools (buffer pools, shared pool)– Manually size non-default pools using

V$DB_CACHE_ADVICE– Monitor for memory starvation– Monitor for memory thrashing

• Waits on “SGA: allocation forcing component growth”

25

Memory starvation and thrashing

26

Optimizing overall memory• Optimizing between PGA and SGA are often more significant

than allocating within each area– In 10g optimization is difficult:– Compare PGA and Buffer Cache advisories– Adjust based on IO types (direct read temp vs. physical reads)

• In 11g can use Automatic Memory Management – Risk of thrashing and starvation is greater than with ASMM– Set minimum values for all pools– Manually configure non-default buffer pools

27

Worst case scenario• Trivial memory allocations from PL/SQL programs can steal

vital memory from buffer cache• Situation can become worse if MTS is enabled• Setting minimum values is virtually mandatory

28

Spotlight on Oracle memory management

29

Spotlight on Oracle memory management

30

11g Result Set Cache• Can provide massive improvements for expensive queries on static tables• In memory dynamic materialized view?

Result cache

No Result Cache

0 10,000 20,000 30,000 40,000 50,000 60,000

6,850

59,590

Elapsed time (ms)

31

Result set cache• Caveats:

– Single latch on modifications– Any modification to a dependent table flushes the result sets – Can select statements only at the table level or by inserting a hint

• Bottom line:– Limited effectiveness– Unique candidate SQLs must be low frequency– Tables must be static

32

Things we didn’t talk about

• Shared pool• Redo buffer• Large Pool• Flashback buffer

33

Key take aways

• Don’t emphasize buffer cache tuning at the expense of PGA• Consider opting out of PGA Aggregate Target for large sorts• ASMM and ASM are fine, but set minimums for important

memory pools • Result set cache is promising, but right now is of limited

applicability

© 2009 Quest Software, Inc. ALL RIGHTS RESERVED

End of Presentation

너를 감사하십시요 Thank You Danke Schön

Gracias 有難う御座いました Merci

Grazie Obrigado 谢谢