How To Determine Granule Size (文档 ID 947152.1)

郑全

In this Document

Goal

Solution

What is a memory granule

How is the granule size determined

How to find the Granule size

Why is granule size important

References

---

Applies to:   Oracle Database - Enterprise Edition - Version 9.2.0.1 to 12.1.0.2 [Release 9.2 to 12.1]
Oracle Database - Standard Edition - Version 11.2.0.3 to 12.1.0.2 [Release 11.2 to 12.1]
Information in this document applies to any platform.

GoalThe goal of this document is to establish the manner in which Oracle sets the granule size for memory management, and the significance of granule sizing.
SolutionWhat is a memory granuleWhen a database instance starts up, the amount of memory allocated is determined by the allocations requested in the parameter file (init file or spfile).  This memory is allocated in units called granules. All memory pool sizes will be allocated in multiples of the granule size.
How is the granule size determinedThe granule size is determined based on the amount of memory requested at the instance startup. It is based on the SGA_MAX_SIZE.  If MEMORY_MAX_TARGET is specified, then SGA_MAX_SIZE defaults to MEMORY_MAX_TARGET for the purpose of sizing the granule.  Once set, the granule size does not change for the life of the instance.

The granule sizes at the time of writing, are:

RDBMS	SGA_MAX_SIZE (or memory_max_target)	GRANULE SIZE
9.2	<= 128MB	4MB
	> 128MB	16MB
10.2	<= 1GB	4MB
	> 1GB	16MB
11gR1	<= 1GB	4MB
	>1Gb   <= 4GB	16MB
	>4Gb   <= 16GB	64MB
	>16Gb <= 64GB	256MB
	> 64GB	512MB
11gR2 (and 11gR1 with patch  8813366 applied *) and later	<= 1Gb	4Mb
	>1Gb   <= 8Gb	16Mb
	>8Gb   <= 16Gb	32Mb
	>16Gb <= 32Gb	64Mb
	>32Gb <= 64Gb	128Mb
	>64Gb <= 128Gb	256Mb
	> 128Gb	512Mb

* The granule size changes in Unpublished Bug 8813366 can be backported to 11gR1.
How to find the Granule sizeYou can check the granule size that is currently set for your database instance by running the following SQL statement as SYSDBA
-- You can determine your granule size with this SQL
SQL> select bytes from v$sgainfo where name like 'Granule Size';

There is a 16MB granule size maximum on 32-bit platforms. This applies even if the granule size is manually overridden.
Why is granule size importantThe SGA memory components are sized as multiples of granules.
The components are:

• shared pool
• buffer cache (plus different size buffer caches)
• redo log buffer
• java pool
• streams pool
• large pool
  

There can be no component of size less than one granule. The minimum of some components can be greater than one granule (and rounded up to the nearest granule boundary).  For example the Buffer Cache minimum will be 4MB*num_cpus, and can exceed 1 granule.

If you set a value in the spfile that is not a multiple of the granule size, the actual size allocated will be rounded up to the nearest granule. This can become important in large SGA's.

For example, if your SGA in 11GR1 is 70G, and you set the java_pool_size to 150M in the spfile, the actual allocation for the java_pool_size will be rounded up to 512M.

The significance of this granule sizing is the following:
Consider a very large SGA on servers with many processors.
The SGA (actually shared, streams and large pool) gets divided in subpools, a maximum of 7 depending on the number of processors and the SGA size.
Typically, 16 processors (cores) will have 4 subpools, 24 processors will have 6 subpools, and 25 or more processors will have 7 subpools.  The number of subpools is derived by an internal algorithm.

In addition, in 10g and 11g, the shared pool and streams pool subpools are further divided into 4 'durations' ("instance", "session", "cursor", and "execution").  

So with over 24 processors, there would be 28 subpools in the shared pool and likely another 28 in the streams pool, each with a minimum of 1 granule.

If you add to that the granules for the other SGA pools, the memory usage could be over 60 granules even before any memory component exceeds 1 granule in size.

If the derived granule size is 256MB, the resulting memory requirement becomes over 15 GB just to start up the instance. This scenario can cause an ORA-4031 during or soon after startup.

Oracle Support can usually offer solutions to this by manually reducing the granule size or by reducing the processor count used in the subpool algorithm.

The patch for unpublished Bug 8813366 reduces the granule sizing to help offset this error.

Starting Oracle release 12.1.0.1 Release, an enhancement to group durations has been made to allow better shareability of the memory (granule movement) and help avoid ORA-4031 errors. This enhancement groups the shared pool durations in 2 groups: (1) instance, session, and cursor (2) instance and session


Another place where granule sizes are taken into consideration, is with Automatic Shared Memory Management (ASMM) in 10g, and Automatic Memory Management (AMM) in 11g.

As memory pressures rise on the Shared Pool, instead of a ORA-4031, the memory auto-tuner in ASMM (or AMM) will go to the Buffer Cache and transfer memory to the Shared Pool to fill the required need. This memory transfer is also done in granules. So with large SGA sizes, it is possible that a transfer of memory will not occur unless there is 256M or 512M of memory available to be transferred. If at least one granule is not available, an ORA-4031 will occur.

References

NOTE:260171.1 - How SGA_MAX_SIZE Parameter Works

NOTE:266702.1 - About Dynamic SGA Sizing
NOTE:455179.1 - How To Determine The Default Number Of Subpools Allocated During Startup
NOTE:8857940.8 - Bug 8857940 - Enhancement to group durations to help reduce chance of ORA-4031