1.2.2 一个经验公式
    现在，根据上面这些假定，我们来看SGA 实际能达到多少内存。在1G 的内存的服务器上，我们能分配给SGA 的内存大约为400—500M。若是2G 的内存，大约可以分到1G的内存给SGA，8G 的内存可以分到5G的内存给SGA。当然我们这里是以默认的排序部分内存sort_area_size=64k进行衡量的，假如我们需要调大该参数和 hash_area_size等参数，然后我们应该根据并发的进程的数量，来衡量考虑这个问题。

事实上，通常我们更习惯通过直观的公式化来表达这样的问题：
OS 使用内存+SGA+并发执行进程数*(sort_area_size+hash_ara_size+2M) < 0.7*总内存
(公式是死的，系统是活的，实际应用的调整不必框公式，这不过是一个参考建议)

       在我们的实际应用中，假如采用的是裸设备，我们可适当的增大SGA(如果需要的话)。由于目前几乎所有的操作系统都使用虚拟缓存，所以实际上如果就算SGA 设置的比较大也不会导致错误，而是可能出现频繁的内存页的换入与换出(page in/out)。在操作系统一级如果观察到这个现象，那么我们就需要调整内存的设置。

1.2.3 各个参数的设置
   那么SGA中的各个参数具体应该按照什么样的原则来设置呢，下面进行讨论：
log_buffer
    对于日志缓冲区的大小设置，通常我觉得没有过多的建议，因为参考LGWR写的触发条件之后，我们会发现通常超过3M意义不是很大。作为一个正式系统，可能考虑先设置这部分为log_buffer=1—3M 大小，然后针对具体情况再调整。

large_pool_size
    对于大缓冲池的设置，假如不使用MTS，建议在20—30M 足够了。这部分主要用来保存并行查询时候的一些信息，还有就是RMAN 在备份的时候可能会使用到。如果设置了MTS，则由于UGA部分要移入这里，则需要具体根据session最大数量和 sort_ares_size 等相关会话内存参数的设置来综合考虑这部分大小的设置，一般可以考虑为 session * (sort_area_size + 2M)。这里要提醒一点，不是必须使用MTS，我们都不主张使用MTS，尤其同时在线用户数小于500的情况下。。

java_pool_size
    假如数据库没有使用JAVA，我们通常认为保留10—20M大小足够了。事实上可以更少，甚至最少只需要32k，但具体跟安装数据库的时候的组件相关(比如http server)。

shared_pool_size
    这是迄今为止最具有争议的一部分内存设置。按照很多文档的描述，这部分内容应该几乎和数据缓冲区差不多大小。但实际上情况却不是这样的。首先我们要考究一个问题，那就是这部分内存的作用，它是为了缓存已经被解析过的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。

    对于一个没有充分使用或者没有使用绑定变量系统，这可能给我们带来一个严重的问题。所谓没有使用bind var 的SQL，我们称为Literal SQL。也就是比如这样的两句SQL我们认为是不同的SQL,需要进行2 次硬解析：
select * from EMP where name = ‘TOM’;
select * from EMP where name = ‘JERRY’;
    假如把 ’TOM’ 和 ’JERRY’ 换做变量V，那就是使用了bind var，我们可以认为是同样的SQL 从而能很好地共享。共享SQL 本来就是shared_pool_size 这部分内存存在的本意，oracle的目的也在于此，而我们不使用bind var 就是违背了oracle 的初衷，这样将给我们的系统带来严重的问题。当然，如果通过在操作系统监控，没有发现严重的cpu问题，我们如果发现该共享池命中率不高可以适当的增加 shred_pool_size。但是通常我们不主张这部分内存超过800M（特殊情况下可以更大）。
事实上，可能的话我们甚至要想办法避免软分析，这在不同的程序语言中实现方式有差异。我们也可能通过设置session_cached_cursors 参数来获得帮助（这将增大PGA）
关于使用绑定变量的话题，在下面的应用优化中继续讨论。

Data buffer
   现在我们来谈数据缓冲区，在确定了SGA 的大小并分配完了前面部分的内存后，其余的，都分配给这部分内存。通常，在允许的情况下，我们都尝试使得这部分内存更大。这部分内存的作用主要是缓存 DB BLOCK，减少甚至避免从磁盘上获取数据，在8i中通常是由db_block_buffers*db_block_size 来决定大小的。如果我们设置了buffer_pool_keep 和buffer_pool_recycle，则应该加上后面这两部分内存的大小。

可以看出，设置SGA时基本上应该掌握的原则是：
data buffer 一般可以尽可能的大
shared_pool_size 应该适度
log buffer 在 1MB 以内就可以了

假定oracle是 32 bit ,服务器RAM大于2G ，注意你的PGA的情况，,则建议
shared_pool_size + data buffer +large_pool_size + java_pool_size < 1.6G

再具体化，如果512M RAM
建议 shared_pool_size = 50M, data buffer = 200M

如果1G RAM
shared_pool_size = 100M , data buffer = 500M

如果2G RAM
shared_pool_size = 150M ,data buffer = 1.2G

物理内存再大已经跟参数没有关系了

假定64 bit ORACLE
内存4G
shared_pool_size = 200M , data buffer = 2.5G

内存8G
shared_pool_size = 300M , data buffer = 5G

内存 12G
shared_pool_size = 300M-----800M , data buffer = 8G

1.3 32bit 与 64bit 对SGA的影响
为什么在上面SGA大小设置的经验规则中要分 32bit Oracle 和 64bit Oracle 呢，是因为这关系到SGA大小的上限问题。在32bit的数据库下，通常oracle只能使用不超过1.7G的内存，即使我们拥有12G的内存，但是我们却只能使用1.7G，这是一个莫大的遗憾。假如我们安装64bit的数据库,我们就可以使用很大的内存，几乎不可能达到上限。但是64bit 的数据库必须安装在64bit 的操作系统上，可惜目前windows上只能安装32bit的数据库，我们通过下面的方式可以查看数据库是 32bit 还是 64bit ：

SQL> select * from v$version;
BANNER
---------------------------------------------------------------- 
Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production
PL/SQL Release 8.1.7.0.0 - Production
CORE 8.1.7.0.0 Production
TNS for 32-bit Windows: Version 8.1.7.0.0 - Production
NLSRTL Version 3.4.1.0.0 – Production

在UNIX平台下的显示有所不同，明显可以看出是 64bit Oracle ，比如在HP-UX平台上：

SQL> select * from v$version;
BANNER
---------------------------------------------------------------- 
Oracle8i Enterprise Edition Release 8.1.7.4.0 - 64bit Production
PL/SQL Release 8.1.7.4.0 - Production
CORE 8.1.7.0.0 Production
TNS for HPUX: Version 8.1.7.4.0 - Production
NLSRTL Version 3.4.1.0.0 – Production 

      32bit的oracle无论跑在32bit或者64bit的平台都有SGA的限制的，而对于32bit的平台只能跑32bit的oracle，但是在特定的操作系统下，可能提供了一定的手段，使得我们可以使用超过1.7G 的内存，达到2G 以上甚至更多。由于我们现在一般都使用64bit Oracle，因此关于如何在32bit平台上扩展SGA大小的问题不再赘述。