继续昨天底层数据库hang住问题的研究

昨天虽然误打误撞的解决了问题，总是感觉问题出在了parallel servers上，晚上和某知名企业的哥们交流了一下，虽然年龄小，海量数据方面他经验很丰富，他的数据自从升级到11R后，也趴了好几天了，不会遭遇了我们前几天遭遇的BUG？没细问，后来谈到了我昨天的事情，他谈到了他的想法，他对parallel应用很有研究的，后来想想也有道理，11G中，虽然提供了系统对oracle内存全局调整的能力，即通过设置memory_max_target和memory_target参数实现，但大数据加载的情况下，shared_pool_size会受到挤压，在IO瓶颈严重并且内存压力大的情况下，shared_pool_size会被挤压出内存，尤其在parallel大且没设置large_pool_size的前提下，shared_pool_size会受到更大挤压，可能会把部分内容挤压出内存，这样也许会导致昨天的问题，因此，在大数据量并行加载的情况下，即使使用了11g的内存自动调整，也应该设置shared_pool_size及larget_pool_size的大小，一面shared_pool_size受到过度挤压而出现系统hang住的情况。尤其是我们底层数据库，更要注意这点。另外，这两个参数在11g里是可以动态修改的。