AGNOSTIC ANALYSIS
===================
1. nmon shows virtual memory swapping does not occur at all - see attached file --nmon根本没有监控到swap动作
2. Oracle Database Server is 11.2.0.3 and contains fix for 10220118
3. Server configuration
real mem: 144GB
lowest value of fre memory : 87,65 GB --剩余内存充足
4. DBRM seems to use a wrong OS statistics - trace file is attached
WORKAROUND?
===========
No
TECHNICAL IMPACT
================
Wrong diagnostic analyze.
Message is bothering customer's DBA when in fact the warning message is
misleading
RELATED ISSUES (bugs, forums, RFAs)
===================================
http://myforums.oracle.com/jive3/thread.jspa?threadID=1104581
10220118
HOW OFTEN DOES THE ISSUE REPRODUCE AT CUSTOMER SITE?
====================================================
Always
DOES THE ISSUE REPRODUCE INTERNALLY?
====================================
No
EXPLAIN WHY THE ISSUE WAS NOT TESTED INTERNALLY.
================================================
Unavailable Data Volume
IS A TESTCASE AVAILABLE?
========================
No
Link to IPS Package:
====================
not available
DBRM(Database Resource Manager)是11gR2中新特性中出现的后台进程，会在alert.log告警日志中反映OS操作系统最近5分钟是否有剧烈的swap活动，而在AIX平台上，由于BUG：14731911的存在，oracle的这个进程谎报了内存进行了swapin和swapout动作。我们知道，只有当物理内存真的不够用的情况下，才会去用swap（通常会配置成物理内存的2倍），而swap是非常耗费性能的（从物理磁盘读写）。但是个人认为这个bug的危害性并不大，仅仅只是在alert.log日志中报了一个WARNING，并没有因为这个影响导致对数据库更加负面的影响，因此是否打补丁到11.2.0.4就见仁见智了，如果想让alert.log平安无事，那么就可以升级一下patch。当然了，如果真的是因为OS内存吃紧造成的swap动作，就要区别对待了，因为此时的确会对数据库造成严重影响。要区分是否真的内存不足而非系统误报，那么主要还是通过nmon，topas，vmstat等监控工具来进行分析（linux下还可以用free监控）
对于AIX平台，其实还有另一个bug，只不过是unpublished base bug，而不是port-specific bug
AIX Platform
If your Platform is IBM-AIX then this is not the only possible reason for this alert log message.
For IBM AIX on POWER Systems (64-bit), there is also next known port-specific bug:
Bug 14731911 - FALSE SWAP WARNING MESSAGES PRINTED TO ALERT.LOG ON AIX
with unpublished base bug:
Bug 11801934 : WRONG PAGE-IN AND PAGE-OUT OS VM STATS IN AIX.
在vmware平台中的这个WARNING信息，如果不是bug引起，则很有可能和ora-04031/ora-04030相关，这个就严重多了
VMWare
Under VMWare, the messages may perhaps indicate a more serious issue, even when no memory related ORA-4031/ORA-4030 errors are reported.
Under circumstances, an instance in a virtual machine may be simply terminated by PMON due to error 471 without further errors in the alert log.
The OS logs may in such case report an out of memory condition like below:
[root@vmh ~]# grep Kill /var/log/messages*
/var/log/messages-20140629:Jun 27 18:29:06 vmh-msfc-dodp02 kernel: [1895074.304941] Out of memory: Kill process 42094 (oracle) score 391 or sacrifice child
/var/log/messages-20140629:Jun 27 18:29:06 vmh-msfc-dodp02 kernel: [1895074.305203] Killed process 42094, UID 303, (oracle) total-vm:189081588kB, anon-rss:27412kB, file-rss:109612
通常解决OS内存swap问题有以下几种方案：
1. 诊断是否存在内存泄露的进程，解决内存泄露 2. 调优SGA/PGA，减少oracle对内存的占用 3. 利用/proc/sys/vm/drop_caches，暂时释放一些cache的内存（Linux） 4. 调整系统VM内存管理参数， 例如Linux上sysctl.conf中的以下几个参数:
vm.min_free_kbytes:Raising the value in /proc/sys/vm/min_free_kbytes will cause the system to start reclaiming memory at an earlier time than it would have before.
vm.vfs_cache_pressure:At the default value of vfs_cache_pressure = 100 the kernel will attempt to reclaim dentries and inodes at a “fair” rate with respect