AIX上升级CPUApr2010

周末有个加班，需要在一台sever上升级22个instance，数据库从9207升级到9208，在打一个CPUApr2010。在这里简单记录一下升级的过程和经验。

从这个架构来看，这个server上的数据库属于库小且多的类型，虽然每个库都很小，也就几个G，但是数量不少。所以在做9207升级到9208时候，我选择了在升级完oracle软件之后，并发的升级数据字典，来提高效率。同时，由于升级数据字典大部分是sga内的操作，比如编辑，生成数据字典等，为了加快速度，我也将原来100M的shared_pool_size临时的加大了。同时为了保证并发，多个数据库能启动一起跑，也不能加太多。最后找到一个比较平衡的值：sga max size为600M，shared pool size 为200M，java pool为200M，执行catpatch脚本的时候，剩余的物理内存：

可以看到在2个instance起来后，并且同时跑catpatch脚本的时候，大约剩余的物理内存为4M左右（1000个页面，每个页面4K，因此大约为4M）。至于为什么只启动2个600M sga的库，就把物理内存压的那么死，后面我会进一步分析。

升级9207到9208的过程很顺利，原来估计每个库1小时左右的时间，在执行的时候，也就每个库6，7分钟左右。

升级完后，开始打CPUApr2010的补丁。

在利用opatch apply的时候，报错：
OPatch encounters the following issues during file patching:

ok，这是这个patch在read me中说到的issue：

于是按照wordround的方式操作，执行slibclean之后，再次执行opatch。没想到，这次报错的是：

由于用opatch rollback进行回滚，回滚成功，再次进行opatch，还是遇到libjox9.a的报错，再次运行rollback_.sh 脚本，不过此次，不再提示脚本运行成功，而是提示libjox9.a正在被使用，无法回滚：

用fuser和lsof看，看不出是谁用在这个文件：

尝试重命名：
[resoprod:oracle:/u01/oracle/product/9.2.0/.patch_storage/9352224:] mv $OH//lib/libjox9.a $OH//lib/libjox9.a.bak20100710

再次opatch apply，成功！

这里遇到的一个问题，就是在opatch的时候，aix中会有写lib的文件会被占用，虽然在opatch的read me中会建议使用slibclean来清理，但是在实际的使用情况下往往会不适用，最好的方式就是用cp一个同名的，将原来被占用的那个mv成别的名字。再重新opatch。

最后，来说说那个机器的内存使用情况的问题。之前可能你会觉得奇怪，为什么只是启动了2个instance，每个instance的sga max size为600M，2个合计也就1.2G，为什么在执行catpatch的时候，剩余内存会那么少？

这个我在事后检查了主机的参数设置。

我们在数据库升级和patch完之后，恢复到原来sga大小，启动所有的实例，检查机器的剩余内存：

剩余内存大约为3926×4k=16M

继续检查内存情况：

我们看到maxperm为80%。我个人认为，maxperm是用来设置non-computational的分页，（参考《Overview of AIX page replacement》此文），而non-computational的分页，也就是用于文件系统buffer，一般如果database使用裸设备，不经过文件系统缓存，maxperm可以设置成3%～5%，而对于文件系统做datafile的database，这个值也只要设置成20%～30%左右即可。把太多物理内存用于文件系统buffer，是没有必要的，对于database来说，将数据块从datafile中读取之后，就是在db buffer cache中进行运算了。

并且，在IBM的官方文档中也找到相关的文章也印证我的猜想。可见《Oracle 9i在AIX上的性能调整 — 内存篇》：
在Oracle数据库应用的环境下，可以将MINPERM和MAXPERM分别设为5%和20%甚至更小，从而使内存更多地被用于Oracle的SGA而不是系统的文件缓存。