1. 深入了解 Oracle 自动内
存管理 ASMM
by Maclean.liu
liu.maclean@gmail.com
www.oracledatabase12g.com

2. About Me
l Email:liu.maclean@gmail.com
l Blog:www.oracledatabase12g.com
l Oracle Certified Database Administrator Master 10g
and 11g
l Over 6 years experience with Oracle DBA technology
l Over 7 years experience with Linux technology
l Member Independent Oracle Users Group
l Member All China Users Group
l Presents for advanced Oracle topics: RAC,
DataGuard, Performance Tuning and Oracle Internal.

3. 每一个 Oracle 的初学者在入门阶段都会接触到 SGA/PGA 的知识，如果是从 10g 开始学习那么会多或少会对
ASMM 有所了解，从使用的角度来说 ASMM 的出现极大地简化了 Oracle 内存初始化参数的设置，在 ASMM 的使
用上高级 DBA 和初学者不会有太大的差别；很多人因此而认为 ASMM 极大程度地减少了数据库对于专业 DBA 的
依赖：如果我们有一个足够智能的 DB，那么为什么还要花费金钱雇佣 DBA 呢？这似乎是时下一种十分流行的想
法。当然这种想法我个人是不能苟同的，ASMM 一定程度上带来了便利，更大程度上它是一个黑盒，黑盒里面藏
了很多秘密，这些秘密带来比手动管理更多的不确定性；在 10g release 1 和 10.2 的早期版本中 ASMM 扮演的角
色有点像一个闯祸精，另一个让用户对 ASMM 很不待见的原因是 ASMM 直接拖慢了 startup 的速度。一个个人观
点是 ASMM 也好 AMM 也罢，都要求产品数据库 DBA 掌握更多 SGA/PGA 相关的知识才能成功”驾驭”这些”有智
力”的家伙，有点夸张的说这个时候的 DBA 很像一个 chemist(需要和一大堆以 1 个或 2 个下划线开头的奇怪参数
打交道)。
为了不辱使命我们真的有必要了解一下 ASMM 的基本知识，显然这并不是一件容易的事情……
Oracle 的 SGA 基本内存组件从 9i 开始并没有非常大的变化，他们包括:
• Buffer Cache 我们常说的数据库高速缓存，虽然我一直不明白要冠以高速之名
• Default Pool 默认的缓冲池，大小由 DB_CACHE_SIZE 决定
• Keep Pool 持久的缓冲池，大小由 DB_KEEP_CACHE_SIZE 决定
• Non standard pool 非标准块标准池，大小由 DB_nK_cache_size 决定
• Recycle pool 回收池，大小由 db_recycle_cache_size 决定
• Shared Pool 共享池，大小由 shared_pool_size 决定
• Library cache 俗称的库缓存
• Row cache 行缓存，也叫字典缓存
• Java Pool java 池，大小由 Java_pool_size 决定
• Large Pool 大池，大小由 Large_pool_size 决定
• Fixed SGA 固定的 SGA 区域，包含了 Oracle 内部的数据结构，一般被存放在第一个 granule 中
在 9i 中尚未引入 ASMM，唯一的选择是手动管理的 SGA，有时候也叫做 MSMM。在 9i 中除去 buffer cache 的大
小可以手动修改外，其余组件都无法动态修改。因为缺乏一种动态管理的机制，所以在 9i 中如果有某个内存区域
有急用，也无法从其他有空闲内存的组件中捐献一些来解燃眉之急。
手动管理 SGA 的缺点在于:
• 个别组件如 shared pool、default buffer pool 的大小存在最优值，但组件之间无法交换内存
• 在 9i 中就提供了多种内存建议(advisor)，但都要求人工手动干预
• 无法适应工作负载存在变化的环境

