KGH: NO ACCESS内存分配过大，引起的ORA-4031故障
一、故障症状
某些时段发现大量ORA-04031报错
Errors in file /oracle/diag/rdbms/obie/obie1/trace/obie1_smon_18153542.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-04031: unable to allocate 32 bytes of shared memory ("shared pool","FET$","KGLS^6c13497e","kglHeapInitialize:temp")
systemstate dump发现以下信息
#cat obie1_j000_37617704_bucket.trc
Process diagnostic dump for oracle@cnbidbp1 (J000), OS id=37617704,
pid: 57, proc_ser: 243, sid: 280, sess_ser: 54191
-------------------------------------------------------------------------------
current sql:
client details:
O/S info: user: oracle, term: UNKNOWN, ospid: 37617704
machine: cnbidbp1 program: oracle@cnbidbp1 (J000)
application name: DBMS_SCHEDULER, hash value=2478762354
action name: GATHER_STATS_JOB, hash value=930355498
Current Wait Stack:
0: waiting for 'SGA: allocation forcing component growth'
=0x0, =0x0, =0x0
wait_id=17065634 seq_num=54583 snap_id=99
wait times: snap=0.041714 sec, exc=5.091919 sec, total=5.435487 sec
wait times: max=infinite, heur=16.686881 sec
wait counts: calls=99 os=99
in_wait=1 iflags=0x15a0
There is at least one session blocking this session.
Dumping 1 direct blocker(s):
inst: 1, sid: 268, ser: 1
Dumping final blocker:
inst: 1, sid: 268, ser: 1
Wait State:
fixed_waits=0 flags=0x23 boundary=0x0/-1
该时段的AWR发现KGH: NO ACCESS 占用大量内存, 而SQLA部分占用内存才265M
注意正常的周期性观察 "KGH: NO ACCESS" 的 分配一般仅 高达约400M。
这个内存是当自动内存管理是在调整SGA组件时的一个在 SGA组件之间的过渡，然而，看到持续的高分配或随着时间的推移一直稳步积聚这种分配类型是很不正常的 。唯一的例外是当数据库需要做出大的变化，比如，一个重负载之后改变内存时，或启动使用次优的SGA设置，如当不使用SPFILE时。
下面的查询可确定 内存分配大量的 "KGH: NO ACCESS"：
- select * from v$sgastat where pool = 'shared pool' and (name in ('free memory', 'sql area', 'library cache', 'miscellaneous', 'row cache', 'KGH: NO ACCESS') );
- POOL NAME BYTES
- ------------ -------------------------- ----------
- shared pool KGH: NO ACCESS 402056288
- shared pool free memory 2149600472
- shared pool miscellaneous 1720
- shared pool row cache 7593704
下面的查询可以显示"DEFAULT buffer cache" 和 "shared pool"的 增长 和收缩操作：
- select START_TIME, component, oper_type, oper_mode, initial_size/1024/1024 "INITIAL", FINAL_SIZE/1024/1024 "FINAL", END_TIME,status
- from v$sga_resize_ops
- order by start_time, component;
- START_TIME COMPONENT OPER_TYPE OPER_MODE INITIAL FINAL END_TIME STATUS
- ------------------- ------------------------- ------------- --------- ---------- ---------- ------------------- ---------
- 14/12/2015 17:05:01 DEFAULT buffer cache SHRINK IMMEDIATE 3520 3456 14/12/2015 17:05:01 COMPLETE
- 14/12/2015 17:05:01 DEFAULT buffer cache SHRINK IMMEDIATE 3520 3520 14/12/2015 17:05:01 ERROR
- 14/12/2015 17:05:01 shared pool GROW IMMEDIATE 4224 4288 14/12/2015 17:05:01 COMPLETE
- 14/12/2015 17:05:01 shared pool GROW IMMEDIATE 4224 4224 14/12/2015 17:05:01 ERROR
- 15/12/2015 21:06:22 DEFAULT buffer cache SHRINK IMMEDIATE 3392 3328 15/12/2015 21:06:23 COMPLETE
- 15/12/2015 21:06:22 DEFAULT buffer cache SHRINK IMMEDIATE 3456 3392 15/12/2015 21:06:22 COMPLETE
- 15/12/2015 21:06:22 large pool GROW IMMEDIATE 256 320 15/12/2015 21:06:23 COMPLETE
- 15/12/2015 21:06:22 large pool GROW IMMEDIATE 192 256 15/12/2015 21:06:22 COMPLETE
二、故障原因
共享池和缓冲区高速缓存的过于频繁的调整大小 ，从而导致过量 "KGH: NO ACCESS" 内存分配，消耗SGA内存。
在10gR2中不同的版本，这个问题的几个bug 已有记录 ;
Fixed 10.2.0.2
Unpublished Bug 4507532: SGA_TARGET DOESN'T WORK AS EXPECTED
Bug 5045507 ASMM - FREQUENT RESIZING OF SHARED POOL & BUFFER CACHE
Fixed 10.2.0.4
Unpublished Bug 6528336: APPSST 10G GSI: LARGE NUMBER OF SESSIONS WAITING ON CURSOR: PIN S WAIT ON X
Fixed 10.2.0.5
Unpublished Bug 7189722: APPSST GSI 10G: VERY FREQUENT GROW/SHRINK SGA RESIZE OPERATION HAPPENING
如果你查看这个问题 在版本 11.1.0.6 to 11.2.0.1，可以查看 以下问题：Note 1127833.1 ORA-04031 in 11g & 11gR2, Excess "KGH: NO ACCESS" Memory Allocation
二、故障原因
1.禁用ASMM
或者
2.设置Shared Pool 和Database Buffer Cache的最小值。
或者
3.增加大小调整操作之间的时间
或者
4.升级 补丁，通过升级或应用一次性补丁，这取决于你的版本。
根据MOS说明，要解决所遇到的这种问题，其中过度ASMM调整操作导致“"KGH: NO ACCESS" 内存分配消耗提供给SGA的内存，上述解决方案都可以;。
Note 451960.1 How To Prevent The Growth Of The Component 'KGH: NO ACCESS' In The Shared Pool When ASMM Is Enabled
Note 742599.1 High 'cursor: pin S wait on X' and/or 'library cache lock' Waits. Cause: Shared Pool/Buffer Cache Resize Activity
禁用ASMM将意味着池之间的内存不再是交换，但它需要对SGA参数进行手动设置。
当启用ASMM，为Shared Pool 和 Buffer cache设置最小值时 意味着ASMM仍然在运行，但在低于最小值时，不会发生任何去改变SGA 组件大小的操作， 从而更少的内存需要经过 "KGH: NO ACCESS" 内存分配。 这是唯一 不需要的重启 数据库 的操作 。
增加调整大小操作之间的时间将意味着默认的30秒要增大到更大的时间间隔。
最后，在应用补丁或者升级将修复代码按照Oracle Development 的建议。
解决方法1：禁用ASMM，并手动设定SGA
1.确定SGA参数DB_CACHE_SIZE，SHARED_POOL_SIZE，LARGE_POOL_SIZE，JAVA_POOL_SIZE和STREAMS_POOL_SIZE（如apprioriate）的 合理值。 如需进一步的帮助，请查看MOS说明 ：Note 1008866.6 How to determine SGA Size (7.x, 8.0.x, 8i, 9i, 10g)
2.禁用ASMM:
- SQL> alter system set SGA_TARGET=0 scope=spfile;
3.手动设置SGA池的大小，使用从第1步（上面）确定的值：
例如:
- SQL> alter system set SHARED_POOL_SIZE=1G scope=spfile.
注意：不是所有的参数都需要设置，这些值会默认为0.
4.关闭 和启动数据库，以便使 ASMM被关闭，而新手工设置的SGA生效。
解决方法2：保持ASMM启用，但对于共享池和缓冲区高速缓存设置最小值
1.在一个典型的，繁忙的时期在数据库上，运行以下查询：
- SET PAGESIZE 100
- COL COMPONENT FORMAT A25
- COL FINAL_SIZE FORMAT A15
- select component, AVG(FINAL_SIZE) "AVG FINAL", MEDIAN(FINAL_SIZE) "MEDIAN FINAL", MAX(FINAL_SIZE) "MAX FINAL"
- from v$sga_resize_ops
- group by component;
2.对于 "DEFAULT buffer cache", 确定 "AVG FINAL" 或"MEDIAN FINAL"中更大的一个值，将这个值作为 最小的Buffer Cache 。
3.对于 " Shared Pool ", 确定 "AVG FINAL" 或"MEDIAN FINAL"中更大的一个值，将这个值作为 最小的Shared Pool 。
4.将最小的 Buffer Cache 和最小Shared Pool相加，然后和当前的SGA_TAGET或SGA_MAX_SIZE 相比较。
5.如果总和大于 SGA_TARGET 或 SGA_MAX_SIZE, 则需相应增加SGA_TARGET 和 SGA_MAX_SIZE的大小， 确定好SGA_TARGET 和 SGA_MAX_SIZE的大小后便可实施，如：
- SQL> alter system set sga_max_size=nnn scope=SPFILE;
- SQL> ALTER SYSTEM SET SGA_TARGET=nnn SCOPE=BOTH;
6.设置参数DB_CACHE_SIZE到最小缓冲区高速缓存的值
SQL> ALTER SYSTEM SET DB_CACHE_SIZE=n SCOPE=SPFILE;
7.设置参数SHARED_POOL_SIZE到最小共享池的价值
SQL> ALTER SYSTEM SET SHARED_POOL_SIZE=m SCOPE=SPFILE;
8.Re-start the database.
9.或者，您可以尝试无需重新启动数据库执行内存更改，但是首先需要确定什么是动态设置，通过运行下面的查询：
- SQL> select component, current_size from v$sga_dynamic_components where component like '% pool' or component = 'DEFAULT buffer cache';
- COMPONENT CURRENT_SIZE
- ------------------------- ------------
- shared pool 4496293888
- large pool 335544320
- java pool 67108864
- streams pool 67108864
- DEFAULT buffer cache 3489660928
如果同时"shared pool"和 "DEFAULT buffer cache" 小于在步骤2和3以上确定的最低值，那么设置DB_CACHE_SIZE和SHARED_POOL_SIZE时你可以尝试使用SCOPE = BOTH。
解决方案3：增加大小调整操作之间的时间
再次仔细看看 Note 742599.1 的解决方案, 特别是涉及到参数“ _memory_broker_stat_interval ”的解决方案。
对于您的数据库，确定一个合理的时间期限调整大小操作之间的延时，目前 给出的 默认值是30秒 。
设置参数 " _memory_broker_stat_interval " 为你确定的时间周期 :
- SQL> ALTER SYSTEM SET "_memory_broker_stat_interval"=n SCOPE=SPFILE;
重启数据库，使调整生效。
解决方法4：升级补丁
10.2.0.1
如果您使用的是v10.2.0.1，升级到最低v10.2.0.3的（或见下文）。
10.2.0.2
如果您使用的是v10.2.0.2，这个版本没有这个错误已记录，所以建议您升级（见下文）。
10.2.0.3
下载补丁包 Patch 6528336 阅读自述文件和先决条件
至2009年4月, 平台有： Linux x86, IBM AIX 64-bit, HP-UX Itanium.
如果没有你平台的补丁，找官方解决。
10.2.0.4
下载补丁包 Patch 7189722阅读自述文件和先决条件
至2009年4月, 平台有： Linux x86, Linux x86-64, IBM AIX 64-bit, HP-UX Itanium, Sun Solaris SPARC 64-bit.
如果没有你平台的补丁，找官方解决。
或者 如果在你的平台可用，Oracle建议您升级到v10.2.0.5
参考文献：
BUG:5045507 - ASMM - FREQUENT RESIZING OF SHARED POOL & BUFFER CACHE
NOTE:1008866.6 - How to determine SGA Size (7.x, 8.x, 9.x, 10g)
NOTE:1127833.1 - ORA-04031 in 11g & 11gR2, Excess "KGH: NO ACCESS" Memory Allocation
NOTE:451960.1 - How To Prevent The Growth Of The Component 'KGH: NO ACCESS' In The Shared Pool When ASMM Is Enabled
NOTE:742599.1 - High 'cursor: pin S wait on X' and/or 'library cache lock' Waits. Cause: Shared Pool/Buffer Cache Resize Activity
KGH: NO ACCESS内存分配过大，引起的ORA-4031故障相关推荐
- golang 内存分配
内存布局结构图 从上述结构图来看,内存分配器还是有一点小复杂的,但根据具体的逻辑层次可以拆分成三大模块--cache,central,heap,然后一个一个的模块分析下去,逻辑就显得特别清晰明了了.位 ...
- 为myeclipse分配更大的内存
在进行开发大项目时,常常会遇见开发工具卡顿的情况 ,大多数都是因为内存不够的原因造成的,今天学习了为MyEclipse分配更大内存的方法.是通过修改配置文件实现的. 一:修改myeclipse.ini ...
- 服务器系统怎么分配,服务器系统盘分配多大内存
服务器系统盘分配多大内存 内容精选 换一换 本文以云服务器的操作系统为"Windows Server 2008 R2 Enterprise 64bit"为例,提供磁盘的初始化操作指 ...
- 计算机可用内存分配失败,你们都被忽悠了! 其实可用内存大才有用
[PConline 杂谈]随着这几年安卓手机的硬件快速升级,手机的运行内存(本文后续页面将"运行内存"简称为内存或者RAM)也越来越大,从最初的512M到1GB,再到现在主流的2G ...
- 挑战malloc极限，看看你的系统有多大的内存分配能力
/**: MallocLimit.c * by lonelyforest *这个程序在DOS下运行,将会输出您的内存到底能够 *分配多大!!! */ #include <stdio.h& ...
- jvm深入理解：内存分配与回收策略（优先在Eden分配、大对象直接进入老年代、长期存活的对象将进入老年代、动态对象年龄判定、空间分配担保）
出入:深入理解Java虚拟机:JVM高级特性与最佳实践(第3版) Java技术体系的自动内存管理,最根本的目标是自动化地解决两个问题:自动给对象分配内存以及自动回收分配给对象的内存. 象的内存分配,从 ...
- CMA大段设备内存分配
在我们使用ARM等嵌入式Linux系统的时候,一个头疼的问题是GPU,Camera,HDMI等都需要预留大量连续内存,对于内核如果申请一块连续的内存空间该怎么处理呢? 首先向到的是利用内核提供的kma ...
- 32位计算机分配的最大内存大小,win732位内存支持多大内存 win732位内存最大支持大小【图文】...
内存是计算机中非常重要的一个硬件,内存的大小直接影响到系统能够支持同时运行程序的数量和质量,而且还能够支持运行占用资源较大的软件.而对于不同的系统,它所能够支持的最大内存数量也会有区别的.那么我们生活 ...
- linux c free大段内存,Linux C 动态内存分配--malloc，new，free及相关内容
一.malloc()和free()的基本概念以及基本用法: 1.函数原型及说明: void *malloc(long NumBytes):该函数分配了NumBytes个字节,并返回了指向这块内存的指针 ...
最新文章
- 在Google Cloud Platform上持续部署Node.js
- 白话红黑树系列之二——红黑树的构建
- 牛顿迭代法的可视化详解
- qcom Android Camera【转】
- 后端开发开发mac装机和开发环境指南（新手版）
- VTK：PolyData之CellCentersDemo
- Shell循环与结构化命令
- 交换机配置工具_Soce在FPGA上为任务关键型应用量身定制的IEEE 1588感知以太网交换机...
- 大数据_Spark_框架简介---Spark工作笔记0001
- mysql 求和_mysql分组求和
- fftshift使用
- 针对OpenSSL吐嘈的吐嘈-如此唱反调
- 用python画箱体图
- VSPD虚拟串口使用
- 新神魔大陆服务器维护,《新神魔大陆》手游8月20日合服维护公告
- windows环境下netcat的安装及使用
- TO_DATE使用詳解
- 自学Python问题记录2：解决画风玫瑰图出现报错No artists with labels found to put in legend.
- 完整目标检测项目流程——从使用LabelImg标注到使用YOLOv5训练测试
- java -Xms -Xmx -XX:PermSize -XX:MaxPermSize 作用详解