Senegacnik PGA Memory Management Oracle9i 10g

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

[email protected]

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


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)


...


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


...


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]






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)





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





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

Date post:	11-Apr-2015
Category:	Documents
Upload:	alex-zhirov
View:	2,570 times
Download:	5 times

Senegacnik PGA Memory Management Oracle9i 10g

Documents