4. • 往往会导致内存浪费，没有用到实处
• 若设置不当，引发著名的 ORA-04031 错误的可能性大大提高
ASMM 的优势在于:
• 全自动的共享内存管理
• 无需再配置每一个内存组件大小参数
• 仅使用一个参数 sga_target 驱动
• 有效利用所有可用的内存，极大程度上减少内存浪费
• 对比 MSMM 其内存管理模式:
• 更加动态
• 更加灵活
• 并具备适应性
• 易于使用
• 一定程度上增强了性能，因为内存分配更为合理了
• 当某个组件急需更多内存时可以有效提供，因此可以一定程度避免 ORA-04031 的发生
ASMM 主要可以囊括为三个部分：
1.由一个新参数 sga_target 驱动的管理模式
2.内存交换的模型，包括了：内存组件(memory component)，内存代理(memory broker)和内存交换机制
(memory mechanism)
3.内存建议(memory advisor)
ASMM 下一部分参数是自动设置的(Automatically set)，这些参数包
括:shared_pool_size、db_cache_size、java_pool_size、large_pool _size 和 streams_pool_size；而另外一些
是需要手动设置的静态参数，包括
了:db_keep_cache_size、db_recycle_cache_size、db_nk_cache_size、log_buffer 以及固定 SGA 内存结构
等，如果以上没有手动设置这些参数的话，除去 log_buffer 和 fixed sga 其他内存组件一般默认大小为零。
通过 ASMM 用户仅需要设置一个 sga_target 参数，其他参数都将由 ASMM 自行内部控制。但如果用户依旧设置
了如 db_cache_size、java_pool_size 等参数，那么这些参数被认为是相关内存组件的最小限制，同时每个内存
组件的大小也存在一个最大上限(内部的)。在实例启动阶段，Oracle 会将必要的内存颗粒(granule，当 SGA<1GB
时 granule 大小为 4M，当 SGA>1GB 时 granule 大小为 16M)分配给内存组件，多余没有分配出去的全都分配给
buffer cache，之后随着系统的不断活跃更多的内存颗粒(granule)将被分配给急需内存的组件。我们可以动态地

5. 修改 sga_target 参数，前提是所在的系统平台支持动态地共享内存(dism，主流平台都支持)。使用 ASMM 的一个
必要条件是初始化参数 statistics_level 必须设置为 typical 或 ALL，如果设置为 BASIC 那么 MMON 后台进程
(Memory Monitor is a background process that gathers memory statistics (snapshots) stores this information in
the AWR (automatic workload repository). MMON is also responsible for issuing alerts for metrics that exceed
their thresholds)将无法有效分析内存的使用的统计信息从而驱动 ASMM 的自动调优，实际上我们不能同时设置
sga_target 为非零值和 statistics_level 为 BASIC:
SQL> show parameter sga
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
lock_sga boolean FALSE
pre_page_sga boolean FALSE
sga_max_size big integer 2000M
sga_target big integer 2000M
SQL> show parameter sga_target
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
sga_target big integer 2000M
SQL> alter system set statistics_level=BASIC;
alter system set statistics_level=BASIC
*
ERROR at line 1:
ORA-02097: parameter cannot be modified because specified value is invalid
ORA-00830: cannot set statistics_level to BASIC with auto-tune SGA enabled
如果使用了 server parameter file 即 spfile 的话，ASMM 会在实例 shutdown 之前将当前实际的内存组件大小
(Oracle 认为这是最优的，但实际上可能不是)保存到 spfile 中，如果你使用 strings 命令打印过 spfile 的内容的可
以发现一些以双下划线开头的参数，如:
G10R2.__db_cache_size=973078528
G10R2.__java_pool_size=16777216
G10R2.__large_pool_size=16777216
G10R2.__shared_pool_size=1006632960
G10R2.__streams_pool_size=67108864
这些在 spfile 保存的组件大小会在下次启动时被沿用，以达到将已经实践得出的”最佳值”记住的目的，这样下次就
不用从头再”学习”了。

