2004年3月5日，发现Oracle公布了有关此问题的一些说明和部分解决方法。大致的内容是，AIX5.2可以打个补丁来获得更好的效果，而其他版本只能通过设置以下环境变量来减少消耗：
AIXTHREAD_SCOPE=S;eXPort AIXTHREAD_SCOPE
NUM_SPAREVP=1; export NUM_SPAREVP（AIX4.3和5.1）
具体内容参考Metalink文档：259983.1 "Memory Consumption on AIX"，此文档是18-DEC-2003创建的，最近更新28-JAN-2004。
2004年3月12日，我们拿了一台新的M85，安装了AIX5.2开始测试这一结果。设置这些环境可以起一定的作用，但没有明显效果。
根据文档说明，安装AIX APAR IY49415补丁，执行如下步骤：
从这里下在相关脚本：http://updates.oracle.com/ARULink/PatchDetails/PRocess_form?aru=5336110
1) save your current version of $ORACLE_HOME/oracle
2) create a working Directory $ORACLE_HOME/relink
3) cd to $ORACLE_HOME/relink
4) unzip the relinking package
5) link $ORACLE_HOME/bin/oracle to ./oracle0
6) run the script ./genscript to generate some required files and scripts
7) run ./relink.sh to generate the new oracle binary oracle0.new.$$
8) copy oracle0.new.$$ to $ORACLE_HOME/bin/oracle and verify that the permissions match the original oracle binary.
验证结果很明显，内存占用改善了很多，没有打补丁的一个空连接server进程占用最低都是5M多，而现在只有2M多，改善了50%！
hawk1> ps v 17686600 （没打补丁的空连接）
PID TTY STAT TIME PGIN SIZE rss LIM TSIZ TRS %CPU %MEM COMMAND
17686600 - A 0:00 0 5496 24600 xx 45561 19104 0.0 0.0 oracle
localhost> ps v 557160 （打过补丁的空连接）
PID TTY STAT TIME PGIN SIZE RSS LIM TSIZ TRS %CPU %MEM COMMAND
557160 - A 0:00 815 2360 15432 32768 46449 13072 0.0 1.0 oracleor
虽然说这里ps v看到的结果不是很准确，但是二者使用相同的标准计算，并不影响对比结果，而且和我们使用NMON的统计结果也是一致的。
至此，Oracle9i在AIX上的内存占用问题算是基本解决了，前后经历了快一年的时间，这恐怕是我关注一个Oracle问题时间最久的一次，理由很简单，这是工作需要，生产需要，要知道这么随便一搞，给我们剩下了很多麻烦，之前为了答应更多的连接，我们不得不将内存从12G扩容到24G，现在一降下来可以为企业节省很多硬件投入，究竟这玩艺内存卖的还是挺贵的，而这是无成本的。
过去这段时间，我工作的其中之一就是在为一个电信业务系统的升级做预备，在两台IBM M85（6CPU*12G MEM AIX 5L）上对ORACLE9I RAC做具体的测试工作，开始的时候一切都很顺利，但后来却碰到一个难题，就是Oracle 9i的单个进程占用的内存过多。
经过一段时间测试，在先后解决了其它问题后，最后的主要问题集中到了内存上，ORACLE9i在AIX 5L上每个进程都占用了很多内存，一个空连接进程就会用到5M多的内存，而众所周知，Oracle8i的单个进程占用的内存一般是2~3M，所以这就引起了我们的高度重视，因为假如按此计算，1000个连接什么事不做就要5G内存了！而我们的实际应用连接数比这还要多。
在出现问题之后，我先后对ORACLE进行了不同方向的调整，也问过了一些朋友以及IBM和ORACLE的技术支持， 翻遍了国内外我所知道的论坛，都没有看到任何有意思的消息，更不要说解决方案了。这让我开始怀疑是Oracle9i的BUG，果然在6月底Oracle公布了这个BUG（我是在7月底看到的，因为7月份的大部分时间在处理别的事）！造成这个问题是因为AIX上C的编译器问题，使得本来可以共享的部分，最后都没有共享，造成每个进程都浪费了大约1MB的内存。详情参见本文最后BUG：3028673的描述。
为了验证确实是AIX的问题，我在另外一台HP-UX B11.11上进行了同样的测试，结果显示Oracle9i的单个进程仍然占用很多内存！经过分析发现这是由于两方面原因造成的：
1、Oracle9i的初始化参数CURSOR_SPACE_FOR_TIME从默认的FALSE改成了TRUE；
2、HP-UX上的Oracle9i将虚拟内存数据页（virtual memory data pages）的默认值从原来的D(4KB)改成了L(1GB)。
使用/usr/bin/chatr $ORACLE_HOME/bin/oracle查看oracle程序的内部属性 ，我们发现虚拟内存的text段从原来的16M改成了64M，而DATA段从原来的64M改成了L（最大可达到1GB）。经过测试验证 ，DATA段这个参数直接影响了Oracle9i单个进程所占用的内存的大小 。对于空连接来说，4MB是扩展的临界点，因为空连接是扩不到16MB（4MB的下一个可设DATA段大小）。
Oracle8i和Oracle9i虚拟内存默认值对比：
8i
......
shared library binding:
deferred
global hash table disabled shared vtable support disabled segments:
index type address flags size
5 text 4000000000000000 z-r-c 16M
6 data 8000000100000000 ---m- 64M
executable from stack: D (default)kernel assisted branch prediction enabled lazy swap allocation for dynamic segments disabled
9i
.........
shared library binding:
deferred
global hash table disabled shared vtable support disabled segments:
index type address flags size
5 text 4000000000000000 z-r-c 64M
6 data 8000000100000000 ---m- L (largest possible)executable from stack: D (default)kernel assisted branch prediction enabled lazy swap allocation for dynamic segments disabled
我们可以使用/usr/bin/chatr +pd newsize $ORACLE_HOME/bin/oracle来更改DATA段的可用内存大小，对于text段的内存大小我们也可以使用chatr +pi来改，但gototop并不建议你这样做，因为text段是给命令用的。
至此，我就在想了，自然在HP-UX上是因为这个原因造成的，那么在AIX上除了C编译器的原因之外，是否也存在着同样的问题呢？到目前为止，gototop还没有的等到任何可靠的消息来证实这一点，但我猜想可能性很大。
附、BUG:3028673描述
问题陈述:
ORACLE ON AIX DOES NOT SHARE MANY CONST STRUCTS - PER PROCESS MEMORY OVERHEAD
--------------------------------------------------------------------------------
*** 06/27/03 10:31 am ***
=========================
PROBLEM:
1. Clear description of the problem encountered:
Oracle on IBM AIX platforms (AIX 5L and 4.3.3) use a large amount of memory per dedicated connection. For Oracle 9.2 on AIX 5L the memory required per idle Oracle process appears to be about 5Mb. A significant portion of this is related to non-shared const structures (probably about 1Mb) .
This bug is to track the issue of the non-shared const structures.
