SGA包含的组件：共享池（shared pool）；数据库缓冲区高速缓存（database buffer cache）；日志缓冲区（redo buffer cache）；大池；Java池；流池等。
SGA相关视图：
v$sga：V$SGA这个视图包括了SGA的的总体情况，只包含两个字段：name（SGA内存区名字）和value（内存区的值，单位为字节）。它的结果和show sga的结果一致。
v$sgastat：10g之前用于查看各SGA组件大小。V$SGAINFO的作用基本和V$SGA一样，只不过把Variable size的部分更细化了一步
v$sgainfo：10g及10g之后才有的。用于查看SGA组件大小更简便。
v$sga_dynamic_components：这个视图记录了SGA各个动态内存区的情况，它的统计信息是基于已经完成了的，针对SGA动态内存区大小调整的操作。
v$sga_dynamic_free_memory：这个视图只有一个字段就是用来表示SGA当前可以用于调整各个组件的剩余大小。
v$sga_target_advice：该视图可用于建议SGA大小设置是否合理。
SELECT a.sga_size,--sga期望大小
a.sga_size_factor,--期望sga大小与实际sga大小的百分比
a.estd_db_time,--sga设置为期望的大小后，其dbtime消耗期望的变化
a.estd_db_time_factor,--修改sga为期望大小后，dbtime消耗的变化与修改前的变化百分比
a.estd_physical_reads--修改前后物理读的差值
FROM v$sga_target_advice a;
--查看当前的sga大小
show parameter sga_max_size;
--修改sga值
alter system set sga_max_size=864M scope=spfile;--要重启数据库
alter system set sga_target=864M;
一、共享池
1、共享池相关视图
如何查看共享池多大合适，先查看statistics_level参数是否为typical或者all，然后统计共享池信息（内存顾问）
1.1 v$shared_pool_advice视图：可用于建议共享池大小的设置
select shared_pool_size_for_estimate sp, --估算的共享池大小（m为单位）
shared_pool_size_factor spf, --估算的共享池大小与当前大小比
estd_lc_memory_objects elm,--估算共享池中库缓存的内存对象数
estd_lc_size el,--估算共享池中用于库缓存的大小（M为单位）
estd_lc_time_saved elt,--估算将可以节省的解析时间。这些节省的时间来自于请求处理一个对象时，重新将它载入共享池的时间消耗和直接从库缓存中读取的时间消耗的差值。
estd_lc_time_saved_factor as elts,--估算的节省的解析时间与当前节省解析时间的比
estd_lc_memory_object_hits as elmo--估算的可以直接从共享池中命中库缓存的内存对象的命中次数
from v$shared_pool_advice;
1.2 V$SHARED_POOL_RESERVED视图 ：存放了共享池保留区的统计信息
--以下字段只有当参数SHARED_POOL_RESERVED_SIZE设置了才有效
select a.FREE_SPACE,--保留区的空闲空间数。
a.AVG_FREE_SIZE,--保留区的空闲空间平均数。
a.FREE_COUNT,--保留区的空闲内存块数
a.MAX_FREE_SIZE,--最大的保留区空闲空间数
a.USED_SPACE,--保留区使用空间数
a.AVG_USED_SIZE,--保留区使用空间平均数
a.USED_COUNT,--保留区使用内存块数
a.MAX_USED_SIZE,--最大保留区使用空间数
a.REQUESTS,--请求再保留区查找空闲内存块的次数
a.REQUEST_MISSES,--无法满足查找保留区空闲内存块请求，需要从LRU列表中清出对象的次数
a.LAST_MISS_SIZE,--请求的内存大小，这次请求是最后一次需要从LRU列表清出对象来满足的请求
--以下字段无论参数SHARED_POOL_RESERVED_SIZE是否设置了都有效
a.MAX_MISS_SIZE,--所有需要从LRU列表清出对象来满足的请求中的内存最大大小
a.REQUEST_FAILURES,--没有内存能满足的请求次数（导致4031错误的请求）
a.LAST_FAILURE_SIZE,--没有内存能满足的请求所需的内存大小（导致4031错误的请求）
a.ABORTED_REQUEST_THRESHOLD,--不清出对象的情况下，导致4031错误的最小请求大小
a.ABORTED_REQUESTS,--不清出对象的情况下，导致4031错误的请求次数
a.LAST_ABORTED_SIZE--不清出对象的情况下，最后一次导致4031错误的请求大小
from V$SHARED_POOL_RESERVED a
可以根据后面4个字段值来决定如何设置保留区的大小以避免4031错误的发生
1.3 v$db_object_cache：显示了所有被缓存在library cache中的对象，包括表、索引、簇、同义词、PL/SQL存储过程和包以及触发器
SELECT o.owner,--对象所有者
o.name,--对象名称
o.db_link,--如果对象存在db link的话，db link的名称
o.namespace,--库缓存的对象命名空间
o.type,--对象类型
o.sharable_mem,--对象消耗的共享池中的共享内存
o.loads,--对象被载入次数。即使对象被置为无效了，这个数字还是会增长
o.executions,--对象执行次数，但本视图中没有被使用。可以参考视图v$sqlarea中执行次数
o.locks,--当前锁住这个对象的用户数（如正在调用、执行对象）
o.pins,--当前pin住这个对象的用户数（如正在编译、解析对象）
o.kept,-- 对象是否被保持，即调用了DBMS_SHARED_POOL.KEEP来永久将对象pin在内存中。(YES | NO)
o.child_latch,--正在保护该对象的子latch的数量
o.invalidations --无效数
FROM v$db_object_cache o;
1.4 v$sql、v$sqlarea 、v$sqltext：
这三个视图都可以用于查询共享池中已经解析过的SQL语句及其相关信息。
V$SQL中列出了共享SQL区中所有语句的信息，它不包含GROUP BY字句，并且为每一条SQL语句中单独存放一条记录；
V$SQLAREA中一条记录显示了一条共享SQL区中的统计信息。它提供了有在内存中、解析过的和准备运行的SQL语句的统计信息；
V$SQLTEXT包含了库缓存中所有共享游标对应的SQL语句。它将SQL语句分片显示。
SELECT s.sql_text,--游标中sql语句的前1000个字符
s.sharable_mem,--被游标占用的共享内存大小。如果存在多个子游标，则包含所有子游标占用的共享内存大小。
s.persistent_mem,--用于打开这条语句的游标的生命过程中的固定内存大小。如果存在多个子游标，则包含所有子游标生命过程中的固定内存大小。
s.runtime_mem,--打开这条语句的游标的执行过程中的固定内存大小。如果存在多个子游标，则包含所有子游标执行过程中的固定内存大小。
s.sorts,--所有子游标执行语句所导致的排序次数
s.version_count,--缓存中关联这条语句的子游标数
s.loaded_versions,--缓存中载入了这条语句上下文堆（kgl heap 6）的子游标数
s.open_versions,--打开语句的子游标数
s.users_opening,--打开这些子游标的用户数
s.fetches,--sql语句的fetch数
s.executions,--所有子游标的执行这条语句次数
s.px_servers_executions,
s.end_of_fetch_count,
s.users_executing,--通过子游标执行这条语句的用户数
s.loads,--语句被载入和重载入的次数
s.first_load_time,--语句被第一次载入的时间戳
s.invalidations,--所有子游标的无效次数
s.parse_calls,--所有子游标对这条语句的解析调用次数
s.disk_reads,--所有子游标运行这条语句导致的读磁盘次数
s.direct_writes,
s.buffer_gets,--所有子游标运行这条语句导致的读内存次数
s.application_wait_time,
s.concurrency_wait_time,
s.cluster_wait_time,
s.user_io_wait_time,
s.plsql_exec_time,
s.java_exec_time,
s.rows_processed,--这条语句处理的总记录行数
s.command_type,--oracle命令类型代号
s.optimizer_mode,--执行这条的优化器模型
s.optimizer_cost,
s.optimizer_env,
s.optimizer_env_hash_value,
s.parsing_user_id,--第一次解析这条语句的用户的id
s.parsing_schema_id,--第一次解析这条语句所用的schema的id
s.parsing_schema_name,
s.kept_versions,--所有被dbms_shared_pool包标识为保持（keep）状态的子游标数
s.address,--指向语句的地址
s.hash_value,--这条语句在library cache中hash值
s.old_hash_value,
s.plan_hash_value,
s.module,--在第一次解析这条语句是通过调用dbms_application_info.set_module设置的模块名称
s.module_hash,--模块的hash值
s.action,--在第一次解析这条语句是通过调用dbms_application_info.set_action设置的动作名称
s.action_hash,--动作的hash值
s.serializable_aborts,--所有子游标的事务无法序列化的次数，这会导致ora-08177错误
s.outline_category,
s.cpu_time,
s.elapsed_time,
s.outline_sid,
s.last_active_child_address,
s.remote,
s.object_status,
s.literal_hash_value,
s.last_load_time,
s.is_obsolete,--游标是否被废除（y或n）。当子游标数太多了时可能会发生
s.child_latch,--包含此游标的子latch数
s.sql_profile,
s.program_id,
s.program_line#,
s.exact_matching_signature,
s.force_matching_signature,
s.last_active_time,
s.bind_data
FROM v$sqlarea s;
查看当前会话所执行的语句以及会话相关信息：
select a.sid || '.' || a.SERIAL#,
a.username,
a.TERMINAL,
a.program,
s.sql_text
from v$session a, v$sqlarea s
where a.sql_address = s.address(+)
and a.sql_hash_value = s.hash_value(+)
order by a.username, a.sid;
1.5 v$sql_plan:视图V$SQL_PLAN包含了library cache中所有游标的执行计划。
SELECT p.address,--当前cursor父句柄位置
p.hash_value,--在library cache中父语句的hash值
p.operation,--在各步骤执行内部操作的名称，例如：table access
p.options,--描述列operation在操作上的变种，例如：full
p.object_node,--用于访问对象的数据库链接database link 的名称对于使用并行执行的本地查询该列能够描述操作中输出的次序
p.object#,--表或索引对象数量
p.object_owner,--对于包含有表或索引的架构schema 给出其所有者的名称
p.object_name,--表或索引名
p.optimizer,--执行计划中首列的默认优化模式
p.id,--在执行计划中分派到每一步的序号
p.parent_id,--对id 步骤的输出进行操作的下一个执行步骤的id
p.depth,--业务树深度(或级)。
p.cost,--cost-based方式优化的操作开销的评估，如果语句使用rule-based方式，本列将为空
p.cardinality,--根据cost-based方式操作所访问的行数的评估
p.bytes,--根据cost-based方式操作产生的字节的评估
p.other_tag,--其它列的内容说明
p.partition_start,--范围存取分区中的开始分区
p.partition_stop,--范围存取分区中的停止分区
p.partition_id,--计算partition_start和partition_stop这对列值的步数
p.other,--其它信息即执行步骤细节，供用户参考
p.distribution,--为了并行查询，存储用于从生产服务器到消费服务器分配列的方法
p.cpu_cost,--根据cost-based方式cpu操作开销的评估。如果语句使用rule-based方式，本列为空
p.io_cost,--根据cost-based方式i/o操作开销的评估。如果语句使用rule-based方式，本列为空
p.temp_space,--ost-based方式操作(sort or hash-join)的临时空间占用评估。如果语句使用rule-based方式，本列为空
p.access_predicates,--指明以便在存取结构中定位列，例如，在范围索引查询中的开始或者结束位置
p.filter_predicates,--在生成数据之前即指明过滤列
FROM v$sql_plan p;
通过结合v$sqlarea可以查出library cache中所有语句的查询计划。先从v$sqlarea中得到语句的地址，然后在由v$sql_plan查出它的查询计划：
SELECT LPAD(' ', 2 * (level - 1)) || operation "Operation",
options "Options",
DECODE(to_char(id),
'0',
'Cost=' || nvl(to_char(position), 'n/a'),
object_name) "Object Name",
optimizer
FROM v$sql_plan a
START WITH address = '4F6E452C'
AND id = 0
CONNECT BY PRIOR id = a.parent_id
AND PRIOR a.address = a.address
AND PRIOR a.hash_value = a.hash_value;
2、查看共享池大小
--查看共享池各参数
SELECT name,(bytes)/1024/1024 a FROM v$sgastat WHERE pool='shared pool' ORDER BY a DESC;
--查看Shared Pool Size大小
select name,bytes/1024/1024 from v$sgainfo WHERE name='Shared Pool Size';
注：区分共享池与Shared Pool Size（Shared Pool Size只是共享池的一大部分）
3、修改共享池的大小：
ALTER SYSTEM SET SHARED_POOL_SIZE = 320M;
4、共享池包含的组件
库高速缓存；数据字典高速缓存；用于保存共享服务器连接用户全局区（UGA），只在共享服务器配置下有。
4.1 库高速缓存
存储SQL语句或PL/SQL块
4.1.1 相关视图
4.1.1.1 v$librarycache视图
这个视图包含了关于library cache的性能统计信息，对于共享池的性能调优很有帮助。
SELECT l.namespace,-- library cache的命名空间
l.gets,--请求GET该命名空间中对象的次数
l.gethits,--请求GET并在内存中找到了对象句柄的次数（锁定命中）
l.gethitratio,--请求GET的命中率
l.pins,--读取或执行该命名中对象的次数
l.pinhits,--库对象的所有元数据在内存中被找到的次数（pin命中）
l.pinhitratio,--Pin命中率
l.reloads,--Pin请求需要从磁盘中载入对象的次数
l.invalidations,--命名空间中的非法对象（由于依赖的对象被修改所导致）数
l.dlm_lock_requests,--GET请求导致的实例锁的数量
l.dlm_pin_requests,--PIN请求导致的实例锁的数量
l.dlm_pin_releases,--请求释放PIN锁的次数
l.dlm_invalidation_requests,--GET请求非法实例锁的次数
l.dlm_invalidations--从其他实例那的得到的非法pin数
FROM v$librarycache l;
4.1.1.2 v$library_cache_memory视图
select a.lc_namespace,-- Library cache命名空间
a.lc_inuse_memory_objects,--存在与库高速缓存的对象数目
a.lc_inuse_memory_size,--存在库高速缓存对象大小（M）
a.lc_freeable_memory_objects,--空闲的库高速缓存数量
a.lc_freeable_memory_size --空闲的库高速缓存大小
from v$library_cache_memory a;
通过此视图可了解目前在库高速缓存中的对象及可继续存放的数目。
4.1.2 查看库缓存的命中率
select sum(pinhits)/sum(pins) from v$librarycache;
select(sum(pins-reloads))/sum(pins) "Library cache" from v$librarycache;--考虑了reloads
当命中率小于99%或未命中率大于1%时，说明系统中硬解析过多，要做系统优化（增加Shared Pool、使用绑定变量、修改cursor_sharing等措施。
注：
I）不能单看库高速缓存命中率的大小，结合v$librarycache中的reloads来分析。如果reloads值比较大，表明许多sql语句在老化退出后又被
重新装入库池。若sql语句是因为没有使用绑定变量导致reloads值变大，可修改该sql采用绑定变量的方式；若sql语句无法使用绑定变量，
则可考虑将sql语句用dbms_shared_pool中的keep过程将需要钉在库池中的对象钉住，用unkeep过程释放。
sys.dbms_shared_pool.keep(name => ,flag => )--Name是需要固定的对象的名称，flag是要固定的对象的类型
II）dbms_shared_pool说明：
1）默认下该包没安装，可利用$ORACLE_HOME/rdbms/admin目录下的dbmspool.sql脚本来安装（sys用户执行），其他用户需要sys用户授权后
才可使用。
2）对于固定在共享池中的对象，当共享池空间不足的时候，ORACLE不会释放这些对象以获取创建新的项目所需要的空间，甚至刷新共享池的时候，
这些对象也不会被清除。
3）dbms_shared_pool包的keep和unkeep过程中的flag的取值：
Q sequence
R trigger
T type
JS java source
JC java class
JR java resource
JD java shared data
C CURSOR
固定SQL的keep示例：dbms_shared_pool.keep('address,hash_value','C')，其中SQL语句的ADDRESS和HASH_VALUE可以在V$SQLAREA中找到；
对于函数、过程和包示例如下：dbms_shared_pool.keep('name','P')。
注：如果采用该过程将程序固定到共享池后，刷新缓冲区（alter system flush shared_pool）也不会清除，必须使用unkeep过程清除。
4.1.3 调优库高速缓存
优化库高速缓存的目的是重用以前分析过的或执行过的代码。最简单的方法就是使用绑定变量，减少硬分析。
4.1.3.1 游标共享cursor_sharing参数的使用，使之使用绑定变量
cursor_sharing参数有三个值：
SIMILAR：只在认为绑定变量不会对优化产生负面影响时才使用绑定变量。
FORCE：强制在所有情况下使用绑定变量。
EXACT：默认情况下为该值
ORACLE建议使用CURSOR_SHARING=SIMILAR，因为使用CURSOR_SHARING=FORCE有可能使执行计划变坏。但实际上CURSOR_SHARING=FORCE
对执行计划的好处要远远大于坏处。在观察到由于不使用绑定变量而导致大量硬分析时，通过把默认的CURSOR_SHARING=EXACT改成CURSOR_SHARING=FORCE
可极大的改善性能。可在init.ora或spfile中更改这个参数，也可使用alter system 或alter session 动态的执行更改。
4.1.3.2 硬分析语句的查询与改进
查看硬分析语句
select s.sid, s.value "execute counts", t.value "hard parse"
from v$sesstat s, v$sesstat t
where s.sid = t.sid
and s.statistic# in
(select statistic# from v$statname where name = 'execute count')
and t.statistic# in
(select statistic# from v$statname where name = 'parse count (hard)')
order by t.value desc;
将硬分析语句采用绑定变量方式或者直接将该sql固定到缓存中。
4.1.3.3 减少软分析，降低库高速缓存闩锁争用
通过以下措施可将软分析保持为最低：
1）设置 SESSION_CACHED_CURSORS
SESSION_CACHED_CURSORS,就是说的是一个session可以缓存多少个cursor，让后续相同的SQL语句不再打开游标,从而避免软解析的过程来提高性能。
(绑定变量是解决硬解析的问题)，软解析同硬解析一样,比较消耗资源.所以这个参数非常重要。
当一个cursor关闭之后，oracle会检查这个cursor的request次数是否超过3次，如果超过了三次，就会放入session cursor cache list的MRU端，
这样在下次打算parse一个sql时,它会先去pga内搜索session cursor cache list,如果找到那么会把这个cursor脱离list,然后当关闭的时候再把这个
cursor加到MRU端. session_cached_cursor提供了快速软分析的功能,提供了比soft parse更高的性能。session cursor cache的管理也是使用LRU。
session_cached_cursors这个参数是控制session cursor cache的大小的。session_cached_cursors定义了session cursor cache中存储的
cursor的个数。这个值越大，则会消耗的内存越多。
另外检查这个参数是否设置的合理，可以从两个statistic来检查。
SQL> select name,value from v$sysstat where name like '%cursor%';
NAME VALUE
---------------------------------------------------------------- ----------
opened cursors cumulative 17889
opened cursors current 34
session cursor cache hits 16481
session cursor cache count 777
cursor authentications 294
SQL>select name,value from v$sysstat where name like '%parse%';
NAME VALUE
---------------------------------------------------------------- ----------
parse time cpu 331
parse time elapsed 2021
parse count (total) 12134
parse count (hard) 1355
parse count (failures) 3
session cursor cache hits 和parse count（total） 就是总的parse次数中，在session cursor cache中找到的次数，所占比例越高，性能越好。
如果比例比较低，并且有剩余内存的话，可以考虑加大该参数。
Oracle 9i及以前,该参数缺省是0,10G上缺省是20。
open_cursors 是充许打开的游标的数量
session_cached_cursors 是充许放入缓存的游标的数量
2）在应用程序预编译器中设置 HOLD_CURSOR
HOLD_CURSOR=YES|NO;缺省值为NO。
当执行SQL操纵语句时，其相关的光标被连到光标高速缓冲存储器中的一项上，该项又被依次连接到ORACLE专用的SQL区域上，该区域存储处理该语句
所需的信息。
当HOLD_CURSOR=NO时，在ORACLE执行完SQL语句或关闭光标后，预编译程序直接撤去该链，释放分析块和分配给专用SQL区域的内存，并把该链标为可再
使用。这时另一个SQL语句就又可使用该链来指向光标高速缓冲存储器的项了。
当HOLD_CURSOR=YES时，该链被保留，预编译程序不再使用它。这对经常使用的SQL语句是有用的。
如果RELEASE_CURSOR=no（默认 no），HOLD_CURSOR=yes（默认为no），当ORACLE执行完SQL语句，为private SQL AREA分配的内存空间被保留，
cursor和private SQL AREA之间的link也被保留，预编译程序不再使用它，同样可以通过这个指针直接在private SQL AREA获得语句。
注意：RELEASE_CURSOR=YES优先于HOLD_CURSOR=YES；HOLD_CURSOR=NO优先于RELEASE_CURSOR=NO。
3）设置 CURSOR_SPACE_FOR_TIME 默认为false 废弃
该参数本意是通过设置为true可以保证游标在关闭前不能重新分配游标。
但是注意，该参数已废弃。
4.1.3.4 修改share_pool大小
查看库缓存命中率大小，若大小，可试着加大share_pool。
4.2 数据字典缓冲区
--查看数据字典缓冲区的使用率（应该在90％以上，否则需要增加共享池的大小）
select (sum(gets-getmisses-usage-fixed))/sum(gets) "Data dictionary cache" from v$rowcache;
二、数据缓冲区
show parameter db_cache_size
--修改一些DB_CACHE相关参数
alter system set db_cache_size=100m; --默认池（所有段块一般都在这个池）
alter system set db_keep_cache_size=12m;--保持池（访问非常频繁的段可放置该池，防止在默认池老化）
alter system set db_recycle_cace_size=16m;--回收池（访问很随机的大段一般可放于该池）
--查看db_cache命中率
select name, value
from v$sysstat
where name in ('db block gets from cache', 'consistent gets from cache',
'physical reads cache');
db_cache命中率算法
db_cache命中率=1-(physical reads cache/(db block gets from cache+consistent gets from cache)) --命中率应该在90％以上，否则需要增加数据缓冲区的大小
--采用v$buffer_pool_statistics视图推导缓冲区高速缓存的命中率
SELECT name,
physical_reads,
db_block_gets,
consistent_gets,
1 - (physical_reads / (db_block_gets + consistent_gets)) Hitratio
FROM v$buffer_pool_statistics;
--v$db_cache_advice视图用于建议缓冲区高速缓存设置
SELECT size_for_estimate "size",
buffers_for_estimate "buffers",
estd_physical_read_factor "read_factor",
estd_physical_reads "reads"
FROM v$db_cache_advice
WHERE NAME = 'DEFAULT'
AND block_size =
(SELECT VALUE FROM v$parameter WHERE NAME = 'db_block_size');
注：对于常用的小表可以将其保存在keep池，这样就不会因为缓冲区满而被清出。
alter table table_name storage(buffer_pool keep) 。
三、重做日志缓冲区
Redo Log Buffer是SGA中一段保存数据库修改信息的缓存。这些信息被存储在重做条目(Redo Entry)中.重做条目中包含了由于INSERT、UPDATE、
DELETE、CREATE、ALTER或DROP所做的修改操作而需要对数据库重新组织或重做的必须信息。在必要时，重做条目还可以用于数据库恢复。
重做条目是Oracle数据库进程从用户内存中拷贝到Redo Log Buffer中去的。重做条目在内存中是连续相连的。后台进程LGWR负责将Redo Log Buffer中
的信息写入到磁盘上活动的重做日志文件（Redo Log File）或文件组中去的。
参数LOG_BUFFER决定了Redo Log Buffer的大小。它的默认值是512K（一般这个大小都是足够的），最大可以到4G。当系统中存在很多的大事务或者
事务数量非常多时，可能会导致日志文件IO增加，降低性能。这时就可以考虑增加LOG_BUFFER。
但是，Redo Log Buffer的实际大小并不是LOB_BUFFER的设定大小。为了保护Redo Log Buffer，oracle为它增加了保护页（一般为11K）：
SQL> show parameter log_buffer
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_buffer integer 7024640
SQL> select * from v$sgastat where name = 'log_buffer';
POOL NAME BYTES
------------ -------------------------- ----------
log_buffer 7135232
调整操作
alter system set log_buffer=3500000 scope=spfile;
四、大池（用于减轻共享池的负担，当有大规模的I/O操作或者备份恢复操作，或者是共享服务器进程）
其主要大小由参数large_pool_size决定
show parameter large_pool_size;
大池是SGA中的一块可选内存池，根据需要时配置。在以下情况下需要配置大池：
用于共享服务（Shared Server MTS方式中）的会话内存和Oracle分布式事务处理的Oracle XA接口
使用并行查询（Parallel Query Option PQO）时
IO服务进程
Oracle备份和恢复操作（启用了RMAN时）
通过从大池中分配会话内存给共享服务、Oracle XA或并行查询，oracle可以使用共享池主要来缓存共享SQL，以防止由于共享SQL缓存收缩导致的性能
消耗。此外，为Oracle备份和恢复操作、IO服务进程和并行查询分配的内存一般都是几百K，这么大的内存段从大池比从共享池更容易分配得到。
参数LARGE_POOL_SIZE设置大池的大小(alter system set large_pool_size=10M)。大池是属于SGA的可变区（Variable Area）的，它不属于共享池。
对于大池的访问，是受到 large memory latch 保护的。大池中只有两种内存段：空闲（free）和可空闲（freeable）内存段。它没有可重建
（recreatable）内存段，因此也不用LRU链表来管理（这和其他内存区的管理不同）。大池最大大小为4G。
为了防止大池中产生碎片，隐含参数 _LARGE_POOL_MIN_ALLOC 设置了大池中内存段的最小大小，默认值是16K（同样，不建议修改隐含参数）。
此外，large pool是没有LRU链表的。
五、JAVA池（使用java语言，java命令分析时需要使用）
其主要大小由参数java_pool_size决定
show parameter java_pool_size;
Java池也是SGA中的一块可选内存区，它也属于SGA中的可变区。
Java池的内存是用于存储所有会话中特定Java代码和JVM中数据。Java池的使用方式依赖与Oracle服务的运行模式。
Java池的大小由参数JAVA_POOL_SIZE设置(alter system set java_pool_size=10M;)。Java Pool最大可到1G。
在Oracle 10g以后，提供了一个新的建议器——Java池建议器——来辅助DBA调整Java池大小。建议器的统计数据可以通过视图
V$JAVA_POOL_ADVICE来查询。
六、流池
流池是Oracle 10g中新增加的。是为了增加对流（流复制是Oracle 9iR2中引入的一个非常吸引人的特性，支持异构数据库之间的复制。10g中得到了
完善）的支持。
流池也是可选内存区，属于SGA中的可变区。它的大小可以通过参数 STREAMS_POOL_SIZE 来指定。如果没有被指定，oracle会在第一次使用流时自动创
建。如果设置了SGA_TARGET参数，Oracle会从SGA中分配内存给流池；如果没有指定SGA_TARGET，则从buffer cache中转换一部分内存过来给流池。转换
的大小是共享池大小的10%。
Oracle同样为流池提供了一个建议器——流池建议器。建议器的统计数据可以通过视图V$STREAMS_POOL_ADVICE查询。