修改时间 10-MAR-2011 类型 HOWTO 状态 PUBLISHED
In this Document
What is a memory granule
How is the granule size determined
How to find the Granule size
Why is granule size important
Applies to:Oracle Server - Enterprise Edition - Version: 188.8.131.52 to 184.108.40.206 - Release: 9.2 to 11.2Information 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.
What 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:
* The granule size changes in Unpublished Bug 8813366 can be backported to 11gR1.
|RDBMS||SGA_MAX_SIZE (or memory_max_target)||GRANULE SIZE|
|>1Gb <= 4GB||16MB|
|>4Gb <= 16GB||64MB|
|>16Gb <= 64GB||256MB|
|11gR2 (and 11gR1 with patch 8813366 applied *)||<= 1Gb||4Mb|
|>1Gb <= 8Gb||16Mb|
|>8Gb <= 16Gb||32Mb|
|>16Gb <= 32Gb||64Mb|
|>32Gb <= 64Gb||128Mb|
|>64Gb <= 128Gb||256Mb|
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 There is a 16MB granule size maximum on 32-bit platforms. This applies even if the granule size is manually overridden.
SQL> select bytes from v$sgainfo where name like 'Granule Size';
Why is granule size importantThe SGA memory components are sized as multiples of granules.The components are:
Shared 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:
buffer cache, (plus different size buffer caches)
redo log buffer,
Consider a very large SGA on servers with many processors.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.
The SGA (actually shared, java, 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.
ReferencesNOTE:260171.1 - How SGA_MAX_SIZE Parameter WorksNOTE:455179.1 - How To Determine The Default Number Of Subpools Allocated During Startup
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/38267/viewspace-713686/，如需转载，请注明出处，否则将追究法律责任。