KGH: NO ACCES是什么及 ORA-4031

共享池中标记为“KGH：NO ACCESS”的内存组件由缓冲区缓存使用。

当通过设置 SGA_TARGET 参数启用 ASMM（自动共享内存管理）时，可以看到该组件的值增加。

启用 ASMM 后，Oracle 将根据需要动态管理可调池之间的内存分配。

请注意，当启用 ASMM 时，仍然可以为每个可调参数（即共享池、数据库缓冲区缓存、大型池、Java 池和流池）指定一个值。当为每个可调参数设置{BANNED}{BANNED}最佳佳小值时，Oracle 将确保分配给相应池的内存量不会缩减到指定量以下。

因此，通过为共享池和数据库缓冲区缓存设置{BANNED}{BANNED}最佳佳xiao值，我们将确保可用于在两个池之间重新分配的内存量较少，从而防止此“KGH：NO ACCESS”组件的增长。

为了防止此组件的增长，您可以

o 禁用 ASMM

- 或 -

o 设置共享池和数据库缓冲区缓存的{BANNED}{BANNED}最佳佳小值

free -h

col name for a40
col value for a10
select nam.ksppinm NAME, val.KSPPSTVL VALUE from x$ksppi nam, x$ksppsv val
where nam.indx = val.indx and nam.ksppinm like '%shared_pool%' order by 1;

select name,round(bytes/1024/1024)m from v$sgainfo;

--排查ora-4031问题，不要在业务高峰期执行
SELECT KSMCHCLS CLASS, COUNT(KSMCHCLS) NUM, round(SUM(KSMCHSIZ/1024/1024)) SIZE_MB, To_char( ((SUM(KSMCHSIZ)/COUNT(KSMCHCLS)/1024)),'999,999.00')||'k' "AVG SIZE" FROM X$KSMSP GROUP BY KSMCHCLS order by 1 desc;
class 分别是：普通sub pool的PERMANENT, FREEABLE, or RECREATABLE 内存和Reserve pool的PERMANENT, FREEABLE, or RECREATABLE 内存分类。

 
加注：
当一个内存块被分配到内存池中时，它会被赋予一个内存类型，包括 PERMANENT，FREEABLE 或者 RECREATABLE。这些内存块之后会被赋予一种池中的内存结构或者元素。例如"KGLS heap"。这些内存结构或元素并不总是会在数据字典中被追踪或者注释（特别是 PERMANENT 类型的那些）。

块的类型：

Normal (freeable) chunks – 这些块所分配的方式使得当内存处理结束时，用户可以显式的释放内存块。

Free chunks – 这些块是空闲的，当有小于或等于块大小的请求进入池中时，就可以重用。

Recreatable chunks – 这是一种特殊形式的"freeable"内存。当它们没有被 pin 的时候，这些块放在 LRU 列表里。如果需要内存，我们会到 LRU 列表内释放一段时间没有使用的“Recreatable”内存。

Permanent chunks – 这些块以不同的方式分配。一些块分配后会在实例的整个生命周期中存在。一些块分配后只要可用，会被内部反反复复的使用。

通过设置事件，可以把 permanent 块标注为其它类型的内存块来进行调试。

set pages 100
break on KSMCHIDX skip 1
 SELECT KSMCHIDX,KSMCHDUR, KSMCHCLS CLASS, COUNT(KSMCHCLS) NUM, SUM(KSMCHSIZ) SIZ,
 To_char( ((SUM(KSMCHSIZ)/COUNT(KSMCHCLS)/1024)),'999,999.00')| |'k' "AVG SIZE"
 FROM X$KSMSP GROUP BY KSMCHIDX,KSMCHDUR, KSMCHCLS order by 1,2,3;

col SGA_HEAP for a22
select 'sga heap('||KSMCHIDX||',0)'sga_heap,ksmchcom ChunkComment,
decode(round(ksmchsiz/1000),0,'0-1K', 1,'1-2K', 2,'2-3K',
3,'3-4K',4,'4-5K',5,'5-6k',6,'6-7k',7,'7-8k',8,'8-9k', 9,'9-10k','> 10K') "Size",
count(*), ksmchcls "Status", sum(ksmchsiz) "Bytes" from x$ksmsp
where KSMCHCOM = 'free memory' group by 'sga heap('||KSMCHIDX||',0)',
ksmchcom, ksmchcls, decode(round(ksmchsiz/1000),0,'0-1K', 1,'1-2K', 2,'2-3K',
 3,'3-4K',4,'4-5K',5,'5-6k',6,'6-7k',7,'7-8k',8,'8-9k', 9,'9-10k','> 10K') order by 1,2;

