Applies to:
Oracle Server – Enterprise Edition – Version: 9.2.0.1 to 11.2.0.2
Information in this document applies to any platform.
Goal
The 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.
Solution
What is a memory granule
When 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 determined
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:
| 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 *) | < 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 size
You 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 important
The SGA memory components are sized as multiples of granules.
The components are:
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, 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.
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.
© 2009, www.oracledatabase12g.com. 版权所有.文章允许转载,但必须以链接方式注明源地址,否则追究法律责任.
相关文章 | Related posts:
最新评论