解决“ORA-04030: 在尝试分配 64544 字节 (sort subheap,sort key) 时进程内存不足”
今天BI项目组中的一个实施工程师向我反映，说数据库服务器的内存不足了，在PL/SQL中执行一个查询报错，错误信息为“ORA-04030: 在尝试分配 64544 字节 (sort subheap,sort key) 时进程内存不足”，说我内存分配得太小了，能不能多分配点内存给oracle使用。查询的SQL为select * from JST_XSJL ORDER BY SCDM ASC 。
收到这个信息后，我马上登录到数据库服务器中查看了内存的使用情况和oracle的内存参数，发现并没什么问题，资源应当是够的，用sqlplus查询上面的SQL，并执行成功，查询该表的记录总行数为300多万条。操作系统是AIX 6.1的，数据库版本为11G,内存管理方式为AMM，内存为16G，我设置的memory_target和memory_max_target设置为10G，从操作系统上看内存使用率为95%的样子。
想着同事说是在pl/sql中执行的，于是我也用pl/sql连接上去做查询，结果还真出那个错误信息了。这就奇怪了，为什么我在服务器上执行并没有问题，而用pl/sql执行就报错了。这时想到是不是操作系统层面有限制内存，于是在操作系统查询
[test2:oracle:/home/oracle] ulimit -atime(seconds) unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes) 4194304
memory(kbytes) unlimited
coredump(blocks) unlimited
nofiles(descriptors) unlimited
threads(per process) unlimited
processes(per user) unlimited
发现内存方面并不存在限制，上网搜索大部分都是说orace内存参数设置的不合理导致，需要修改内存参数。于是我将数据库停掉再开启，故障依旧，这更证明了不是我oracle内存分配的问题。最后查到篇文章，文章中有个假设，并最终验让了这个假设的成立，下面是原文
为此我做了一个假设：虽然目前的ulimit -a显示的结果表示ORACLE用户进程的数据段没有限制，但是这个修改很可能是在监听器启动之后，监听器启动之后继承了先前的ulimits的所有设置，而在此后重新修改的并没有反馈到监听器中。而通过客户端sqlplus连到数据库中的时候，
监听器派生出的服务器进程继承了监听器中的ulimits相关的设置，导致服务器进程的数据段还是有限制的。而通过本地连接的数据库不通过监听器，直接继承了当前的设置，所以本地连接建立索引不会报ORA-4030错误。
监听器派生出的服务器进程继承了监听器中的ulimits相关的设置，导致服务器进程的数据段还是有限制的。而通过本地连接的数据库不通过监听器，直接继承了当前的设置，所以本地连接建立索引不会报ORA-4030错误。
看到这里，也就解释了为什么我直接在服务器上查询不报错，而在客户端用pl/sql查询却报错，于是将监听重启，再在pl/sql中执行查询，搞定。
著作权归作者所有
如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！
赞0Ctrl+Enter 发表
作者其他文章
评论 0 · 赞 4
评论 0 · 赞 2
评论 1 · 赞 2
评论 0 · 赞 0
评论 0 · 赞 0
添加新评论0 条评论