ITPub博客

首页 > Linux操作系统 > Linux操作系统 > How to determine granule size [ID 947152.1]

How to determine granule size [ID 947152.1]

原创 Linux操作系统 作者:spider0283 时间:2011-12-21 12:03:24 0 删除 编辑

修改时间
 10-MAR-2011     类型 HOWTO     状态 PUBLISHED
 

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 Server - Enterprise Edition - Version: 9.2.0.1 to 11.2.0.2 - Release: 9.2 to 11.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: 
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, 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.

References

NOTE:260171.1 - How SGA_MAX_SIZE Parameter Works
NOTE:455179.1 - How To Determine The Default Number Of Subpools Allocated During Startup

显示相关信息 相关内容


产品
  • Oracle Database Products > Oracle Database > Oracle Database > Oracle Server - Enterprise Edition
关键字
V$SGAINFO; AUTOMATIC SHARED MEMORY MANAGEMENT; LARGE POOL; JAVA POOL; CACHE; SHARED POOL; BUFFER CACHE
错误
ORA-4031; ORA-64

返回页首返回页首

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/38267/viewspace-713686/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2011-03-29

  • 博文量
    194
  • 访问量
    611472