Oracle 内存调整与优化

爱她吗

SQL，而使其能被重用，不再解析。对于一个新的SQL（shared_pool 里面不存在已经解析的可用的相同的SQL），数据库将执行硬解析，这是一个很消耗资源的过程。而若已经存在，则进行的仅仅是软分析（在共享池中寻找相同SQL），这样消耗的资源大大减少。所以我们期望能多共享一些SQL，并且如果该参数设置不够大，经常会出现ora-04031错误，表示为了解析新的　　SQL，没有可用的足够大的连续空闲空间，这样自然我们期望该参数能大一些。但是该参数
　　的增大，却也有负面的影响，因为需要维护共享的结构，内存的增大也会使得SQL 的老化的代价更高，带来大量的管理的开销，所有这些可能会导致CPU 的严重问题。在一个充分使用绑定变量的比较大的统中，shared_pool_size 的开销通常应该维持在300M 以内。除非系统使用了大量的存储过程、函数、包，比如oracle erp这样的应用，可能会达到500M甚至更高。于是我们假定一个1G内存的系统，可能考虑设置该参数为100M，2G 的系统考虑设置为150M,8G 的系统可以考虑设置为200—300M。
　　Data buffer
　　主要作用缓存DB BLOCK，减少甚至避免从磁盘上获取数据，通常，在允许的情况下，我们都尝试使得这部分内存更大。