thanks for the memory
DESCRIPTION
Presentation on Oracle memory optimization. Presented at Perth AUSOUG 20/20 Conference November 2009.TRANSCRIPT
© 2009 Quest Software, Inc. ALL RIGHTS RESERVED
Thanks for the MemoryGuy Harrison
Director, Melbourne R&D
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 谢谢