6. 在 ASMM 的内存交换模型中存在三类组件
1. 可调优组件(tunable):可调优组件是那些大小可以随之变化且若过小仅损害少量性能。buffer cache 就
是一个经典的例子，cache 过小的情况下应用程序仍能正常运行，但带来的代价是更多的 IO。注意可调
优组件同时存在一个下限。举例来说共享池由库缓存 Library cache 和其他一些 subheap 子堆组成，
那么共享池就存在一个下限要保证至少能放下某个一个时刻并行打开的游标(open cursors)以及负担其
他共享池 client 的运行时内存分配需求。类似的 buffer cache 也存在一个下限，该下限至少要大于并行
被 pin 住的 buffer 的总和(虽然这部分很小)
2. 不可调组件(Un-tunable):不可调组件是那些存在最小下限的内存组件，这个最小下限足够让应用程序
正常运行，超过这个上限并不会带来额外的性能收益。在这类组件中 large pool 是一个典型。
3. 固定大小组件(Fixed Size)：自动调优框架之外的组件，一般为固定大小。这些组件的大小仅在手动调
整时改变。例如非标准块大小的高速缓冲池
内存交换模型中内存大小调整的申请(memory resize request)存在三种不同的模式，它们分别是：
立即内存申请(Immediate Request)：这种申请模式一般出现在 ASMM 管理的某个自动调优组件在无法分配到连
续可用内存块(chunk)时，为了避免出现 OUT-OF-MEMORY(ORA-04031)的错误，系统尝试从其他候选组件中转
移一个内存颗粒(granule)过来。需要注意的是当前可能没有可用的全空 granule，这时就会出现不完整的转移，
在此情形下系统会开始从候选组件中清理内存颗粒以满足内存申请，并将一个 granule 不完整地转移给急需内存
的组件。
延迟内存申请(Deferred Request)：这种申请一般出现在系统认为存在一种更为合理的内存分配时，考虑在组件
之间转移一个或多个 granule。用以判定最佳内存分配的依据是 MMON 进程所提供的统计信息 delta.
手动内存申请(Manual Request)：这种申请仅发生在用户使用 alter system 命令手动调整内存组件的大小时。在
这种模式下仅允许使用空的内存颗粒参与大小调整。如果当时没有足够的空 granule，那么针对组件 grow 操作会
返回 ORA-4033 错误，而针对组件 shrink 操作会返回 ORA-4034 错误。

7. 当 ASMM 被启用后，内存代理(Memory Broker)定期执行上图所示的活动。以上操作都处于延迟内存申请模式下
(Deferred)。其目的是通过自动化的作业来调优自动调优组件(auto-tunable component)的大小以适应不断改变的
工作负载，将内存分配到最需要它们的地方。MMON 辅助进程会在后台不断将统计信息和内存建议定期地捕获到
循环使用的内存中，并计算不同时期缓存信息之间的差值；MMON 还会基于 Memory Broker 的策略分析这些差
值并估算出长期和短期内的趋势。最后 MMON 基于以上分析生成一些内存组件的大小调整决议并将相应的申请
发送到一个系统申请队列中(resize request system queue)。MMAN 后台进程(Memory Manager is a background
process that manages the dynamic resizing of SGA memory areas as the workload increases or decreases)会
定期扫描系统申请队列并执行内存转移。
在 10gR1 中 Shared Pool 的 shrink 收缩操作存在一些缺陷，造成缺陷的原因是在该版本中 Buffer Cache 还没有
能力共享使用一个 granule，这是因为 Buffer Cache 的 granule 的尾部由 granule header 和 Metadata(可能是
buffer header 或者 RAC 中的 Lock Elements)拼接组成，在其尾部不容许存在空洞。另一个原因是当时的 shared
pool 允许不同生命周期 duration(以后会介绍)的 chunk 存放在同一个 granule 中，这造成共享池无法完全释放
granule。到 10gR2 中通过对 Buffer Cache Granule 结构的修改允许在 granule header 和 buffer 及
Metadata(buffer header 或 LE)存在缝隙，同时 shared pool 中不同 duration 的 chunk 将不在共享同一个
granule，通过以上改进 buffer cache 与 shared pool 间的内存交换变得可行。此外在 10gr2 中 streams pool 也开
始支持内存交换(实际根据不同的 streams pool duration 存在限制)

