- 浏览: 1366036 次
- 性别:
- 来自: 北京
文章分类
- 全部博客 (551)
- 计划 (4)
- java (115)
- oracle (60)
- ajax (3)
- javascript (64)
- 计算机操作技巧集 (11)
- 近期关注话题 (10)
- 随想 (13)
- html (6)
- struts (15)
- hibernate (16)
- spring (2)
- game (0)
- Eglish (10)
- DisplayTag (6)
- jsp (18)
- css (3)
- eclipse (3)
- 其他知识 (8)
- 备用1 (12)
- 备用2 (1)
- 笑话-放松心情 (9)
- 设计 (1)
- 设计模式 (1)
- 数据结构 (0)
- office办公软件 (5)
- webwork (0)
- tomcat (2)
- MySql (1)
- 我的链接资源 (5)
- xml (2)
- servlet (0)
- PHP (13)
- DOM (0)
- 网页画图vml,canvas (1)
- 协议 (2)
- 健康 (3)
- 书籍下载 (1)
- jbpm (1)
- EXT (1)
- 自考 (2)
- 报表 (4)
- 生活 (64)
- 操作系统基础知识 (2)
- 测试 (2)
- guice (1)
- google学习 (2)
- Erlang (1)
- LOG4J (2)
- wicket (1)
- 考研 (1)
- 法律 (1)
- 地震 (1)
- 易学-等等相关 (1)
- 音乐 (1)
- 建站 (4)
- 分享说 (3)
- 购物省钱 (0)
- linux (1)
最新评论
-
zenmshuo:
如果使用SpreadJS这一类的表格工具,应该能更好的实现这些 ...
js中excel的用法 -
hjhj2991708:
第一个已经使用不了
jar包查询网站 非常好用! -
jiangmeiwei:
...
中文乱码 我的总结 不断更新 -
gary_bu:
...
response.sendRedirect 中文乱码问题解决 -
hnez:
多谢指点,怎么调试也不通,原来我在<body>&l ...
ExtJs IE ownerDocument.createRange() 错误解决方案
[Oracle] 如何解决ORA-04031 错误
请查看原文
http://www.dbanotes.net/Oracle/Ora-04031.htm
诊断并解决ORA-04031 错误
当我们在共享池中试图分配大片的连续内存失败的时候,Oracle首先清除池中当前没使用的所有对象,使空闲内存块合并。如果仍然没有足够大单个的大块内存满足请求,就会产生ORA-04031 错误。
当这个错误出现的时候你得到的错误解释信息类似如下:
04031, 00000, "unable to allocate %s bytes of shared memory (\"%s\",\"%s\",\"%s\",\"%s\")"
// *Cause: More shared memory is needed than was allocated in the shared
// pool.
// *Action: If the shared pool is out of memory, either use the
// dbms_shared_pool package to pin large packages,
// reduce your use of shared memory, or increase the amount of
// available shared memory by increasing the value of the
// INIT.ORA parameters "shared_pool_reserved_size" and
// "shared_pool_size".
// If the large pool is out of memory, increase the INIT.ORA
// parameter "large_pool_size".
1.共享池相关的实例参数
在继续之前,有必要理解下面的实例参数:
SHARED_POOL_SIZE
这个参数指定了共享池的大小,单位是字节。可以接受数字值或者数字后面跟上后缀"K" 或 "M" 。"K"代表千字节, "M"代表兆字节。
SHARED_POOL_RESERVED_SIZE
指定了为共享池内存保留的用于大的连续请求的共享池空间。当共享池碎片强制使 Oracle 查找并释放大块未使用的池来满足当前的请求的时候,这个参数和SHARED_POOL_RESERVED_MIN_ALLOC 参数一起可以用来避免性能下降。
这个参数理想的值应该大到足以满足任何对保留列表中内存的请求扫描而无需从共享池中刷新对象。既然操作系统内存可以限制共享池的大小,一般来说,你应该设定这个参数为 SHARED_POOL_SIZE 参数的 10% 大小。
SHARED_POOL_RESERVED_MIN_ALLOC 这个参数的值控制保留内存的分配。如果一个足够尺寸的大块内存在共享池空闲列表中没能找到,内存就从保留列表中分配一块比这个值大的空间。默认的值对于大多数系统来说都足够了。如果你加大这个值,那么Oracle 服务器将允许从这个保留列表中更少的分配并且将从共享池列表中请求更多的内存。这个参数在Oracle 8i 和更高的版本中是隐藏的。提交如下的语句查找这个参数值: SELECT nam.ksppinm NAME, val.ksppstvl VALUE
FROM x$ksppi nam, x$ksppsv val
WHERE nam.indx = val.indx AND nam.ksppinm LIKE '%shared%'
ORDER BY 1;
10g 注释:Oracle 10g 的一个新特性叫做 "自动内存管理" 允许DBA保留一个共享内存池来分shared pool,buffer cache, java pool 和large pool。一般来说,当数据库需要分配一个大的对象到共享池中并且不能找到连续的可用空间,将自动使用其他SGA结构的空闲空间来增加共享池的大小 。既然空间分配是Oracle自动管理的,ora-4031出错的可能性将大大降低。自动内存管理在初始化参数SGA_TARGET大于0的时候被激活。当前设定可以通过查询v$sga_dynamic_components 视图获得。请参考10g管理手册以得到更多内容 。
2.诊断ORA-04031 错误
注:大多数的常见的 ORA-4031 的产生都和 SHARED POOL SIZE 有关,这篇文章中的诊断步骤大多都是关于共享池的。 对于其它方面如Large_pool或是Java_pool,内存分配算法都是相似的,一般来说都是因为结构不够大造成。
ORA-04031 可能是因为 SHARED POOL 不够大,或是因为碎片问题导致数据库不能找到足够大的内存块。
ORA-04031 错误通常是因为库高速缓冲中或共享池保留空间中的碎片。 在加大共享池大小的时 候考虑调整应用,使用共享的SQL 并且调整如下的参数:
SHARED_POOL_SIZE,
SHARED_POOL_RESERVED_SIZE,
SHARED_POOL_RESERVED_MIN_ALLOC.
首先判定是否ORA-04031 错误是由共享池保留空间中的库高速缓冲的碎片产生的。提交下的查询:
SELECT free_space, avg_free_size,used_space, avg_used_size, request_failures,
last_failure_size
FROM v$shared_pool_reserved;
如果:
REQUEST_FAILURES > 0 并且 LAST_FAILURE_SIZE > SHARED_POOL_RESERVED_MIN_ALLOC
那么ORA-04031 错误就是因为共享池保留空间缺少连续空间所致。要解决这个问题,可以考虑加大SHARED_POOL_RESERVED_MIN_ALLOC 来降低缓冲进共 享池保留空间的对象数目,并增大 SHARED_POOL_RESERVED_SIZE 和 SHARED_POOL_SIZE 来加大共享池保留空间的可用内存。
如果:
REQUEST_FAILURES > 0 并且 LAST_FAILURE_SIZE < SHARED_POOL_RESERVED_MIN_ALLOC
或者
REQUEST_FAILURES 等于0 并且 LAST_FAILURE_SIZE < SHARED_POOL_RESERVED_MIN_ALLOC
那么是因为在库高速缓冲缺少连续空间导致ORA-04031 错误。
第一步应该考虑降低SHARED_POOL_RESERVED_MIN_ALLOC 以放入更多的对象到共享池保留空间中并且加大SHARED_POOL_SIZE。
3.解决ORA-04031 错误
ORACLE BUG
Oracle推荐对你的系统打上最新的PatchSet。大多数的ORA-04031错误都和BUG 相关,可以通过使用这些补丁来避免。
下面表中总结和和这个错误相关的最常见的BUG、可能的环境和修补这个问题的补丁。
BUG 描述 Workaround Fixed
<Bug:1397603> ORA-4031/SGA memory leak of PERMANENT memory occurs for buffer handles _db_handles_cached = 0 901/ 8172
<Bug:1640583> ORA-4031 due to leak / cache buffer chain contention from AND-EQUAL access Not available 8171/901
<Bug:1318267> INSERT AS SELECT statements may
not be shared when they should be
if TIMED_STATISTICS. It can lead to ORA-4031 _SQLEXEC_PROGRESSION_COST=0
8171/8200
<Bug:1193003> Cursors may not be shared in 8.1
when they should be Not available 8162/8170/ 901
<Bug:2104071> ORA-4031/excessive "miscellaneous" shared pool usage possible. (many PINS) None-> This is known to affect the XML parser. 8174, 9013, 9201
<Note:263791.1> Several number of BUGs related to ORA-4031 erros were fixed in the 9.2.0.5 patchset Not available 9205
编译Java代码时出现的ORA-4031
在你编译Java代码的时候如果内存溢出,你会看到错误:
A SQL exception occurred while compiling: :
ORA-04031: unable to allocate bytes of shared memory
("shared pool","unknown object","joxlod: init h", "JOX: ioc_allocate_pal")
解决办法是关闭数据库然后把参数 JAVA_POOL_SIZE 设定为一个较大的值。这里错误信息中提到的 "shared pool" 其实共享全局区(SGA)溢出的误导,并不表示你需要增加SHARED_POOL_SIZE,相反,你必须加大 JAVA_POOL_SIZE 参数的值,然后重启动系统,再试一下。参考: <Bug:2736601> 。
小的共享池尺寸
很多情况下,共享池过小能够导致ORA-04031错误。下面信息有助于你调整共享池大小:
库高速缓冲命中率
命中率有助于你衡量共享池的使用,有多少语句需要被解析而不是重用。下面的SQL语句有助于你计算库高速缓冲的命中率:
SELECT SUM(PINS) "EXECUTIONS",
SUM(RELOADS) "CACHE MISSES WHILE EXECUTING"
FROM V$LIBRARYCACHE;
如果丢失超过1%,那么尝试通过加大共享池的大小来减少库高速缓冲丢失。
共享池大小计算
要计算最适合你工作负载的共享池大小,请参考:
<Note:1012046.6>: HOW TO CALCULATE YOUR SHARED POOL SIZE.
共享池碎片
每一次,需要被执行的SQL 或者PL/SQL 语句的解析形式载入共享池中都需要一块特定的连续的空间。数据库要扫描的第一个资源就是共享池中的空闲可用内存。一旦空闲内存耗尽,数据库要查找一块已经分配但还没使用的内存准备重用。如果这样的确切尺寸的大块内存不可用,就继续按照如下标准寻找:
大块(chunk)大小比请求的大小大
空间是连续的
大块内存是可用的(而不是正在使用的)
这样大块的内存被分开,剩余的添加到相应的空闲空间列表中。当数据库以这种方式操作一段时间之后,共享池结构就会出现碎片。
当共享池存在碎片的问题,分配一片空闲的空间就会花费更多的时间,数据库性能也会下降(整个操作的过程中,"chunk allocation"被一个叫做"shared pool latch" 的闩所控制) 或者是出现 ORA-04031 错误errors (在数据库不能找到一个连续的空闲内存块的时候)。
参考 <Note:61623.1>: 可以得到关于共享池碎片的详细讨论。
如果SHARED_POOL_SIZE 足够大,大多数的 ORA-04031 错误都是由共享池中的动态SQL 碎片导致的。可能的原因如下:
非共享的SQL
生成不必要的解析调用 (软解析)
没有使用绑定变量
要减少碎片的产生你需要确定是前面描叙的几种可能的因素。可以采取如下的一些方法,当然不只局限于这几种: 应用调整、数据库调整或者实例参数调整。
请参考 <Note:62143.1>,描述了所有的这些细节内容。这个注释还包括了共享池如何工作的细节。
下面的视图有助于你标明共享池中非共享的SQL/PLSQL:
V$SQLAREA 视图
这个视图保存了在数据库中执行的SQL 语句和PL/SQL 块的信息。下面的SQL 语句可以显示给你带有literal 的语句或者是带有绑定变量的语句:
SELECT SUBSTR (sql_text, 1, 40) "SQL", COUNT (*),
SUM (executions) "TotExecs"
FROM v$sqlarea
WHERE executions < 5
GROUP BY SUBSTR (sql_text, 1, 40)
HAVING COUNT (*) > 30
ORDER BY 2;
注: Having 后的数值 "30" 可以根据需要调整以得到更为详细的信息。
X$KSMLRU 视图
这个固定表x$ksmlru 跟踪共享池中导致其它对象换出(age out)的应用。这个固定表可以用来标记是什么导致了大的应用。
如果很多对象在共享池中都被阶段性的刷新可能导致响应时间问题并且有可能在对象重载入共享池中的时候导致库高速缓冲闩竞争问题。
关于这个x$ksmlru 表的一个不寻常的地方就是如果有人从表中选取内容这个表的内容就会被擦除。这样这个固定表只存储曾经发生的最大的分配。这个值在选择后被重新设定这样接下来的大的分配可以被标记,即使它们不如先前的分配过的大。因为这样的重置,在查询提交后的结果不可以再次得到,从表中的输出的结果应该小心的保存。监视这个固定表运行如下操作:
SELECT * FROM X$KSMLRU WHERE ksmlrsiz > 0;
这个表只可以用SYS用户登录进行查询。
X$KSMSP 视图 (类似堆Heapdump信息)
使用这个视图能找出当前分配的空闲空间,有助于理解共享池碎片的程度。如我们在前面的描述,查找为游标分配的足够的大块内存的第一个地方是空闲列表( free list)。 下面的语句显示了空闲列表中的大块内存:
SELECT '0 (<140)' bucket, ksmchcls, 10 * TRUNC (ksmchsiz / 10) "From",
COUNT (*) "Count", MAX (ksmchsiz) "Biggest",
TRUNC (AVG (ksmchsiz)) "AvgSize", TRUNC (SUM (ksmchsiz)) "Total"
FROM x$ksmsp
WHERE ksmchsiz < 140 AND ksmchcls = 'free'
GROUP BY ksmchcls, 10 * TRUNC (ksmchsiz / 10)
UNION ALL
SELECT '1 (140-267)' bucket, ksmchcls, 20 * TRUNC (ksmchsiz / 20),
COUNT (*), MAX (ksmchsiz), TRUNC (AVG (ksmchsiz)) "AvgSize",
TRUNC (SUM (ksmchsiz)) "Total"
FROM x$ksmsp
WHERE ksmchsiz BETWEEN 140 AND 267 AND ksmchcls = 'free'
GROUP BY ksmchcls, 20 * TRUNC (ksmchsiz / 20)
UNION ALL
SELECT '2 (268-523)' bucket, ksmchcls, 50 * TRUNC (ksmchsiz / 50),
COUNT (*), MAX (ksmchsiz), TRUNC (AVG (ksmchsiz)) "AvgSize",
TRUNC (SUM (ksmchsiz)) "Total"
FROM x$ksmsp
WHERE ksmchsiz BETWEEN 268 AND 523 AND ksmchcls = 'free'
GROUP BY ksmchcls, 50 * TRUNC (ksmchsiz / 50)
UNION ALL
SELECT '3-5 (524-4107)' bucket, ksmchcls, 500 * TRUNC (ksmchsiz / 500),
COUNT (*), MAX (ksmchsiz), TRUNC (AVG (ksmchsiz)) "AvgSize",
TRUNC (SUM (ksmchsiz)) "Total"
FROM x$ksmsp
WHERE ksmchsiz BETWEEN 524 AND 4107 AND ksmchcls = 'free'
GROUP BY ksmchcls, 500 * TRUNC (ksmchsiz / 500)
UNION ALL
SELECT '6+ (4108+)' bucket, ksmchcls, 1000 * TRUNC (ksmchsiz / 1000),
COUNT (*), MAX (ksmchsiz), TRUNC (AVG (ksmchsiz)) "AvgSize",
TRUNC (SUM (ksmchsiz)) "Total"
FROM x$ksmsp
WHERE ksmchsiz >= 4108 AND ksmchcls = 'free'
GROUP BY ksmchcls, 1000 * TRUNC (ksmchsiz / 1000);
4. ORA-04031 错误与 Large Pool
大池是个可选的内存区,为以下的操作提供大内存分配:
MTS会话内存和 Oracle XA 接口
Oracle 备份与恢复操作和I/O服务器进程用的内存(缓冲)
并行执行消息缓冲
大池没有LRU列表。这和共享池中的保留空间不同,保留空间和共享池中其他分配的内存使用同样的LRU列表。大块内存从不会换出大池中,内存必须是显式的被每个会话分配并释放。一个请求如果没有足够的内存,就会产生类似这样的一个ORA-4031错误:
ORA-04031: unable to allocate XXXX bytes of shared memory
("large pool","unknown object","session heap","frame")
这个错误发生时候可以检查几件事情:
1- 使用如下语句检查 V$SGASTAT ,得知使用和空闲的内存: SELECT pool,name,bytes FROM v$sgastat where pool = 'large pool';
2- 你还可以采用 heapdump level 32 来 dump 大池的堆并检查空闲的大块内存的大小
从大池分配的内存如果是LARGE_POOL_MIN_ALLOC 子节的整块数有助于避免碎片。任何请求分配小于LARGE_POOL_MIN_ALLOC 大块尺寸都将分配LARGE_POOL_MIN_ALLOC的大小。一般来说,你会看到使用大池的时候相对共享池来说要用到更多的内存。通常要解决大池中的ORA-4031错误必须增加 LARGE_POOL_SIZE 的大小。
5. ORA-04031 和共享池刷新
有一些技巧会提高游标的共享能力,从而共享池碎片和ORA-4031都会减少。最佳途径是调整应用使用绑定变量。另外在应用不能调整的时候考虑使用CURSOR_SHARING参数和FORCE不同的值来做到 (要注意那会导致执行计划改变,所以建议先对应用进行测试)。当上述技巧都不可以用的时候,并且碎片问题在系统中比较严重,刷新共享持可能有助于减轻碎片问题。但是,必须加以如下考虑:
刷新将导致所有没被使用的游标从共享池删除。这样,在共享池刷新之后,大多数SQL和PL/SQL游标必须被硬解析。这将提高CPU的使用,也会加大Latch的活动。
当应用程序没有使用绑定变量并被许多用户进行类似的操作的时候(如在OLTP系统中) ,刷新之后很快还会出现碎片问题。所以共享池对设计糟糕的应用程序来说不是解决办法。
对一个大的共享池刷新可能会导致系统挂起,尤其是实例繁忙的时候,推荐在非高峰的时候刷新
6. ORA-04031错误的高级分析
如果前述的这些技术内容都不能解决ORA-04031 错误,可能需要额外的跟踪信息来得到问题发生的共享池的快照。
调整init.ora参数添加如下的事件得到该问题的跟踪信息:
event = "4031 trace name errorstack level 3"
event = "4031 trace name HEAPDUMP level 3"
如果问题可重现,该事件可设定在会话层,在执行问题语句之前使用如下的语句: SQL> alter session set events '4031 trace name errorstack level 3';
SQL> alter session set events '4031 trace name HEAPDUMP level 3';
把这个跟踪文件发给Oracle支持人员进行排错。
重要标注: Oracle 9.2.0.5 和Oracle 10g 版本中,每次在发生ORA-4031 错误的时候会自动创建一个跟踪文件,可以在user_dump_dest 目录中找到。如果你的系统是上述的版本,你不需要再进行前面描述中的步骤。
参考信息
Metalink - http://metalink.oracle.com
<Note:1012046.6> How to Calculate Your Shared Pool Size
<Note:62143.1> Understanding and Tuning the Shared Pool
<Note:1012049.6> Tuning Library Cache Latch Contention
<Note:61623.1> Resolving Shared Pool Fragmentation
<Note:146599.1> Diagnosing and Resolving Error ORA-04031
请查看原文
http://www.dbanotes.net/Oracle/Ora-04031.htm
诊断并解决ORA-04031 错误
当我们在共享池中试图分配大片的连续内存失败的时候,Oracle首先清除池中当前没使用的所有对象,使空闲内存块合并。如果仍然没有足够大单个的大块内存满足请求,就会产生ORA-04031 错误。
当这个错误出现的时候你得到的错误解释信息类似如下:
04031, 00000, "unable to allocate %s bytes of shared memory (\"%s\",\"%s\",\"%s\",\"%s\")"
// *Cause: More shared memory is needed than was allocated in the shared
// pool.
// *Action: If the shared pool is out of memory, either use the
// dbms_shared_pool package to pin large packages,
// reduce your use of shared memory, or increase the amount of
// available shared memory by increasing the value of the
// INIT.ORA parameters "shared_pool_reserved_size" and
// "shared_pool_size".
// If the large pool is out of memory, increase the INIT.ORA
// parameter "large_pool_size".
1.共享池相关的实例参数
在继续之前,有必要理解下面的实例参数:
SHARED_POOL_SIZE
这个参数指定了共享池的大小,单位是字节。可以接受数字值或者数字后面跟上后缀"K" 或 "M" 。"K"代表千字节, "M"代表兆字节。
SHARED_POOL_RESERVED_SIZE
指定了为共享池内存保留的用于大的连续请求的共享池空间。当共享池碎片强制使 Oracle 查找并释放大块未使用的池来满足当前的请求的时候,这个参数和SHARED_POOL_RESERVED_MIN_ALLOC 参数一起可以用来避免性能下降。
这个参数理想的值应该大到足以满足任何对保留列表中内存的请求扫描而无需从共享池中刷新对象。既然操作系统内存可以限制共享池的大小,一般来说,你应该设定这个参数为 SHARED_POOL_SIZE 参数的 10% 大小。
SHARED_POOL_RESERVED_MIN_ALLOC 这个参数的值控制保留内存的分配。如果一个足够尺寸的大块内存在共享池空闲列表中没能找到,内存就从保留列表中分配一块比这个值大的空间。默认的值对于大多数系统来说都足够了。如果你加大这个值,那么Oracle 服务器将允许从这个保留列表中更少的分配并且将从共享池列表中请求更多的内存。这个参数在Oracle 8i 和更高的版本中是隐藏的。提交如下的语句查找这个参数值: SELECT nam.ksppinm NAME, val.ksppstvl VALUE
FROM x$ksppi nam, x$ksppsv val
WHERE nam.indx = val.indx AND nam.ksppinm LIKE '%shared%'
ORDER BY 1;
10g 注释:Oracle 10g 的一个新特性叫做 "自动内存管理" 允许DBA保留一个共享内存池来分shared pool,buffer cache, java pool 和large pool。一般来说,当数据库需要分配一个大的对象到共享池中并且不能找到连续的可用空间,将自动使用其他SGA结构的空闲空间来增加共享池的大小 。既然空间分配是Oracle自动管理的,ora-4031出错的可能性将大大降低。自动内存管理在初始化参数SGA_TARGET大于0的时候被激活。当前设定可以通过查询v$sga_dynamic_components 视图获得。请参考10g管理手册以得到更多内容 。
2.诊断ORA-04031 错误
注:大多数的常见的 ORA-4031 的产生都和 SHARED POOL SIZE 有关,这篇文章中的诊断步骤大多都是关于共享池的。 对于其它方面如Large_pool或是Java_pool,内存分配算法都是相似的,一般来说都是因为结构不够大造成。
ORA-04031 可能是因为 SHARED POOL 不够大,或是因为碎片问题导致数据库不能找到足够大的内存块。
ORA-04031 错误通常是因为库高速缓冲中或共享池保留空间中的碎片。 在加大共享池大小的时 候考虑调整应用,使用共享的SQL 并且调整如下的参数:
SHARED_POOL_SIZE,
SHARED_POOL_RESERVED_SIZE,
SHARED_POOL_RESERVED_MIN_ALLOC.
首先判定是否ORA-04031 错误是由共享池保留空间中的库高速缓冲的碎片产生的。提交下的查询:
SELECT free_space, avg_free_size,used_space, avg_used_size, request_failures,
last_failure_size
FROM v$shared_pool_reserved;
如果:
REQUEST_FAILURES > 0 并且 LAST_FAILURE_SIZE > SHARED_POOL_RESERVED_MIN_ALLOC
那么ORA-04031 错误就是因为共享池保留空间缺少连续空间所致。要解决这个问题,可以考虑加大SHARED_POOL_RESERVED_MIN_ALLOC 来降低缓冲进共 享池保留空间的对象数目,并增大 SHARED_POOL_RESERVED_SIZE 和 SHARED_POOL_SIZE 来加大共享池保留空间的可用内存。
如果:
REQUEST_FAILURES > 0 并且 LAST_FAILURE_SIZE < SHARED_POOL_RESERVED_MIN_ALLOC
或者
REQUEST_FAILURES 等于0 并且 LAST_FAILURE_SIZE < SHARED_POOL_RESERVED_MIN_ALLOC
那么是因为在库高速缓冲缺少连续空间导致ORA-04031 错误。
第一步应该考虑降低SHARED_POOL_RESERVED_MIN_ALLOC 以放入更多的对象到共享池保留空间中并且加大SHARED_POOL_SIZE。
3.解决ORA-04031 错误
ORACLE BUG
Oracle推荐对你的系统打上最新的PatchSet。大多数的ORA-04031错误都和BUG 相关,可以通过使用这些补丁来避免。
下面表中总结和和这个错误相关的最常见的BUG、可能的环境和修补这个问题的补丁。
BUG 描述 Workaround Fixed
<Bug:1397603> ORA-4031/SGA memory leak of PERMANENT memory occurs for buffer handles _db_handles_cached = 0 901/ 8172
<Bug:1640583> ORA-4031 due to leak / cache buffer chain contention from AND-EQUAL access Not available 8171/901
<Bug:1318267> INSERT AS SELECT statements may
not be shared when they should be
if TIMED_STATISTICS. It can lead to ORA-4031 _SQLEXEC_PROGRESSION_COST=0
8171/8200
<Bug:1193003> Cursors may not be shared in 8.1
when they should be Not available 8162/8170/ 901
<Bug:2104071> ORA-4031/excessive "miscellaneous" shared pool usage possible. (many PINS) None-> This is known to affect the XML parser. 8174, 9013, 9201
<Note:263791.1> Several number of BUGs related to ORA-4031 erros were fixed in the 9.2.0.5 patchset Not available 9205
编译Java代码时出现的ORA-4031
在你编译Java代码的时候如果内存溢出,你会看到错误:
A SQL exception occurred while compiling: :
ORA-04031: unable to allocate bytes of shared memory
("shared pool","unknown object","joxlod: init h", "JOX: ioc_allocate_pal")
解决办法是关闭数据库然后把参数 JAVA_POOL_SIZE 设定为一个较大的值。这里错误信息中提到的 "shared pool" 其实共享全局区(SGA)溢出的误导,并不表示你需要增加SHARED_POOL_SIZE,相反,你必须加大 JAVA_POOL_SIZE 参数的值,然后重启动系统,再试一下。参考: <Bug:2736601> 。
小的共享池尺寸
很多情况下,共享池过小能够导致ORA-04031错误。下面信息有助于你调整共享池大小:
库高速缓冲命中率
命中率有助于你衡量共享池的使用,有多少语句需要被解析而不是重用。下面的SQL语句有助于你计算库高速缓冲的命中率:
SELECT SUM(PINS) "EXECUTIONS",
SUM(RELOADS) "CACHE MISSES WHILE EXECUTING"
FROM V$LIBRARYCACHE;
如果丢失超过1%,那么尝试通过加大共享池的大小来减少库高速缓冲丢失。
共享池大小计算
要计算最适合你工作负载的共享池大小,请参考:
<Note:1012046.6>: HOW TO CALCULATE YOUR SHARED POOL SIZE.
共享池碎片
每一次,需要被执行的SQL 或者PL/SQL 语句的解析形式载入共享池中都需要一块特定的连续的空间。数据库要扫描的第一个资源就是共享池中的空闲可用内存。一旦空闲内存耗尽,数据库要查找一块已经分配但还没使用的内存准备重用。如果这样的确切尺寸的大块内存不可用,就继续按照如下标准寻找:
大块(chunk)大小比请求的大小大
空间是连续的
大块内存是可用的(而不是正在使用的)
这样大块的内存被分开,剩余的添加到相应的空闲空间列表中。当数据库以这种方式操作一段时间之后,共享池结构就会出现碎片。
当共享池存在碎片的问题,分配一片空闲的空间就会花费更多的时间,数据库性能也会下降(整个操作的过程中,"chunk allocation"被一个叫做"shared pool latch" 的闩所控制) 或者是出现 ORA-04031 错误errors (在数据库不能找到一个连续的空闲内存块的时候)。
参考 <Note:61623.1>: 可以得到关于共享池碎片的详细讨论。
如果SHARED_POOL_SIZE 足够大,大多数的 ORA-04031 错误都是由共享池中的动态SQL 碎片导致的。可能的原因如下:
非共享的SQL
生成不必要的解析调用 (软解析)
没有使用绑定变量
要减少碎片的产生你需要确定是前面描叙的几种可能的因素。可以采取如下的一些方法,当然不只局限于这几种: 应用调整、数据库调整或者实例参数调整。
请参考 <Note:62143.1>,描述了所有的这些细节内容。这个注释还包括了共享池如何工作的细节。
下面的视图有助于你标明共享池中非共享的SQL/PLSQL:
V$SQLAREA 视图
这个视图保存了在数据库中执行的SQL 语句和PL/SQL 块的信息。下面的SQL 语句可以显示给你带有literal 的语句或者是带有绑定变量的语句:
SELECT SUBSTR (sql_text, 1, 40) "SQL", COUNT (*),
SUM (executions) "TotExecs"
FROM v$sqlarea
WHERE executions < 5
GROUP BY SUBSTR (sql_text, 1, 40)
HAVING COUNT (*) > 30
ORDER BY 2;
注: Having 后的数值 "30" 可以根据需要调整以得到更为详细的信息。
X$KSMLRU 视图
这个固定表x$ksmlru 跟踪共享池中导致其它对象换出(age out)的应用。这个固定表可以用来标记是什么导致了大的应用。
如果很多对象在共享池中都被阶段性的刷新可能导致响应时间问题并且有可能在对象重载入共享池中的时候导致库高速缓冲闩竞争问题。
关于这个x$ksmlru 表的一个不寻常的地方就是如果有人从表中选取内容这个表的内容就会被擦除。这样这个固定表只存储曾经发生的最大的分配。这个值在选择后被重新设定这样接下来的大的分配可以被标记,即使它们不如先前的分配过的大。因为这样的重置,在查询提交后的结果不可以再次得到,从表中的输出的结果应该小心的保存。监视这个固定表运行如下操作:
SELECT * FROM X$KSMLRU WHERE ksmlrsiz > 0;
这个表只可以用SYS用户登录进行查询。
X$KSMSP 视图 (类似堆Heapdump信息)
使用这个视图能找出当前分配的空闲空间,有助于理解共享池碎片的程度。如我们在前面的描述,查找为游标分配的足够的大块内存的第一个地方是空闲列表( free list)。 下面的语句显示了空闲列表中的大块内存:
SELECT '0 (<140)' bucket, ksmchcls, 10 * TRUNC (ksmchsiz / 10) "From",
COUNT (*) "Count", MAX (ksmchsiz) "Biggest",
TRUNC (AVG (ksmchsiz)) "AvgSize", TRUNC (SUM (ksmchsiz)) "Total"
FROM x$ksmsp
WHERE ksmchsiz < 140 AND ksmchcls = 'free'
GROUP BY ksmchcls, 10 * TRUNC (ksmchsiz / 10)
UNION ALL
SELECT '1 (140-267)' bucket, ksmchcls, 20 * TRUNC (ksmchsiz / 20),
COUNT (*), MAX (ksmchsiz), TRUNC (AVG (ksmchsiz)) "AvgSize",
TRUNC (SUM (ksmchsiz)) "Total"
FROM x$ksmsp
WHERE ksmchsiz BETWEEN 140 AND 267 AND ksmchcls = 'free'
GROUP BY ksmchcls, 20 * TRUNC (ksmchsiz / 20)
UNION ALL
SELECT '2 (268-523)' bucket, ksmchcls, 50 * TRUNC (ksmchsiz / 50),
COUNT (*), MAX (ksmchsiz), TRUNC (AVG (ksmchsiz)) "AvgSize",
TRUNC (SUM (ksmchsiz)) "Total"
FROM x$ksmsp
WHERE ksmchsiz BETWEEN 268 AND 523 AND ksmchcls = 'free'
GROUP BY ksmchcls, 50 * TRUNC (ksmchsiz / 50)
UNION ALL
SELECT '3-5 (524-4107)' bucket, ksmchcls, 500 * TRUNC (ksmchsiz / 500),
COUNT (*), MAX (ksmchsiz), TRUNC (AVG (ksmchsiz)) "AvgSize",
TRUNC (SUM (ksmchsiz)) "Total"
FROM x$ksmsp
WHERE ksmchsiz BETWEEN 524 AND 4107 AND ksmchcls = 'free'
GROUP BY ksmchcls, 500 * TRUNC (ksmchsiz / 500)
UNION ALL
SELECT '6+ (4108+)' bucket, ksmchcls, 1000 * TRUNC (ksmchsiz / 1000),
COUNT (*), MAX (ksmchsiz), TRUNC (AVG (ksmchsiz)) "AvgSize",
TRUNC (SUM (ksmchsiz)) "Total"
FROM x$ksmsp
WHERE ksmchsiz >= 4108 AND ksmchcls = 'free'
GROUP BY ksmchcls, 1000 * TRUNC (ksmchsiz / 1000);
4. ORA-04031 错误与 Large Pool
大池是个可选的内存区,为以下的操作提供大内存分配:
MTS会话内存和 Oracle XA 接口
Oracle 备份与恢复操作和I/O服务器进程用的内存(缓冲)
并行执行消息缓冲
大池没有LRU列表。这和共享池中的保留空间不同,保留空间和共享池中其他分配的内存使用同样的LRU列表。大块内存从不会换出大池中,内存必须是显式的被每个会话分配并释放。一个请求如果没有足够的内存,就会产生类似这样的一个ORA-4031错误:
ORA-04031: unable to allocate XXXX bytes of shared memory
("large pool","unknown object","session heap","frame")
这个错误发生时候可以检查几件事情:
1- 使用如下语句检查 V$SGASTAT ,得知使用和空闲的内存: SELECT pool,name,bytes FROM v$sgastat where pool = 'large pool';
2- 你还可以采用 heapdump level 32 来 dump 大池的堆并检查空闲的大块内存的大小
从大池分配的内存如果是LARGE_POOL_MIN_ALLOC 子节的整块数有助于避免碎片。任何请求分配小于LARGE_POOL_MIN_ALLOC 大块尺寸都将分配LARGE_POOL_MIN_ALLOC的大小。一般来说,你会看到使用大池的时候相对共享池来说要用到更多的内存。通常要解决大池中的ORA-4031错误必须增加 LARGE_POOL_SIZE 的大小。
5. ORA-04031 和共享池刷新
有一些技巧会提高游标的共享能力,从而共享池碎片和ORA-4031都会减少。最佳途径是调整应用使用绑定变量。另外在应用不能调整的时候考虑使用CURSOR_SHARING参数和FORCE不同的值来做到 (要注意那会导致执行计划改变,所以建议先对应用进行测试)。当上述技巧都不可以用的时候,并且碎片问题在系统中比较严重,刷新共享持可能有助于减轻碎片问题。但是,必须加以如下考虑:
刷新将导致所有没被使用的游标从共享池删除。这样,在共享池刷新之后,大多数SQL和PL/SQL游标必须被硬解析。这将提高CPU的使用,也会加大Latch的活动。
当应用程序没有使用绑定变量并被许多用户进行类似的操作的时候(如在OLTP系统中) ,刷新之后很快还会出现碎片问题。所以共享池对设计糟糕的应用程序来说不是解决办法。
对一个大的共享池刷新可能会导致系统挂起,尤其是实例繁忙的时候,推荐在非高峰的时候刷新
6. ORA-04031错误的高级分析
如果前述的这些技术内容都不能解决ORA-04031 错误,可能需要额外的跟踪信息来得到问题发生的共享池的快照。
调整init.ora参数添加如下的事件得到该问题的跟踪信息:
event = "4031 trace name errorstack level 3"
event = "4031 trace name HEAPDUMP level 3"
如果问题可重现,该事件可设定在会话层,在执行问题语句之前使用如下的语句: SQL> alter session set events '4031 trace name errorstack level 3';
SQL> alter session set events '4031 trace name HEAPDUMP level 3';
把这个跟踪文件发给Oracle支持人员进行排错。
重要标注: Oracle 9.2.0.5 和Oracle 10g 版本中,每次在发生ORA-4031 错误的时候会自动创建一个跟踪文件,可以在user_dump_dest 目录中找到。如果你的系统是上述的版本,你不需要再进行前面描述中的步骤。
参考信息
Metalink - http://metalink.oracle.com
<Note:1012046.6> How to Calculate Your Shared Pool Size
<Note:62143.1> Understanding and Tuning the Shared Pool
<Note:1012049.6> Tuning Library Cache Latch Contention
<Note:61623.1> Resolving Shared Pool Fragmentation
<Note:146599.1> Diagnosing and Resolving Error ORA-04031
发表评论
-
oracle删除重复记录
2009-07-16 11:16 1217有困难,找猪八戒 Q:要删除一张表中的重复记录,但是要保留一条 ... -
db2 express-c 安装后检查及安装例子数据库
2009-02-27 17:07 3397摘自http://publib.boulder.ibm.com ... -
问:如何得到与WEB-INF同级目录下的配置文件
2008-09-23 08:35 2138Q: 有如下需求:需要从WEB-INF同级的目录下读取配 ... -
讨论如何优化这条sql
2008-09-11 16:33 1601SELECT * FROM ( ... -
N Vs Exist in SQL
2008-07-02 16:39 1395N Vs Exist in SQL 原文如下: http:// ... -
SQL 指南
2008-05-27 11:45 1047http://www.sql-tutorial.com/ -
orace 分析函数
2008-05-26 09:08 1214select x.num, sum(x.num) over ( ... -
oralce tutoial 指南
2008-03-22 14:21 1034http://www.exforsys.com/tutoria ... -
查找部分字段重复的记录 ORACLE Identifying duplicate rows
2008-03-13 08:49 1969http://www.jlcomp.demon.co.uk/f ... -
oracle 资源网站
2008-01-12 11:42 1881oracle alter table table_ ... -
Top 5 Oracle Reference Books 前5本 oracle 参考书
2008-01-12 11:24 1721http://databases.about.com/od/o ... -
Oracle与DB2、MySQL取前10条记录的对比<转>
2008-01-11 16:46 2224原文:http://tech.ccidnet.com/art/ ... -
expert on e on one oracle - Thomas Kyte 读书笔记
2008-01-11 10:17 2112=============================== ... -
oracle 资源 整体理解oralce 比较好 英文网
2008-01-09 16:59 1201http://www.adp-gmbh.ch/ora/admi ... -
oracle java 插入 clob insert clob hibernate
2007-12-21 15:48 7232用jdbc 或者 hibernate http://www.w ... -
pl/sql 应用之一
2007-12-12 17:21 1144declare begin insert into x ... -
init.ora文件所在目录
2007-12-12 15:58 2168Oracle安装盘:\oracle\admin\DB名称\pf ... -
oracle faq 常见问题解答 http://www.orafaq.com/
2007-12-12 13:34 1499The Oracle FAQ http://www.oraf ... -
oracle 快速参考
2007-12-12 09:58 1095http://www.psoug.org/library.ht ... -
oracle like
2007-12-12 09:18 3417http://www.adp-gmbh.ch/ora/sql/ ...
相关推荐
1. 通过调整SHARED_POOL_SIZE、SHARED_POOL_RESERVED_SIZE和SHARED_POOL_RESERVED_MIN_ALLOC三个参数来解决ORA-04031错误。 2. 通过查询V$SHARED_POOL_RESERVED视图来确定ORA-04031错误是否由共享池保留空间中的碎片...
在深入探讨如何解决ORA-04031错误之前,我们需要先了解几个与共享池(`shared pool`)密切相关的Oracle实例参数: 1. **`SHARED_POOL_SIZE`**:此参数定义了共享池的总大小。可以设置为具体数值(例如1024),也可以...
解决ORA-04031错误通常涉及调整参数,优化内存分配策略,以及监控和分析数据库的运行状况。在ASM实例中,由于其特殊性,可能需要更大的共享池大小来满足存储管理和查询的需求。在调整参数时,应谨慎操作并进行充分的...
根据提供的部分内容,下面详细介绍解决ORA-01041错误的具体步骤: 1. **启动Oracle配置和移植工具** - 打开Oracle的“配置和移植工具”中的“Net Configuration Assistant”。 2. **本地网络服务名配置** - 在...
本文旨在探讨如何接近并解决ORA-12518/TNS-12518错误,并提供详细的故障排除指南。 #### 最后审核日期 本指南最后审核于2008年1月29日,确保了内容的时效性和准确性。 #### 故障排查细节 ##### 第一部分:处理...
通过修改服务端和客户端的配置文件,以及重启服务端计算机,可以有效解决ORA-28040和ORA-01017这两个特定的错误。此外,文中还介绍了Oracle数据库在不同版本间进行配置和通信时所涉及的一些关键配置文件和参数设置。
### Oracle 错误 ORA-00132 和 ORA-00214 解析及处理 #### 一、错误概述 在Oracle数据库管理过程中,遇到ORA-00132和ORA-00214这类错误时,往往意味着数据库配置或启动过程中出现了问题。下面将对这两个错误进行...
为了解决ORA-16038和ORA-19809错误,可以采取以下步骤: ##### 步骤一:调整恢复文件目的地大小 由于ORA-19809错误提示达到恢复文件目的地大小的限制,首先需要调整`DB_RECOVERY_FILE_DEST_SIZE`参数来扩大存储...
根据提供的描述,“登陆oracle时出现ora-15414时按照文档操作即可安全无压力”,我们可以推测此错误与配置文件`listener.ora`有关,并且可以通过调整该文件来解决。 #### ORA-15414错误含义 ORA-15414是Oracle...
总之,解决ORA-04031错误需要深入理解Oracle内存管理机制,仔细诊断问题所在,并采取适当的调整措施。这可能涉及参数调整、SQL优化以及对数据库整体架构的审查。通过以上步骤,可以有效地避免和解决这种常见的Oracle...
NULL 博文链接:https://ajita.iteye.com/blog/1725304
当尝试使用Kettle连接Oracle 12c时,可能会遇到错误"ORA-28040:没有匹配的验证协议"。这个错误通常意味着客户端和服务器之间的安全认证不兼容。 **ORA-28040错误的解释:** 此错误通常出现在Oracle数据库服务器...
本文将详细介绍如何在Windows和Linux操作系统下解决ORA-00702错误。 **ORA-00702错误解析** ORA-00702错误信息表明数据库实例试图访问一个尚未完全初始化的数据文件或控制文件。这可能是由于数据库在不正常的情况下...
在使用Oracle Data Pump工具IMPDP(Import Data Pump)进行数据导入的过程中,可能会遇到ORA-39002和ORA-39070等错误。本文将针对这些错误的排查方法进行详细介绍,帮助用户理解问题的原因及解决策略。 ### 错误...
### Oracle ORA-03113 错误解析及解决方法 #### 一、ORA-03113 错误概述 ORA-03113 是一个较为常见的Oracle错误,通常出现在网络通信...通过以上步骤,可以有效地解决ORA-03113错误,并防止类似问题在未来再次发生。
ORA-12514 错误的原因和解决方法 ORA-12514 错误是 Oracle 数据库中常见的一种错误,它的出现可能是由于多种原因引起的。下面我们将从根本上探究 ORA-12514 错误的原因,并提供相应的解决方法。 原因 1:监听器没有...
通过以上方法,我们可以有效地解决ORA-29275错误,并提高Oracle数据库的整体稳定性和数据完整性。需要注意的是,在实际操作过程中,应当根据具体情况选择最适合的解决方案。例如,在某些情况下,调整字段长度可能是...
### Oracle数据库ORA-29275错误解析与解决方案 #### 错误概述 在Oracle数据库操作过程中,遇到ORA-29275错误时,...通过上述步骤的细致分析与排查,可以有效地解决ORA-29275错误,确保Oracle数据库系统的稳定运行。
总之,解决ORA-12737错误需要对Oracle数据库的运作机制有一定理解,并结合日志信息进行系统性的排查。通过逐步检查数据库状态、监听器、网络配置、客户端版本以及使用辅助工具,大多数情况下都能找到问题的根源并...
### 解决ORA-01033:Oracle正在初始化或关闭 #### 背景与问题解析 在Oracle数据库管理中,遇到ORA-01033错误是较为常见的问题之一,该错误通常出现在数据库启动或关闭的过程中。ORA-01033错误的全称是“ORA-01033:...