Updated@2013-01-30 对于运行Oracle数据库的AIX操作系统VMM（Virtual Memory Management）层面的系统内核参数如何进行调整，这是一个很古老的话题。这篇文章力图解释一些概念，同时与时俱进地提出一些设置的建议。 通常对VMM系统内核调优的目的，在于最大限度的保护计算内存页（computational memory）不被page-out到paging space中，因为对于计算内存页（特定于Oracle数据库来说就比如是SGA和PGA）来说被page-out出去的内存页总在之后的某一时刻又会被重新page-in，通常这样会对系统性能产生负面影响。另外对于像Oracle数据库这样拥有自己的数据缓存机制（data buffer cache）的数据库应用来说，保护计算内存页更显得格外重要。 在IBM AIX 5.3 ML1之前，对于作为Oracle Database Server用途并且使用裸设备作为Datafile存储的的AIX操作系统内核参数调优的经验通常如下： maxperm%=maxclient%=(通常是一个很低的值，小于20或者30) 设置较小maxperm%值的原因在于，如果文件内存页在内存中的比例高过该参数值，那么VMM换页算法将只从文件内存页中进行偷页。将maxperm%值降低就意味着有更大的机会让VMM只从文件内存页中偷页。 minperm%=5（通常是一个比maxperm%更低的值） lru_file_repage = 1（这是默认值） 比如以下的VMM参数设置就符合该种调优方式。 root@hostname:/> vmo -a |grep “maxclient%” maxclient% = 15 root@hostname:/> vmo -a |grep “maxperm%” maxperm% = 15 root@hostname:/> vmo -a |grep “minperm%” minperm% = 10 root@hostname:/> vmo -a |grep “lru_file_repage” lru_file_repage = 1 但是实际上在AIX…
Tag: AIX
IBM AIX 5L+TSM+Oracle10.2.0.3 RAC+ASM+RMAN经验谈
1. TSM（Tivoli Storage Manager）在产品易用性方面真是不如Veritas的NBU，甚至也不如HP的Omni DP。 2. 高端带库的I/O速度不弱于盘阵，跟I/O通道个数以及驱动器个数关系很大。 3. 使用2个channel往84块单盘300G的底层作了0+1 RAID的21个物理卷组成的ASM磁盘组中（好拗口 …）restore 2T大小的数据库耗时6小时。 4. 目前看来，所有的ASM磁盘组信息都没有存在任何配置文件中，无论是进入asmcmd还是选择v$asm相关视图，都是实时从PV头部读取的信息。所以在ASM使用外部冗余的磁盘组中一块PV坏掉以后，可以直接用dd来清除该磁盘组中所有其他disk的头部信息，然后重新创建磁盘组，然后用RMAN恢复数据库，这也是当ASM磁盘组崩溃以后唯一的修复方法。 5. 条带并不是越多越好。在这个环境中，112块disk在硬件级别做了RAID 0+1的条带和镜像，操作系统中对这112/2*300G=16T的存储做了56个PV，如果在创建LV的时候又选择了条带选项（二次条带化），那么读性能将会严重下降，每秒只能达到60M的读，而如果去除二次条带化，则读性能可以上升到每秒200M。 原因：在将数据写入做了二次条带化的存储上时，首先数据在操作系统级别被打散为56个stripe，然后每个stripe在硬件级别又再次被打散为56个stripe，这样并行写的性能是没有问题的，但是在读取的时候，由于请求的数据在硬件级别是被打散在56块disk中的，而硬件级别的缓存机制在读取一块disk上的数据时将会缓存相邻的大量数据，而这些缓存对于此次读取来说都是无用的，当从另外一个disk中再读取需要的数据时，缓存又需要被腾空再容纳这个disk上的数据，但是这次缓存中又只有很小一部分数据是有用的，因此当PV越多的时候，二次条带将导致越大的性能下降。 6. 10g的新功能change tacking貌似有些bug，在头天晚上启动了change tacking，然后做了level 0备份，2.1T的数据文件总共备份出200G的备份集，第二天做了level 1备份，居然备份出2.1T的备份集，也就是change tracking告诉RMAN在这一天里面所有的data block都发生了变化，所以RMAN备出了数据库中所有block，但是实际上这很明显是不可能的，因为当天的归档日志备份只有500多M，第三天仍旧是level 1备份，就比较正常了，当天产生60多G的归档日志，但是level 1备份只花费了3分钟，这是change tracking真正的威力显示了。