8. 当某个组件扮演捐献者(Donor，下面的 trace 中会看到)角色时，它可能将一个不完整 granule 转移给 buffer
cache，那么在该 granule 被使用前需要完成以下步骤:
1. 首先在该 granule 的尾部生成新的 granule header
2. 针对剩下的 chunk 判定在该 granule 中是否还有未使用的 buffer header
3. 如果有，那么将 chunk 中的内存转换为一个数据块。否则将之转换为一个 metadata 块
4. 重复以 2-4 步骤，直到该 granule 被转换完
接着我们来了解一下内存转移的基本原理，当将 buffer cache 中的 granule 转移给 shared pool 时，将按照以下步
骤:
1. MMAN 后台进程找到一块属于 buffer cache 的合适 granule
2. MMAN 将看中的 granule 置入 quiesce 列表中(Moving 1 granule from inuse to quiesce list of
DEFAULT buffer cache for an immediate req)
3. DBWR 将负责写出置入 quiesced 列表中 granule 里面的脏 buffer(dirty buffer)
4. MMAN 将为 shared pool 调用消费回调函数(consume callback)，granule 中 free 的 chunk 都会被
shared pool 消费(consume)掉，并对共享池新的内存分配可用。从这里开始该 granule 变成一个
shared granule 共享内存颗粒，注意不要认为这个时候该 granule 的空间全部属于共享池了，实际上
有部分 pin 住的 buffer 及其 Metadata(上述的 buffer header 和 LE)的空间仍被 buffer cache 占用着
5. 最终该 granule 将完整的转移给 shared pool，这时此 granule 不再是一个 shared 共享的
实际使用中 ASMM 受到众多隐藏参数的影响，其中比较主要的参数有:
1. _enabled_shared_pool_duration:该参数控制是否启用 10g 中特有的 shared pool duration 特性，
当我们设置 sga_target 为 0 时该参数为 false；同时在 10.2.0.5 前若 cursor_space_for_time 设置
为 true 时该参数也为 false，不过在 10.2.0.5 以后 cursor_space_for_time 参数被废弃
2. _memory_broker_shrink_heaps:若该参数设置为 0 那么 Oracle 不会去收缩 shared pool 或 java
pool，当该参数大于 0，会在 shrink request 失败后等待该参数指定秒数时间后再次申请

9. 3. _memory_management_tracing: 该参数控制针对 MMON 和 MMAN 后台进程包括内存建议
(advisor)和内存代理(Memory Broker)决议的相关 trace 的级别；针对 ORA-04031 的诊断可以设置
为 36，设置为 8 启用针对启动期间组件大小的 trace，设置为 23 启动针对 Memory Broker decision
的跟踪，设置为 32 将转储 cache resize 的细节；该参数的具体级别如下:
Level Contents
0×01 Enables statistics tracing
0×02 Enables policy tracing
Enables transfer of granules
0×04
tracing
0×08 Enables startup tracing
0×10 Enables tuning tracing
0×20 Enables cache tracing
接下来我们通过设置_memory_management_tracing 隐藏参数和 DUMP_TRANSFER_OPS 转储来实地了解一次
完整的内存转移，和不完整的内存转移。以下演示的完整 trace 文件可以从这里下载
mman_trace、transfer_ops_dump。
SQL> alter system set "_memory_management_tracing"=63;
System altered
Operation make shared pool grow and buffer cache shrink!!!..............
以下为一个完整 granule 转移的过程，包括了对 default buffer pool 的 resize 操作:
AUTO SGA: Request 0xdc9c2628 after pre-processing, ret=0
/* 这里的 0xdc9c2628 是前台进程的 addr */
AUTO SGA: IMMEDIATE, FG request 0xdc9c2628
/* 这里可以看到前台进程的 Immediate 立即申请 */
AUTO SGA: Receiver of memory is shared pool, size=16, state=3, flg=0
/* 此次申请的收益人是 shared pool，共享池，其大小为 16 个 granule，处于 grow 状态 */

