1 / 44

Memory Management

Memory Management. Objectives. At the end of this section, you should be able to: Identify the different memory areas that are used by the Oracle server Explain how and when those areas are allocated Describe the architecture of a memory heap

iola-norman
Download Presentation

Memory Management

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Memory Management

  2. Objectives • At the end of this section, you should be able to: • Identify the different memory areas that are used by the Oracle server • Explain how and when those areas are allocated • Describe the architecture of a memory heap • List the algorithms that are used to manage memory

  3. Memory Areas • System global area (SGA) • Process memory areas: • Process global area (PGA) • User global area (UGA) • Call global area (CGA)

  4. System Global Area • The SGA consists of: • Fixed area • Variable area • Database buffer cache • Redo log buffer • Shared pool

  5. Dynamic SGA Memory Allocation • The size of the SGA components is now dynamic. • The size of each component is rounded up to a memory page boundary. • SGA components may grow until SGA_MAX_SIZE is reached. • Parameters controlling the SGA size include: • DB_CACHE_SIZE • LOG_BUFFER • SHARED_POOL_SIZE • LARGE_POOL_SIZE

  6. Granule Size • In Oracle9i the basic allocation unit of the SGA is a granule. • Granule size is based on the SGA_MAX_SIZE parameter • If greater than 128Mb, granule size is 16Mb • If less than 128Mb, granule size is 4Mb • If SGA_MAX_SIZE is not set, the value is derived from the sum of original values of all components • The SGA is allocated, grown, and shrunk on granule boundaries.

  7. Granule Memory Manager • KSMG is the granule memory manager • A granule can be in one of three states: • Free • Initialized • Allocated • At startup, each component registers with KSMG • Granule/component associations can be seen by querying X$KSMGV. • Any granule will contain a buffer and its corresponding buffer header

  8. SGA and Shared Memory • The database uses shared memory to function more efficiently. • Oracle processes use shared memory to access data without excessive paging. • The processes use semaphores to read or write a shared memory address exclusively.

  9. Configuring Shared Memory • Shared memory configuration is platform specific: • Solaris: /etc/system • HPUX: /stand/system • Linux: /usr/src/linux/include/asm/shmparam.h, /usr/src/linux/include/linux/sem.h • For a complete platform list, see WebIV Note: 169706.1.

  10. SGA Shared Memory Allocation • The Oracle server uses three possible memory models for SGA allocation: • Single segment • Contiguous multisegment • Noncontiguous multisegment • The entire SGA must fit into shared memory.

  11. Fixed Area • The fixed area contains: • Many small variables of fixed size • Pointers to large or variable size variables • The table X$KSMFSV provides the name, type, size, and memory address for the variables in this area. • Use oradebug to obtain the variable’s value.

  12. Database Block Buffers • Size determined by two parameters: • DB_BLOCK_BUFFERS • DB_BLOCK_SIZE • This area only contains the buffers. • The control information is in the variable area. • Buffer headers • Working set headers (LRU and LRUW) • Hash chain headers

  13. Redo Buffers • The parameter LOG_BUFFER determines memory size. • Two guard pages protect this memory area. • The operating system traps any illegal access attempt. • This prevents accidental corruption of the redo records. Log Buffer Guard Pages

  14. Variable Area • The variable area is divided into three pools: • The shared pool • Library cache • Row cache • Permanent memory • The Large pool • The Java pool

  15. Heaps and Subheaps • Memory areas are organized as heaps. • Physically, a memory heap consists of: • A header or heap descriptor • One or more extents • Logically, a heap may contain subheaps. • The extents in the subheap are allocated from the parent heap. • Heaps and subheaps have free lists and LRU lists to manage free and used space.

  16. More on Subheaps • Subheaps can limit fragmentation within the parent heap. • Often memory that would be temporarily allocated in a parent heap can be allocated from a subheap. • Subheaps allow shared memory that is attached by a single process to be accessed without a latch. • Subheaps may be pinned or unpinned.

  17. The Shared Pool • The shared pool is organized as a heap and consists of: • A permanent memory area • Stores data structures • Size dependent on many parameters • A dynamically managed memory area • Stores the library and row caches • Size is determined by SHARED_POOL_SIZE

  18. Allocation Classes • Space in the shared pool is divided into chunks: • Each chunk has a header. • Chunks can be of any size. • Listed in X$KSMSP • Each chunk belongs to an allocation class: • Freeable • Re-creatable • Freeable with a mark • Permanent • A chunk can also be free (unallocated).

  19. Allocation Classes Viewed in X$KSMSP SQL> select ksmchcom, ksmchcls, ksmchsiz from x$ksmsp; KSMCHCOM KSMCHCLS KSMCHSIZ ---------------- -------- ---------- library cache freeabl 332 sql area freeabl 2292 KGL handles recr 304 library cache freeabl 96 KGL handles recr 320 library cache recr 240 library cache freeabl 96 KGL handles recr 320 library cache recr 240 library cache freeabl 560 multiblock rea freeabl 2072 ...

  20. Chunk Allocation: Free Lists • When space is requested, the heap manager searches for a free chunk of the exact size. • Free chunks are organized on free lists according to size. • If an exact chunk is not available, then the best fit is found and split. • If all the free lists are empty, then the heap manager searches for a suitable re-creatable chunk. • Re-creatable chunks are organized on LRU lists.

  21. Chunk Allocation: LRU Lists • There are two LRU lists of inactive chunks: • Transient: likely not to be needed again • Recurrent: likely to be needed again soon • If free chunks are not available, then chunks are freed from these lists alternatively. • Start with the transient list. • Look for unpinned re-creatable chunks. • Free eight chunks at a time before alternating to the other list. • Stop when a large enough chunk is found.

  22. Chunk Allocation: Hidden Free Memory • If the previous strategies fail to find a suitable chunk, then hidden free memory is released. • Half the shared pool memory allocation is hidden at startup. • This memory is not on the free lists. • It is hidden as a permanent memory allocation. • It is released on a need basis. • This memory is not recovered after it is used.

  23. The Reserved Pool • The reserved pool is actually part of the shared pool. • It is sized with SHARED_POOL_RESERVED_SIZE. • It defaults to 5% of SHARED_POOL_SIZE. • It is reserved for chunks that are larger than a threshold. • The threshold can be set with the parameter _SHARED_POOL_RESERVED_MIN_ALLOC. • The threshold defaults to 5000 bytes. • This area is often not used and therefore wasted.

  24. Keeping Objects • If objects are used only intermittently, then they may be flushed out of the shared pool. • Some re-creatable objects are very expensive to re-create. • Sometimes it is undesirable to flush freeable objects like sequences. • It is possible to mark valuable objects to prevent them from being flushed out. • Use DBMS_SHARED_POOL.KEEP after instance startup.

  25. Flushing the Shared Pool • This is the only way to coalesce the shared pool. • It should be performed: • To reduce long-term shared pool latch contention • To reduce the risk of ORA-4031 errors • However, consider the following points: • May cause gaps in sequences • Causes reloads of objects that were not kept, which increases short-term shared pool latch contention

  26. The Large Pool • Size determined by LARGE_POOL_SIZE • Allocations are protected by the shared pool latch. • Configure if any of these options are implemented: • Oracle Shared Server • Recovery Manager • Parallel Query • Use V$SGASTAT to monitor: SQL> select * from v$sgastat; POOL NAME BYTES ----------- --------------------- ---------- fixed_sga 454740 buffer_cache 4194304 ... large pool free memory 12582912 java pool free memory 12582912

  27. The Java Pool • Size is determined by JAVA_POOL_SIZE. • It is also a separate heap from the shared pool. • The memory is allocated dynamically. • Allocations are protected by the shared Java pool latch. • It should only be configured if the applications use the Java Virtual Machine (JVM).

  28. Process Global Area • The PGA is part of the process private memory. • Each server process has its own PGA. • The PGA is only used for process-specific information. • It has two components: • Fixed PGA (data and control files) • Variable PGA (UGA and CGA subheaps) • PGA heap information can be seen in X$KSMPP.

  29. User Global Area • Session-specific information • Two components: • Fixed UGA • Variable UGA (private SQL and PL/SQL areas, open cursors and links, enabled roles and events, and so on) • The UGA is part of: • The PGA when using dedicated servers • The SGA when using shared servers • UGA heap information can be seen in X$KSMUP.

  30. Call Global Area • The CGA contains call-specific information. • It is deallocated at the end of the call. • Required for: • Parse, execute, and fetch calls • Recursive SQL and PL/SQL calls • The CGA stores only temporary data: • Direct I/O buffers • Stack space for expression evaluation • The CGA is always a subheap of PGA.

  31. Heap Dumps • Heap dump command: • The level determines which heap/s to dump: • Level 1: PGA • Level 2: SGA • Level 4: UGA • Level 8: Current call (CGA) • Level 16: User call (CGA) • Level 32: Large pool SQL> alter session set events 2 'immediate trace name heapdump level n';

  32. Subheap Dumps • Subheap dump command: • The level determines which subheap to dump based on its address. • The address of the subheap is obtained from a dump of the parent heap. SQL> alter session set events 2 'immediate trace name heapdump_addr level n';

  33. Summary • In this lesson, you should have learned about: • The different types of memory • System global area • Process memory areas • The architecture of a memory heap • The algorithms that are used to manage memory resources • Dumping memory heaps

  34. References • WebIV Notes: 35084.1, 39686.1, 43143.1, 45092.1, 47392.1, 47632.1, and 61866.1 • Oracle8i Internal Services for Waits, Latches, Locks, and Memory by Steve Adams • Source Code: kgh.h, kgh.c, ksm.c

More Related