如何解决ORA-04031 错误
程序员文章站
2022-05-22 12:27:19
...
今天在做项目的时候,因为改了远程访问的IP,所以一直在报如下的错误:
百度了下。搜到如下解决方案:
1.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
现把原文链接放上:http://www.dbanotes.net/Oracle/Ora-04031.htm
有兴趣的朋友可以去看看。
ORA-04031: 无法分配 4096 字节的共享内存 ("shared pool","select user#,type# from user...","Typecheck heap","kgghteInit")
百度了下。搜到如下解决方案:
1.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
现把原文链接放上:http://www.dbanotes.net/Oracle/Ora-04031.htm
有兴趣的朋友可以去看看。
推荐阅读
-
如何解决暴风转码视频翻转 视频翻转教程
-
笔记本开机进不去系统 错误代码0xc000000f的解决办法
-
XP系统设备管理器视频控制器VGA有黄色问号如何解决?
-
XP系统设备管理器视频控制器VGA有黄色问号如何解决?
-
解决WinXP系统Internet Explorerr脚本错误问题的方法
-
win10系统还原出现Usage Error 10099该如何解决?
-
SQLServer2000 报1053错误(服务没有及时响应或控制请求)的解决方法
-
清除SQL SERVER错误日志出现操作系统错误的解决方法
-
MySQL server has gone away错误提示解决方法
-
Photoshop CS6error16错误怎么解决 轻轻松松摆平它