10. AUTO SGA: Donor of memory is DEFAULT buffer cache, size=106, state=4, flg=0
/* 此处的捐献者是 Default buffer cache，高速缓存，其大小为 106 个 granule，处于 shrink 状态 */
AUTO SGA: Memory requested=3896, remaining=3896
/* 这里 immeidate request 所要求的空间是 3896 bytes */
AUTO SGA: Memory received=0, minreq=3896, gransz=16777216
/* 这里没有 free 的 granule，所以 received 为 0，gransz 为 granule 的大小 */
AUTO SGA: Request 0xdc9c2628 status is INACTIVE
/* 因为没有空的内存颗粒，先将申请置于 inactive 状态 */
AUTO SGA: Init bef rsz for request 0xdc9c2628
/* 为相关申请初始化 before-process 大小调整 */
AUTO SGA: Set rq dc9c2628 status to PENDING
/* 将 request 置于 pending 状态 */
AUTO SGA: 0xca000000 rem=3896, rcvd=16777216, 105, 16777216, 17
/* 返回起始地址为 0xca000000 的 16M 大小 granule */
AUTO SGA: Returning 4 from kmgs_process for request dc9c2628
AUTO SGA: Process req dc9c2628 ret 4, 1, a
AUTO SGA: Resize done for pool DEFAULT, 8192
/* 完成对 default pool 的 resize */
AUTO SGA: Init aft rsz for request 0xdc9c2628
AUTO SGA: Request 0xdc9c2628 after processing
AUTO SGA: IMMEDIATE, FG request 0x7fff917964a0
AUTO SGA: Receiver of memory is shared pool, size=17, state=0, flg=0
AUTO SGA: Donor of memory is DEFAULT buffer cache, size=105, state=0, flg=0
AUTO SGA: Memory requested=3896, remaining=0
AUTO SGA: Memory received=16777216, minreq=3896, gransz=16777216

11. AUTO SGA: Request 0x7fff917964a0 status is COMPLETE
/* shared pool 成功收到 16M 的 granule */
AUTO SGA: activated granule 0xca000000 of shared pool
以下为一个 partial granule 不完全内存颗粒的转移过程 trace:
AUTO SGA: Request 0xdc9c2628 after pre-processing, ret=0
AUTO SGA: IMMEDIATE, FG request 0xdc9c2628
AUTO SGA: Receiver of memory is shared pool, size=82, state=3, flg=1
AUTO SGA: Donor of memory is DEFAULT buffer cache, size=36, state=4, flg=1
/* 此处的受益者仍为 shared pool，而捐献者是 default buffer cache */
AUTO SGA: Memory requested=4120, remaining=4120
AUTO SGA: Memory received=0, minreq=4120, gransz=16777216
AUTO SGA: Request 0xdc9c2628 status is INACTIVE
AUTO SGA: Init bef rsz for request 0xdc9c2628
AUTO SGA: Set rq dc9c2628 status to PENDING
AUTO SGA: Moving granule 0x93000000 of DEFAULT buffer cache to activate list
AUTO SGA: Moving 1 granule 0x8c000000 from inuse to quiesce list of DEFAULT buffer cache
for an immediate req
/* 以上将 buffer cache 中起始地址为 0x8c000000 的 granule 从使用中列表 inuse list，
移动到静默列表 quiesce list 中 */
AUTO SGA: Returning 0 from kmgs_process for request dc9c2628
AUTO SGA: Process req dc9c2628 ret 0, 1, 20a
AUTO SGA: activated granule 0x93000000 of DEFAULT buffer cache
AUTO SGA: NOT_FREE for imm req for gran 0x8c000000
/ * 等待 dbwr 写出 0x8c000000 granule 中所有的 dirty buffer */
AUTO SGA: Returning 0 from kmgs_process for request dc9c2628
AUTO SGA: Process req dc9c2628 ret 0, 1, 20a
AUTO SGA: NOT_FREE for imm req for gran 0x8c000000
AUTO SGA: Returning 0 from kmgs_process for request dc9c2628
AUTO SGA: Process req dc9c2628 ret 0, 1, 20a
AUTO SGA: NOT_FREE for imm req for gran 0x8c000000
AUTO SGA: Returning 0 from kmgs_process for request dc9c2628

