senegacnik pga memory management oracle9i 10g
DESCRIPTION
Advanced Management Of Working Areas In Oracle 9i/10gTRANSCRIPT
Advanced Management Of Advanced Management Of Advanced Management Of Advanced Management Of Working Areas In Oracle 9i/10gWorking Areas In Oracle 9i/10gWorking Areas In Oracle 9i/10gWorking Areas In Oracle 9i/10g
Jože Senegačnikprivate researcher
Who am I?
• Registered private researcher
• Member of the OakTable Network
• 17+ years of experience with Oracle RDBMS.
• First experience with Oracle Version 4 in 1988
• Member of the board of SIOUG
• Owner of www.dbprof.com
Agenda
• About the speaker
• SGA/PGA/UGA
• SQL Operators
• Automatic Work Area Management
• SMM Daemon
• SMM Work Area sizes
• New sort algorithm
• Conclusions
Accompanying paper
• Part of the presentation is a technical paper with the same title.
• Contains excerpts from the SMM trace files and detailed description of execution of one SQL statement with 3 working areas.
• Describes hidden parameters and related views for monitoring working area memory allocation.
• Only part of the material from the paper is presented due to time limit.
• The paper was presented at UKOUG 2005.
UGA
Oracle InstanceOracle Instance
SGA
Redo LogBuffer
Shared Pool
Data DictionaryCache
LibraryCache
DBWRSMONPMON CKPTLGWR Others
Java Pool
Large Pool
DatabaseBuffer Cache
ARCH
PGAPGA
Serverprocess 1
PGAPGA
Serverprocess 2
PGAPGA
Serverprocess 3
PGAPGA
SharedServer
process 1
PGAPGA
SharedServer
process 2
PGA_AGGREGATE_TARGET
SGA / PGA / UGA
UGA UGA UGA
UGAUGAUGAUGAUGAUGA
UGAUGAUGA
SQL Operators
• Sort-based operators, such as ORDER BY, GROUP BY, ROLLUP, and window functions in analytical functions
• Hash-join
• Bitmap merge
• Bitmap create
• Write buffers used by bulk load operations
SQL Operators
• Are able to adopt to changed global memory bound.
• Sometimes they cannot adapt instantaneously because releasing of memory in certain phase is not appropriate or even possible (lag).
Execution Modes
• Optimal execution – everything in memory
• input data
• auxiliary memory structures.
• One-pass execution – not enough memory
• extra pass has to be performed over part of the input data.
• Response time increases.
• Multi-pass execution – minimum memory • multiple passes over the input data are required.
• response time dramatically increases.
Work Area Memory Requirements
Response time
Memory usedminumum 1 pass (cache)
optimal
PGA_AGGREGATE_TARGET
• PGA_AGGREGATE_TARGET (P_A_T) • Target aggregate PGA memory available to all server processes attached
to the instance.
• Setting P_A_T > 0 � WORKAREA_SIZE_POLICY= AUTO then*_AREA_SIZE parameters are neglected.
• Setting P_A_T = 0 � WORKAREA_SIZE_POLICY= MANUAL. SQL work areas are sized using the *_AREA_SIZE parameters.
• P_A_T is a dynamic parameter. Oracle tries adapting the size of work areas to ensure:
• the maximum performance benefits and
• the most efficient utilization of memory.
• In Oracle9i the automatics works only for dedicated server connections, in Oracle10g for shared and dedicated servers.
WA1
HJ
WA1
HJ
SQL1SQL1
aggregated persistent
area + a part of
the run time area
of all
server processes
aggregated persistent
area + a part of
the run time area
of all
server processes
SQL2SQL2 SQLn
SQLn
PGA aggregate
WORK AREA TABLE (X$QESMMIWT)
v$sql_workarea_active
WP1WP1
v$sql_workarea
WP2WP2 WP3
WP3 WP4WP4 WP5
WP5 WPnWPn
...
...
WA2
SORT
WA2
SORT
WA3
BITMAP
WA3
BITMAP
LOCALMEMORYMANAGER
LOCALMEMORYMANAGER
GLOBALMEMORYMANAGER
(CKPT)
GLOBALMEMORYMANAGER
(CKPT)
SGA
PGA_AGGREGATE_TARGET
SQL Memory Target (auto target)1st step
GlobalMemoryBound
2nd step (every 3 seconds bound is published)
Free
list
Free
list
me
mo
ry d
rift
SQL Memory Target
• SQL memory Target
P_A_T – (aggr(persistent area) + aggr(part of runtime area))
• Global memory bound is the maximum value for which the sum of the expected work area size of each operator will be less than or equal to the target SQL memory target.
Work Area Table
• V$SQL_WORKAREA_ACTIVE reports the active working areas
• only if size >= 64K – see Metalink Note 223730.1
• Based on the fixed table X$QESMMIWT.
• Dumping work area table at level 3:SQL> oradebug setmypid
SQL> oradebug dump workareatab_dump 3
• Within the current session with:SQL> alter session set events
'immediate trace name workareatab_dump level 3';
Level Description
1 Only a list of values is dumped
2 Level 1 + work area table with summary information
3 Level 2 + details for all active work areas
Work Area Table DumpDumping Work Area Table (level=3)=====================================
Global SGA Info---------------
global target: 10 MBauto target: 4 MBmax pga: 200 MBpga limit: 0 MBpga limit known: 0pga limit errors: 0
pga inuse: 261 MBpga alloc: 279 MBpga freeable: 0 MBpga freed: 0 MBpga to free: 0
pga auto: 6 MBpga manual: 0 MB
pga alloc (max): 339 MBpga auto (max): 159 MBpga manual (max): 0 MB
# workareas : 18# workareas(max): 43
V$PGASTAT (X$QESMMSGA)
Work Area Table Dump (Contd.)Work Area Table (67 entries)
----------------------------
Entry 0: 0 are active (max=3)
Entry 1: 0 are active (max=3)
...
Entry 62: 1 are active (max=3)
Work area 2FD9B334
wid=0, trcId=-1 sid=130, ser#=1, flags=11 (AUTO|SGA|ADVICE)
qc_sid=65535, qc_instid=65535, slv_grp=1
curSize=488, maxSize=488, #maxPasses=0
tempSegStateObj=00000000, tempSegObjType=0
shared work area descriptor (2F856080):
flags:12 ( AUTO SGA )
opType:9(HASH-JOIN) opId=35 proxy=00000000
isize=1907K, osize=3497K, rowlen=12, flags=01
opt=270, 1pass=4, mpass=9, lastMem=7832KB
maxTempSegSize=4096KB, lastTempSegSize=0KB
Entry 63: 0 are active (max=4)
...
Entry 66: 0 are active (max=3)
Shareddescriptorv$sql_workarea
Current Execution
v$sql_workarea_active
SQL Memory Manager Latches
SQL> ALTER SESSION SET EVENTS 'immediate trace name latches level 1';....03c4fd70 SQL memory manager latch level=1
Location from where latch is held: qesmmIDeamonCb: Context saved from call: 1state=free, wlstate=free
03c4fde8 Parent SQL memory manager workarea list latch level=2 Location from where latch is held: No latch: Context saved from call: 0state=free, wlstate=free
1f265798 Child SQL memory manager workarea list latch level=2 child#=67 Location from where latch is held: qesmmIRefreshBound: Context saved from call: 6state=free, wlstate=free
....
....1f263698 Child SQL memory manager workarea list latch level=2 child#=1
Location from where latch is held: qesmmIRefreshBound: Context saved from call: 6state=free, wlstate=free
...
SQL Memory Manager Latches
WA1
HJ
WAnGROUP
BY
...
Child SQL memory manager workarea list latches (67 – 0..66)
Table Entry 0WA2
HJ
WA3
SORT
WA4
HJ
WA5
HJ
WA6
SORT
Table Entry 1
Table Entry 66
...
QESMM Daemon
• X$MESSAGES (inspired by Jonathan’s post)
SQL> select description, dest
from X$MESSAGES
where description like 'SQL Memory%';
DESCRIPTION DEST
---------------------------------- --------
SQL Memory Management Calculation CKPT
QESMM and X$TRACE
• X$TRACE (inspired by Anjo Kolk’s paper about CI enqueue)
• Added definition in init.ora for buffer size: • _trace_buffers = ALL:2048
SQL> column cur_seq new_value cur_seq
SQL> SELECT MAX(seq#) cur_seq
FROM x$trace;
SQL> SELECT TIME time,data
FROM x$trace
WHERE data LIKE '%SQL Memory%'
AND seq# > &cur_seq
ORDER BY seq#;
X$TRACEThe result from X$TRACE was the following:
TIME DATA
--------- ------------------------------------------------------------------------------------------
9169937 KSBCTI: (CKPT) : (timeout action): acnum=[129] comment=[SQL Memory Management Calculation]
9170239 KSBCTI: (CKPT) : (timeout action): acnum=[129] comment=[SQL Memory Management Calculation]
9170539 KSBCTI: (CKPT) : (timeout action): acnum=[129] comment=[SQL Memory Management Calculation]
9170839 KSBCTI: (CKPT) : (timeout action): acnum=[129] comment=[SQL Memory Management Calculation]
9171140 KSBCTI: (CKPT) : (timeout action): acnum=[129] comment=[SQL Memory Management Calculation]
9171440 KSBCTI: (CKPT) : (timeout action): acnum=[129] comment=[SQL Memory Management Calculation]
9171741 KSBCTI: (CKPT) : (timeout action) : acnum=[129] comment=[SQL Memory Management Calculation]
....
• The time column is reported in centiseconds. • The interval is ~3 seconds.
V$SGASTAT & FIXED SGA
• Memory allocations:
SQL> select * from V$SGASTATwhere name like 'qesm%' or name like 'work area%';
POOL NAME BYTES
------------ -------------------------- -------
shared pool work area tab 271216
.....
SQL> SELECT ksmfsnam name,ksmfstyp "TYPE",
ksmfssiz "SIZE" FROM X$KSMFSV -- fixed SGA
WHERE ksmfsnam LIKE '%qesmm%'
NAME TYPE SIZE
---------------------- --------- ----
...
qesmmISga_ qesmmISg 264
qesmmIdeamon_ ksbsa 8
qesmmwm_ sword 4
...
Event 10319
• With event 10319 we can trace PGA memory allocations and de-allocations.
SQL> alter session set events
'10319 trace name context forever, level 2';
PGA ALLOC used=16108K alloc=16370K sz=0002180 typ=FRE name='callheap'
PGA ALLOC used=16110K alloc=16370K sz=0002180 typ=FRE name='callheap'
...
PGA ALLOC used=15850K alloc=16178K sz=0065476 typ=FRE name='session heap'
PGA ALLOC used=15914K alloc=16242K sz=0065476 typ=FRE name='session heap'
...
PGA FREE used=16108K alloc=16370K sz=0002180 typ=FRE name='callheap'
PGA FREE used=16106K alloc=16370K sz=0002180 typ=FRE name='callheap'
....
PGA FREE used=15978K alloc=16370K sz=0065476 typ=FRE name='session heap'
PGA FREE used=15914K alloc=16370K sz=0065476 typ=FRE name='session heap'
...
_realfree_heap_pagesize_hint
Different PGA Memory Allocation
• Parameter _use_realfree_heap governs memory allocation.
• When set to TRUE then the memory for working areas is allocated as heap 0.
• This means that the memory is allocated as a separate heap and not as a sub-heap of the PGA.
Memory Allocation on Linux
• Output of strace command on Linux:...
mmap2(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_NORESERVE, 7, 0xb4) = 0x40c2f000
mmap2(0x40c2f000, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 7, 0) = 0x40c2f000
mmap2(0x40c3f000, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 7, 0) = 0x40c3f000...
• With MAP_NORESERVE first allocated a virtual address space with no swap space reservation.
• In the subsequent calls memory is mapped in smaller sizes defined by _realfree_heap_pagesize_hint.
• The memory is mapped with MAP_FIXED flag which gives the opportunity to map the virtually memory to a specific process address space.
Global Memory Bound Calculation
• CKPT process re-computes memory bound every 3 seconds (_smm_trace=65535)
qesmmIRefreshBound: enter
Dumping Global SGA descriptor (cnt=48)
PgIu=15M PgAl=(30M, 30M) PgFr=(0,0M,0M) PgAu=(0M, 0M) PgMa=(1M, 0M)
Cache=(0M, 6M) OnePass=(0M, 6M)
Tau=166M Res=546 Bnd=40960 Drift=0 Gcnt=48 Qcnt=0
qesmmIRefreshBound(): advice enable (free=10230 max=269, pos=85)
Making snapshot of work area table (maxElem=110)
new: op=0778B11C ind=0 nbWa=1 qc=65535 #sib=1
End of snapshot (NbElem=1 NbWa=1 totAutoCache=546)
Dumping Global SGA descriptor (cnt=48)
PgIu=15M PgAl=(30M, 30M) PgFr=(0,0M,0M) PgAu=(0M, 0M) PgMa=(1M, 0M)
Cache=(0M, 6M) OnePass=(0M, 6M)
Tau=166M Res=546 Bnd=40960 Drift=0 Gcnt=48 Qcnt=0
qesmmIRefreshBound: exit, don't need to recompute bound
CKPTdemo
BigSort
MonWA
Getting Work Area Size
one
pass
10M
20M
30M
40M
50M
60M
70M
80M
90M
100M
SORT
DOP=2
HJ
DOP=1
SORT
DOP=2
HJ
DOP=8
min
one
pass
one
pass
min
min
Global Memory
Bound
Global Memory
Bound
Global Memory
Bound
one
pass
min
Foreground Bound Recompute
qesmmIRecordDrifting: recording 6489 drift (Tau=4096, Tres=0)
qesmmIRecordDrifting: exit (6489 drift, too much=1)
qesmmIQueryRefreshBound(enter): wi=1EF74AD4 drift=6489
Dumping Global SGA descriptor (cnt=3769)
PgIu=15M PgAl=(29M, 49M) PgFr=(0,0M,0M) PgAu=(0M, 0M) PgMa=(3M, 0M)
Cache=(0M, 29M) OnePass=(0M, 29M)
Tau=4M Res=0 Bnd=409600 Drift=6489 Gcnt=3769 Qcnt=571
We got the latch. State before recompute
qesmmIRecordDrifting: recording 6489 drift (Tau=4096, Tres=0)
qesmmIRecordDrifting: exit (12978 drift, too much=1)
Too much drifting, we need to recompute bound
...
Bound before recompute= 409600kB
Too big drift detected first time.
Memory drift increased again!
Foreground Bound Recompute (Contd.)
qesmmComputeBound: start (nbOp=1, nbWa=1, target=4096 useCap=1
minSz=128, serCap=409600,parCap=5120)
Input TabOp:
bound info (088790FC):
op=HASH-JOIN, min=448, 1pass=6107, cache=6489, capSize=6489, sib=1
Start (it=1): nbWa=1 nbLft=1 bnd=4096 memTg=4096 memLeft=4096
start loop: bi[0]=088790FC mem=4096 nextIncr=64
bi[0]=088790FC lrgest so far
keep bi[0]=088790FC, nextMemLeft=0, pos=0
end loop 1: lft=1 nbWa=1
All use max. We are done
End (it=1): memTg=0 res=4096 memLeft=0
qesmmComputeBound: exit-3: reserved=4096 bound=4096
New bound after recompute= 4096kB (100 times less)
PGA Over-allocations
PG
A A
llocatio
ns
0
10.0
00
20.0
00
30.0
00
40.0
00
50.0
00
60.0
00
02:57.589
02:59.021
03:00.283
03:01.375
03:02.456
03:03.798
03:05.110
03:06.432
03:07.634
03:08.765
03:10.638
03:12.651
03:14.073
03:16.266
03:17.548
03:29.155
03:30.196
03:31.508
03:32.720
03:34.282
03:46.840
03:47.741
03:48.743
03:49.844
03:50.846
03:51.937
03:52.939
03:53.880
03:55.162
03:56.154
Tim
e
Allocated memory (kB)
0 500
1.0
00
1.5
00
2.0
00
2.5
00
Bound (kB)
AU
TO
TA
RG
ET
PG
A_A
LLO
CA
TE
DP
GA
_U
SE
DB
OU
ND
Multi-P
asses Execution
Mu
lti-pa
ss
es
Ex
ec
utio
ns
of 4
co
nc
urre
nt s
es
sio
ns
0
50
0.0
00
1.0
00
.00
0
1.5
00
.00
0
2.0
00
.00
0
2.5
00
.00
0
09:42:59,5
09:43:01,4
09:43:02,3
09:43:02,9
09:43:03,1
09:43:03,5
09:43:03,9
09:43:04,3
09:43:04,8
09:43:05,2
09:43:06,2
09:43:06,8
09:43:07,1
09:43:07,5
09:43:07,8
09:43:08,7
09:43:09,2
09:43:09,7
09:43:09,9
09:43:10,2
09:43:10,6
09:43:11,0
09:43:11,3
09:43:11,5
09:43:11,6
09:43:11,9
09:43:12,3
Tim
e
Memory Allocated (Bytes)
SE
SS
ION
_1
SE
SS
ION
_2
SE
SS
ION
_3
SE
SS
ION
_4
Work area sizes in 9i/10gR1
• Serial operations: _smm_max_size
• min(5% PGA_AGGREGATE_TARGET, 100MB)
• Parallel operations: _smm_px_max_size
• 30% of PGA_AGGREGATE_TARGET / DOP
• DOP stands for degree of parallelism
Limits For Work Area Sizes in 10gR2
• Serial operations• for P_A_T <= 500MB the parameter _smm_max_size = 20% of P_A_T
• for P_A_T between 500MB and 1000MB the parameter _smm_max_size = 100M
• for P_A_T > 1000 MB the parameter _smm_max_size = 10% of P_A_T (upper bound not limited?)
• Parallel operations• limit for parallel operations changed from 30% to 50% of
PGA_AGGREGATE_TARGET / DOP.
• When DOP <=5 then _smm_max_size is used
• when DOP > 5 _smm_px_max_size/DOP limits the maximum memory usage.
• _PGA_MAX_SIZE defaults to 2*_smm_max_size
P_A_T and Related SMM sizes
P_A_T and Related SMM Sizes
0
200
400
600
800
1000
1200
1400
10
90
170
250
330
410
490
570
650
730
810
890
970
1050
1130
1210
1290
1370
1450
1530
1610
1690
1770
1850
1930
2010
2090
2170
2250
2330
2410
2490
P_A_T size in MB
SM
M S
ize in M
B
0,000
0,200
0,400
0,600
0,800
1,000
1,200
1,400
_S
MM
_M
IN_S
IZE
in M
B
_PGA_MAX_SIZE_9iR2/10gR1 _SMM_MAX_SIZE_9iR2/10gR1 _SMM_PX_MAX_SIZE_9iR2/10gR1
_PGA_MAX_SIZE_10gR2 _SMM_PX_MAX_SIZE_10gR2 _SMM_MAX_SIZE_10gR2
_SMM_MIN_SIZE
Anomalies• The only parameter defined is P_A_T in init.ora, no parameters where
changed.
PARAMETER CURRENT
------------------------------ ---------
pga_aggregate_target 3145728
_pga_max_size 629140
_smm_max_size 314570
_smm_px_max_size 1572864
CBO TRACE:
*************************************
PARAMETERS WITH ALTERED VALUES
******************************
_pga_max_size = 629140 KB ????? (20% P_A_T)
************************************
AFTER
-------
4194304
458605 (10.9% P_A_T ???)
229302
2097152
SQL> alter system set pga_aggregate_target=4G;
Bigger Memory Allocations in 10gR2
• Allocation of memory for big sort operation with DOP=5
SQL> SELECT workarea_address, operation_type,
operation_id, actual_mem_used,
max_mem_used, tempseg_size
FROM v$sql_workarea_active
ORDER BY max_mem_used DESC;
WORKAREA_ADDRESS OPERATION_TYPE ACTUAL_MEM_USED MAX_MEM_USED TEMP
---------------- -------------- --------------- ------------ ----
1E37734C SORT (v2) 216162304 216162304
1E37734C SORT (v2) 100427776 100427776
1E37734C SORT (v2) 78235648 78235648
1E37734C SORT (v2) 78106624 78106624
1E37734C SORT (v2) 53011456 53011456
V$PGASTAT (X$QESMMSGA)
SQL> select QESMMSGANM name, QESMMSGAVL value, QESMMSGAMU multip
2 from x$qesmmsga;
NAME VALUE MULTIPLIER
--------------------------------------------------- ----------
aggregate PGA target parameter 3145728 1024
aggregate PGA auto target 2815272 1024
global memory bound 262060 1024
total expected memory 546 1024
drifting from expected memory 0 1024
PGA max size parameter 524120 1024
total PGA inuse 17794 1024
total PGA allocated 442665 1024
maximum PGA allocated 471922 1024
total freeable PGA memory 0 1024
workarea SGA retain size 40 1024
PGA memory freed back to OS 0 1024
percentage freeable memory to be released 0 100
total PGA used for auto workareas 102 1024
maximum PGA used for auto workareas 408091 1024
...
V$PROCESS_MEMORY
• New in 10gR2• Reports the memory usage for the following categories: SQL, PL/SQL,
OLAP, JAVA, Freeable and Other. • The view reports allocated memory in bytes.
SQL> select PID,CATEGORY,ALLOCATED,USED,MAX_ALLOCATED2 from v$process_memory3 where nvl(used,0) > 04* order by MAX_ALLOCATED desc;
PID CATEGORY ALLOCATED USED MAX_ALLOCATED---------- --------------- ---------- ---------- -------------
25 SQL 178172800 178045640 17817280024 SQL 104383328 104280992 10438332835 SQL 15763252 15640196 26414992
...15 PL/SQL 77768 16384 10243614 PL/SQL 79684 16408 79684
...
New Sort Algorithm in 10gR2
• _smm_isort_cap - new in 10.2• Defines the size of work area for old (v1) insertion sort.• The default limit is 100MB.
• _newsort_enabled – new in 10.2 • enables/disables {TRUE|FALSE} new sort algorithm
• The new sort is marked as (v2) sort.
SQL> alter session set "_newsort_enabled"=FALSE;
SQL> select c1 from t_big2 t order by c1;
OPERATION_TYPE ACTUAL_MEM_USED MAX_MEM_USED TEMPSEG_SIZE-------------- --------------- ------------ ------------SORT (v1) 102318080 102318080 19922944
SQL> alter system set "_smm_isort_cap"= 262060;
SQL> select c1 from t_big2 t order by c1;
OPERATION_TYPE ACTUAL_MEM_USED MAX_MEM_USED TEMPSEG_SIZE-------------- --------------- ------------ ------------SORT (v1) 265445376 265445376 9437184
Index Creation in 10gR1
create index t_big_i1 on t_big(normal) compute statistics
call count cpu elapsed disk query current rows
------- ------ ------ -------- ----- ------ -------- -----
Parse 1 0.00 0.00 0 2 0 0
Execute 1 20.96 34.94 4009 4050 2620 0
Fetch 0 0.00 0.00 0 0 0 0
------- ------ ------ -------- ----- ------ -------- -----
total 2 20.96 34.95 4009 4052 2620 0
V$MYSTAT:
NAME VALUE
------------------------------- ----------
session uga memory 217648
session uga memory max 42049144
session pga memory 825932
session pga memory max 43817548
Index Creation in 10gR2create index t_big_i1 on t_big(normal) compute statistics
call count cpu elapsed disk query current rows------- ------ ----- -------- ----- ------ -------- -----Parse 1 0.01 0.05 0 2 0 0Execute 1 3.86 19.12 3178 4103 3253 0Fetch 0 0.00 0.00 0 0 0 0------- ------ ----- -------- ----- ------ -------- -----total 2 3.87 19.17 3178 4105 3253 0
NAME VALUE------------------------------- ----------session uga memory 352672session uga memory max 29549616session pga memory 646740session pga memory max 30989908
NAME VALUE
------------------------------- ----------
session uga memory 201748
session uga memory max 298740
session pga memory 327368
session pga memory max 30801608
Dedicated server
Shared server
Old Sort Versus New Sort
Results of comparison for index creation
Parameter 10gR1 10gR2 Difference % Diff
CPU time 20.96 3.86 17.10 -81.6%
session uga memory max (bytes) 42,049,144 29,549,616 12,499,528 -29.7%
session pga memory max (bytes) 43,817,548 30,989,908 12,827,640 -29.3%
workarea max size (bytes) 36,611,072 28,819,456 7,791,616 -21.3%
Conclusions
• Automatic memory management better utilizes available memory.
• Suitable for OLTP, in DSS for only one or several batch processes still use MANUAL policy at session level for huge memory requirements.
• In 10gR2 sizing policy is more aggressive and most likely more suitable for greedy SQL operators.
• Maximum sizes of work areas are floating and require further investigation.
SORT Operations - FYI
1. BITMAP CONSTRUCTION2. BITMAP MERGE3. BUFFER4. CONNECT-BY (SORT)5. DST BITMAP COUNTING - Decision Tree Bitmap Counting6. FIC BITMAP ANDING7. FIC GENERATE CANDIDATE8. FIC LOAD SNAKES9. FIC LOAD TRANSACTIONS10. FIC TREE COUNTING11. GROUP BY (HASH)12. GROUP BY (SORT)13. HASH-JOIN14. IDX MAINTENANCE (SORT)15. LOAD WRITE BUFFERS16. ROLLUP (SORT)17. SORT18. SORT (V1)19. SORT (V2)20. SPREADSHEET - Supports a SQL MODEL operation (formerly known as SQL SPREADSHEET).21. WINDOW (SORT)
Support Frequent Itemset Counting
(DBMS_FREQUENT_ITEMSET package)
Source: Julian Dyke
References
1. Dageville, Benoît and Zait, Mohamed, »SQL Memory Management in Oracle9i«, Proceedings of the 28th VLDB
Conference, Hong Kong, China, 2002
2. Kumar, Sushil: »Oracle9i Memory Management: Easier Than Ever«, Oracle Open World 2002,
[http://www.oracle.com/technology/products/manageability/database/pdf/OOW2002MemMgmtV2.pdf]
3. Kutrovsky, Christo, »Working with Automatic PGA«,
[http://www.pythian.com/documents/Working_with_Automatic_PGA.ppt]
4. Ramaswamy, Ramesh: »Optimising Oracle9i Instance Memory«,
[http://www.quest.com/presentations/Optimising_Oracle9i_Instance_Memory.pdf ]
5. Poder, Tanel: »Memory Management and Latching Improvements in Oracle Database 9i and 10g«, Oracle Open
World 2005, [https://www35.cplan.com/cv_106/sessions_catalog.jsp]
6. Lewis, Jonathan: »Undocumented secrets – or untested fairytales ?«, [http://www.jlcomp.demon.co.uk/untested.html]
7. Lewis, Jonathan: »The Snark research mechanism ?«, [http://www.jlcomp.demon.co.uk/snark.html]
8. Dyke, Julian, Diagnostics and Dumping commands, [http://www.juliandyke.com]
9. Shee, Richmond: »If Your Memory Serves You Right…«, IOUG Live! 2004, April 2004, Toronto, Canada
[http://download-uk.oracle.com/oowsf2004/1080.pdf]
References
1. Oracle Metalink Note 223730.1 »Automatic PGA Memory Managment in 9i«[http://metalink.oracle.com/metalink/plsql/showdoc?db=NOT&id=223730.1]
2. Oracle Metalink Note 147806.1 »Oracle9i New Feature: Automated SQL Execution Memory Management« [http://metalink.oracle.com/metalink/plsql/showdoc?db=NOT&id=147806.1]
3. Oracle Metalink Note 148346.1 »Oracle9i Monitoring Automated SQL Execution Memory Management« [http://metalink.oracle.com/metalink/plsql/showdoc?db=NOT&id=148346.1]
4. Patch 3130972 »ENH: Allow over 1Gb private memory in realfree allocator«[http://metalink.oracle.com/metalink/plsql/showdoc?db=NOT&id=3130972.8]
5. An Oracle White Paper : »Sort Performance Improvements in Oracle Database 10g Release 2«, June 2005, [http://www.oracle.com/technology/products/bi/db/10g/pdf/twp_general_sort_performance_10gr2_0605.pdf]
6. An Oracle White Paper : »DSS Performance in Oracle Database 10g Release 2«, July 2005, [http://www.oracle.com/technology/deploy/performance/pdf/twp_dss_performance_with_10gr2.pdf]
Q&A
Thank you for your interest!
Please, fill the evaluation forms!
• Session Details:
• Speaker: Joze Senegacnik
• Title: Advanced Management Of Working Areas In Oracle 9i/10g
• Session#: 411