` KGH: NO ACCESS `是指在ASMM中传输的颗粒，即内存从共享池重新分配到数据库缓冲缓存，反之亦然。
这个在共享池中标记为“KGH: NO ACCESS”的内存组件由缓冲缓存使用。
当通过设置SGA_TARGET参数启用ASMM(自动共享内存管理)时，可以看到该组件的值在增加。
当ASMM启用时，Oracle将根据需求动态管理可调内存池之间的内存分配。
请注意，当启用ASMM时，仍然可以为每个可调参数指定一个值，即共享池、数据库缓冲区缓存、大池、Java池和流池。当为每个可调参数设置{BANNED}{BANNED}最佳佳xiao值时，Oracle将确保分配给相应池的内存数量不会缩小到指定的数量以下。
因此，通过为共享池和数据库缓冲区缓存设置{BANNED}{BANNED}最佳佳xiao值，我们将确保在两个池之间重新分配可用的内存数量将更少，从而防止此` KGH: NO ACCESS `组件的增长。

原文：

'KGH: NO ACCESS' refers to granules that are in transit with ASMM i.e memory being reassigned from the Shared Pool to the Database Buffer Cache and vice-versa.

This memory component in the Shared Pool marked as 'KGH: NO ACCESS' is used by the Buffer Cache.

One could see the value for this component increasing when ASMM (Automatic Shared Memory Management) is enabled by setting the SGA_TARGET parameter.

When ASMM is enabled, Oracle will dynamically manage the memory allocations between the tunable pools based on the requirement.

Note that one can still specify a value for the each of the tunable parameters i.e Shared Pool, Database Buffer Cache, Large Pool, Java Pool and Streams Pool when ASMM is enabled. When minimum value for each of the tunable parameters is set, Oracle will make sure that the amount of memory being allocated for the corresponding pool will not shrink below the specified amount.

Thus by setting minimum value for the Shared Pool and Database Buffer Cache, we will be ensuring that the amount of memory available for reassignment between the two pools will be lesser thus preventing the growth of this 'KGH: NO ACCESS' component.

To prevent the growth of this component you can either

o  Disable ASMM

- OR -

o Set the minimum values for the Shared Pool and the Database Buffer Cache

ORA-4031错误：
SGA 中的内存池由不同大小的内存块组成。当数据库实例启动时，大量的内存块分配到不同的池中并且由空闲列表哈希 bucket 追踪。随着时间推移，由于内存块被分配和回收，内存块会根据它们的大小在池中的不同空闲列表 Bucket 中移动。当 Oracle 不能找到一个足够大的内存块来满足用户操作所带来的内部分配请求的时候，ORA-4031 错误就可能在 SGA 的任何一个池中出现。

共享池的管理与其它内存池不同。共享池存储数据字典和库缓存相关的信息。然而，这些内存区域使用空闲列表和{BANNED}{BANNED}最佳佳shao{BANNED}{BANNED}最佳佳jin使用（LRU）算法管理。在搜索所有的空闲列表，老化 LRU 列表上所有可能的对象，并且扫描空闲列表多次之后，共享池上才会发出 ORA-4031 错误。

如果还是没有什么思路，那就考虑一下：

1、设置如下参数，并重启数据库实例：
alter system set shared_pool_size=20G scope=spfile;
alter system set db_cache_size=30G scope=spfile;
alter system set "_memory_imm_mode_without_autosga"=FALSE scope=spfile;
alter system set event='28401 trace name context forever,level 1' scope=spfile;
2、关闭透明大页，开启大页，关闭numa
3、在操作系统回收了匿名大页后调整sga为60G
alter system set sga_target=60G scope=spfile;
alter system set sga_max_size=60G scope=spfile;
然后酌情调整shared_pool_size、db_cache_size
4、优化没有使用绑定变量的sql

下面是一个内存分配算法的简化版本：

scan regular free list for match, if not found
 large request, scan reserved list
   if (chunk found)
      check chunk size and perhaps truncate
   if (chunk is not found)
      scan regular free list
          if (chunk found)
             check chunk size and perhaps truncate
             all done
          if (chunk is not found)
              do LRU operations and repeat

 small request, scan regular free list 
   do LRU operations and repeat search
    if (chunk found)
       check chunk size and perhaps truncate
       all done
    if (chunk is not found) 
   do LRU operations and repeat

查查大小

select name, round(bytes/1024/1024) mb
from v$sgastat
where pool='shared pool'
and name in ('KGLH0')
order by mb desc;

可以作为监控的一个指标，达到

参考：

How To Prevent The Growth Of The Component 'KGH: NO ACCESS' In The Shared Pool When ASMM Is Enabled (Doc ID 451960.1)
ORA-4031 错误故障排除与诊断  (Doc ID 2016002.1)