12. AUTO SGA: Process req dc9c2628 ret 0, 1, 20a
AUTO SGA: NOT_FREE for imm req for gran 0x8c000000
AUTO SGA: Returning 0 from kmgs_process for request dc9c2628
AUTO SGA: Process req dc9c2628 ret 0, 1, 20a
AUTO SGA: NOT_FREE for imm req for gran 0x8c000000
AUTO SGA: Returning 0 from kmgs_process for request dc9c2628
AUTO SGA: Process req dc9c2628 ret 0, 1, 20a
AUTO SGA: NOT_FREE for imm req for gran 0x8c000000
.........................................
AUTO SGA: Rcv shared pool consuming 8192 from 0x8c000000 in granule 0x8c000000; owner is
DEFAULT buffer cache
AUTO SGA: Rcv shared pool consuming 90112 from 0x8c002000 in granule 0x8c000000; owner is
DEFAULT buffer cache
AUTO SGA: Rcv shared pool consuming 24576 from 0x8c01a000 in granule 0x8c000000; owner is
DEFAULT buffer cache
AUTO SGA: Rcv shared pool consuming 65536 from 0x8c022000 in granule 0x8c000000; owner is
DEFAULT buffer cache
AUTO SGA: Rcv shared pool consuming 131072 from 0x8c034000 in granule 0x8c000000; owner
is DEFAULT buffer cache
AUTO SGA: Rcv shared pool consuming 286720 from 0x8c056000 in granule 0x8c000000; owner
is DEFAULT buffer cache
AUTO SGA: Rcv shared pool consuming 98304 from 0x8c09e000 in granule 0x8c000000; owner is
DEFAULT buffer cache
AUTO SGA: Rcv shared pool consuming 106496 from 0x8c0b8000 in granule 0x8c000000; owner
is DEFAULT buffer cache
.....................
/* 以上 shared pool 开始消费 0x8c000000 granule 中的 chunk，
但此 granule 的 owner 暂时仍为 default buffer cache */
AUTO SGA: Imm xfer 0x8c000000 from quiesce list of DEFAULT buffer cache to partial inuse
list of shared pool
/* 以上将 0x8c000000 granule 从 default buffer cache 的静默列表转移到 shared pool 的不完整 inuse
list */
AUTO SGA: Returning 4 from kmgs_process for request dc9c2628
AUTO SGA: Process req dc9c2628 ret 4, 1, 20a
AUTO SGA: Init aft rsz for request 0xdc9c2628
AUTO SGA: Request 0xdc9c2628 after processing
AUTO SGA: IMMEDIATE, FG request 0x7fffe9bcd0e0
AUTO SGA: Receiver of memory is shared pool, size=83, state=0, flg=1
AUTO SGA: Donor of memory is DEFAULT buffer cache, size=35, state=0, flg=1

13. AUTO SGA: Memory requested=4120, remaining=0
AUTO SGA: Memory received=14934016, minreq=4120, gransz=16777216
AUTO SGA: Request 0x7fffe9bcd0e0 status is COMPLETE
/* 以上一个 partial transfer 完成 */
对应于以上 partial transfer 我们可以通过 DUMP_TRANSFER_OPS 来了解该 0x8c000000 partial granule 的实际
使用情况，如:
SQL> oradebug setmypid;
Statement processed.
SQL> oradebug dump DUMP_TRANSFER_OPS 1;
Statement processed.
SQL> oradebug tracefile_name;
/s01/admin/G10R2/udump/g10r2_ora_21482.trc
=======================trace content==============================
GRANULE SIZE is 16777216
COMPONENT NAME : shared pool
Number of granules in partially inuse list (listid 4) is 23
Granule addr is 0x8c000000 Granule owner is DEFAULT buffer cache
/* 该 0x8c000000 granule 在 shared pool 的 partially inuse list，
但这里它的 owner 仍为 default buffer cache */
Granule 0x8c000000 dump from owner perspective
gptr = 0x8c000000, num buf hdrs = 1989, num buffers = 156, ghdr = 0x8cffe000
/ * 可以看到该 granule 的 granule header 地址位于 0x8cffe000，
其中共有 156 个 buffer block,1989 个 buffer header */
/* 以下 granule 中具体的内容，实际既包含了 buffer cache 也有 shared pool chunk */
BH:0x8cf76018 BA:(nil) st:11 flg:20000
BH:0x8cf76128 BA:(nil) st:11 flg:20000
BH:0x8cf76238 BA:(nil) st:11 flg:20000
BH:0x8cf76348 BA:(nil) st:11 flg:20000
BH:0x8cf76458 BA:(nil) st:11 flg:20000
BH:0x8cf76568 BA:(nil) st:11 flg:20000

