System Global Area (SGA) Overview

Figure 7–1 Oracle Memory Structures

System Global Area

Software Code Areas are another basic memory structure, discussed on page 7-22.

See Also:

System Global Area (SGA) Overview

A system global area (SGA) is a group of shared memory structures that contain data and control information for one Oracle database instance. If multiple users are concurrently connected to the same instance, then the data in the instance’s SGA is shared among the users. Consequently, the SGA is sometimes called the shared global area.

An SGA and Oracle processes constitute an Oracle instance. Oracle automatically allocates memory for an SGA when you start an instance, and the operating system reclaims the memory when you shut down the instance. Each instance has its own SGA.

Memory Architecture 7-3

System Global Area (SGA) Overview

The SGA is read/write. All users connected to a multiple-process database instance can read information contained within the instance’s SGA, and several processes write to the SGA during execution of Oracle.

The SGA contains the following data structures:

Part of the SGA contains general information about the state of the database and the instance, which the background processes need to access; this is called the fixed SGA. No user data is stored here. The SGA also includes information communicated between processes, such as locking information.

If the system uses shared server architecture, then the request and response queues and some contents of the PGA are in the SGA.

See Also:

Dynamic SGA

With the dynamic SGA infrastructure, the size of the buffer cache, the shared pool, the large pool, and the process-private memory can be changed without shutting down the instance.

Dynamic SGA allows Oracle to set, at run time, limits on how much virtual memory Oracle uses for the SGA. Oracle can start instances underconfigured and allow the instance to use more memory by growing the SGA components, up to a maximum of SGA_MAX_SIZE. If SGA_MAX_SIZE specified in the initialization parameter file is less than the sum of all components specified or defaulted at initialization time, then the setting in the initialization parameter file is ignored.

7-4 Oracle9i Database Concepts

System Global Area (SGA) Overview

For optimal performance in most systems, the entire SGA should fit in real memory. If it does not, and if virtual memory is used to store parts of it, then overall database system performance can decrease dramatically, because portions of the SGA are paged (written to and read from disk) by the operating system. The amount of memory dedicated to all shared areas in the SGA also has performance impact.

The size of the SGA is determined by several initialization parameters. The following parameters most affect SGA size:

LARGE_POOL_SIZE The size of the large pool; the default is 0.

The memory allocated for an instance’s SGA is displayed on instance startup when using Enterprise Manager or SQL*Plus. You can also display the current instance’s SGA size using the SQL*Plus SHOW statement with the SGA clause.

Dynamic SGA Granules

With dynamic SGA, the unit of allocation is called a granule. Components, such as the buffer cache, the shared pool, the java pool, and the large pool, allocate and free SGA space in units of granules. Oracle tracks SGA memory use in integral numbers of granules, by SGA component. All information about a granule is stored in a corresponding granule entry. Oracle maintains the state of each granule in the granule entry and the granule type.

Granule size is determined by total SGA size. On most platforms, the size of a granule is 4 MB if the total SGA size is less than 128 MB, and it is 16 MB for larger SGAs. There may be some platform dependency, for example, on 32-bit Windows NT, the granule size is 8 MB for SGAs larger than 128 MB.

The granule size that is currently being used for SGA can be viewed in the view V$SGA_DYNAMIC_COMPONENTS. The same granule size is used for all dynamic components in the SGA.

Memory Architecture 7-5

System Global Area (SGA) Overview

Note: If you specify a size for a component that is not a multiple of granule size, then Oracle rounds the specified size up to the nearest multiple. For example, if the granule size is 4 MB and you specify DB_CACHE_SIZE as 10 MB, you will actually be allocated 12 MB.

Oracle keeps information about the components and their granules in a scoreboard. For each component that owns granules, the scoreboard contains the number of granules allocated to the component, any pending operations against this component, the target size in granules, and the progress made toward the target size. The start time of the operation is also logged. Oracle maintains the initial number of granules and the maximum number of granules for each component.

For operations that modify the number of granules, Oracle logs the operation, the target size, and the start time to the appropriate SGA component in the scoreboard. Oracle updates the progress field until the operation is complete. When the operation is complete, Oracle replaces the current size with the target size and clears the target size field and the progress field. At the end of the operation, a database administrator can see how the number of granules was changed. Oracle updates the initialization parameter values to reflect the updated amount of SGA in use.

Oracle maintains a circular buffer of the last 100 operations made to the scoreboard. Fixed views show the state of the scoreboard and the current contents of last 100 operations to the scoreboard.

Allocating Granules at Startup At startup, Oracle reads the values in the initialization parameter file, queries the operating system memory limits, and allocates virtual address space for the SGA. The initialization parameter SGA_MAX_SIZE specifies the maximum size of the SGA for the life of the instance in bytes. Its value is rounded up to the next granule size.

Adding Granules to Components A database administrator grows a component’s SGA use with ALTER SYSTEM statements to modify the initialization parameter values. Oracle takes the new size, rounds it up to the nearest multiple of 16MB, and adds or takes away granules to meet the target size. Oracle must have enough free granules to satisfy the request. If the current amount of SGA memory is less than SGA_MAX_ SIZE, then Oracle can allocate more granules until the SGA size reaches SGA_MAX_ SIZE.

7-6 Oracle9i Database Concepts