The 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:
三，内存粒度查询
You can check the granule size that is currently set for your database instance by running the following SQL statement as SYSDBA
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.
四，内存粒度的重要性
The 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:
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").
(It is possible the number of durations may change in 12g.)
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.
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.