14. BH:0x8cf76678 BA:(nil) st:11 flg:20000
BH:0x8cf76788 BA:(nil) st:11 flg:20000
BH:0x8cf76898 BA:(nil) st:11 flg:20000
BH:0x8cf769a8 BA:(nil) st:11 flg:20000
BH:0x8cf76ab8 BA:(nil) st:11 flg:20000
BH:0x8cf76bc8 BA:(nil) st:11 flg:20000
BH:0x8cf76cd8 BA:0x8c018000 st:1 flg:622202
...............
Address 0x8cf30000 to 0x8cf74000 not in cache
Address 0x8cf74000 to 0x8d000000 in cache
Granule 0x8c000000 dump from receivers perspective
Dumping layout
Address 0x8c000000 to 0x8c018000 in sga heap(1,3) (idx=1, dur=4)
Address 0x8c018000 to 0x8c01a000 not in this pool
Address 0x8c01a000 to 0x8c020000 in sga heap(1,3) (idx=1, dur=4)
Address 0x8c020000 to 0x8c022000 not in this pool
Address 0x8c022000 to 0x8c032000 in sga heap(1,3) (idx=1, dur=4)
Address 0x8c032000 to 0x8c034000 not in this pool
Address 0x8c034000 to 0x8c054000 in sga heap(1,3) (idx=1, dur=4)
Address 0x8c054000 to 0x8c056000 not in this pool
Address 0x8c056000 to 0x8c09c000 in sga heap(1,3) (idx=1, dur=4)
Address 0x8c09c000 to 0x8c09e000 not in this pool
Address 0x8c09e000 to 0x8c0b6000 in sga heap(1,3) (idx=1, dur=4)
Address 0x8c0b6000 to 0x8c0b8000 not in this pool
Address 0x8c0b8000 to 0x8c0d2000 in sga heap(1,3) (idx=1, dur=4)
以上可以看到该 granule 真的是一个 shared granule 共享内存颗粒，其中不仅包含了部分 buffer block，还包含了
1 号 shared subpool 共享池子池的 durtaion 为 4 的 chunk，duration=4 即 execution duration;这类 duration 的
chunk 一般有着较短的生命周期，当其 extent 被置于 quiesce list 静默列表时将很有可能变得足够
free。execution duration 是共享池中唯一能可靠转移的，因此唯有该类 duration 所在的 extent(一般来说一个
extent 占用一个 granule)可以用来收缩。

15. 以下我们列出一些有助于诊断 ASMM 问题的动态性能视图，仅供参考:
V$SGAINFO
Displays summary information about the system global area (SGA).
V$SGA
Displays size information about the SGA, including the sizes of different SGA components, the granule size,
and free memory.
V$SGASTAT
Displays detailed information about the SGA.
V$SGA_DYNAMIC_COMPONENTS
Displays information about the dynamic SGA components. This view summarizes information based on all
completed SGA resize operations since instance startup.
V$SGA_DYNAMIC_FREE_MEMORY
Displays information about the amount of SGA memory available for future dynamic SGA resize operations.
V$SGA_RESIZE_OPS
Displays information about the last 400 completed SGA resize operations.
V$SGA_CURRENT_RESIZE_OPS
Displays information about SGA resize operations that are currently in progress. A resize operation is an
enlargement or reduction of a dynamic SGA component.
V$SGA_TARGET_ADVICE
Displays information that helps you tune SGA_TARGET.
近期内会写一篇介绍 shared pool duration 的文章，作为对这篇的补充。
© 2011, www.oracledatabase12g.com. 版权所有.文章允许转载,但必须以链接方式注明源地址,否则追求法律责
任.