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