me waited: 5.627769 secs p2: 'number'=0x101
p3: 'tries'=0x0
2.> time waited: 0.465190 secs p2: 'number'=0x101
p3: 'tries'=0x0
3.> time waited: 0.082002 secs p2: 'number'=0x101
p3: 'tries'=0x0
}
从DUMP信息看来，这次的情况跟上次类似，大量的latch: shared pool等待。
客户的DB配置情况：
物理内存24G，而MEMORY_TARGET设置为22G，感觉配置的非常不合理，客户的情况跟我之前处理过的一个CASE很像（ORA-609：疑似MEMORY_TARGET设置过大导致的宕机http://blog.csdn.net/zhou1862324/article/details/17288103），都是MEMORY_TARGET参数设置过大导致出现SWAP PAGE IN/OUT的情况，最终导致数据库HANG住或宕机。
之前的CASE发生在另一位客户的一套非常重要的生产库上，数据库屡次宕机客户苦不堪言，而客户接收了我的建议将MEMORY_TARGET调低到一个合理的值之后，类似的问题没有再发生了。
所以，对于这个案例，我给了客户2个建议：
1.减少 memory_target 和 memory_max_target，预留更多内存供OS使用，减少发生SWAP PAGE IN/OUT的可能性。
2.启用hugepages，hugepages本身就是锁定在内存中不能被SWAP的，但Hugepages与memory_target不兼容，所以需要禁用memory_target，设置sga_target和pga_aggregate_target。
关于HUGEPAGE，可以参考我转的一篇文章HugePages on Oracle
Linux 64-bit（http://blog.csdn.net/zhou1862324/article/details/17540277）。
解决方法：
最终客户选择了调小memory_target 和 memory_max_target，问题未再出现。
|