理解Shared Pool 1

堆管理

shared pool是利用堆内存管理方式管理的（KGH：Kernel Generic Heap）.从Oracle 9i开始，可以有多个最高级堆（TOP-LEVEL HEAP）,最高级堆可以分为多个副堆，副堆下面还拥有下属副堆.堆和副堆的结构基本相同.从物理上来看，一个堆由于多个内存区以LINKED LIST的形式连接组成.一个内存区物理上使用一个GRANULE，一个内存区有多个CHUNK组成，所以CHUNK是HEAP的最小内存单位.CHUNK的使用情况可以通过X$KSMSP内部视图查看每个堆头上则包含了可使用的CHUNK列表和已使用的CHUNK列表.通过DUMP
HEAP命令可以在跟踪文件中观察HEAP和EXTENT的关系

alter session set events ‘immediate trace name heapdump level 2‘；

来看一下dump文件

[email protected]>select * from v$version;

BANNER

--------------------------------------------------------------------------------

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production

PL/SQL Release 11.2.0.1.0 - Production

CORE    11.2.0.1.0      Production

TNS for Linux: Version 11.2.0.1.0 - Production

NLSRTL Version 11.2.0.1.0 - Production

[email protected]>select * from v$sgainfo where name=‘Granule Size‘;

NAME                                  BYTES RES

-------------------------------- ---------- ---

Granule Size                        4194304 No

******************************************************

HEAP DUMP heap name="sga heap(1,0)"  desc=0x2002b1cc

extent sz=0xfc4 alt=124 het=32767 rec=9 flg=-126 opc=0

parent=(nil) owner=(nil) nex=(nil) xsz=0x400000 heap=(nil)

fl2=0x20, nex=(nil)

latch set 1 of 1

durations enabled for this heap

reserved granules for root 27 (granule size 4194304)

EXTENT 0 addr=0x4d000000

Chunk 4d000038 sz=       24  R-freeable  "reserved stoppe"

Chunk 4d000050 sz=  4193964  R-perm      "perm           "  alo=4193964

Chunk 4d3ffefc sz=      236  R-free      "               "

Chunk 4d3fffe8 sz=       24  R-freeable  "reserved stoppe"

EXTENT 1 addr=0x4e000000

Chunk 4e000038 sz=       24  R-freeable  "reserved stoppe"

Chunk 4e000050 sz=   212888  R-free      "               "

Chunk 4e033fe8 sz=       24  R-freeable  "reserved stoppe"

Chunk 4e034000 sz=  1544904    perm      "perm           "  alo=1544904

Chunk 4e1ad2c8 sz=  2436408    perm      "perm           "  alo=455948

EXTENT 2 addr=0x4e400000

Chunk 4e400038 sz=       24  R-freeable  "reserved stoppe"

Chunk 4e400050 sz=   212888  R-free      "               "

Chunk 4e433fe8 sz=       24  R-freeable  "reserved stoppe"

Chunk 4e434000 sz=  3973960    perm      "perm           "  alo=3973960

Chunk 4e7fe348 sz=     3976    perm      "perm           "  alo=3976

Chunk 4e7ff2d0 sz=     3376    free      "               "

EXTENT 3 addr=0x4e800000

Chunk 4e800038 sz=       24  R-freeable  "reserved stoppe"

Chunk 4e800050 sz=   212888  R-free      "               "

Chunk 4e833fe8 sz=       24  R-freeable  "reserved stoppe"

Chunk 4e834000 sz=  3953996    perm      "perm           "  alo=3953996

Chunk 4ebf954c sz=    16400    perm      "perm           "  alo=16400

Chunk 4ebfd55c sz=     7936    perm      "perm           "  alo=7936

Chunk 4ebff45c sz=     2980    free      "               "

可以看出Oracle每次以EXTENT的形式为每个"sga heap"分配空间，而每个EXTENT的大小和GRANULE有关系

将EXTENT 0 中的所有Chunk相加：24+4193964+236+24=4194304-56

将EXTENT 1 中的所有Chunk相加：24+212888+24+1544904+2436408=4194304-56

将EXTENT 2 中的所有Chunk相加：24+212888+24+3953996+16400+7936+2980=4194304-56

这56到底是个啥？我没百度到，我猜是EXTENT HEADER的大小

Chunk

Chunk以链条Chain的形式存在于内存中，每个Chunk包含Header和Body两部分，Chunk的状态大体上分为：

FREE：          可马上使用

RECREATABLE：   可再生

FREEABLE：      只有在Session或Call期间内保存必要的对象状态

PERMANENT：     永久不可再生

其中FREE和RECREATABLE状态下的Chunk可重复使用

Free List

Free List主要用于管理空闲的Chunk，并且是用Bucket管理的.从Oracle 9i开始，一个堆总共有255个Bucket，Bucket所包含的Free Chunk大小随编号增加而递增，各Bucket下的Free Chunk以Linked list的形式连接

在DBA实战攻略一书中提到：同一个Bucket中的Chunk并不是按照大小排序的

同样在DBA思想天空中也有相似说明

那么实际是什么情况呢？

FREE LISTS:

Bucket 0 size=16

Bucket 1 size=20

Chunk 4e38e234 sz=       20    free      "               "

Chunk 4e34738c sz=       20    free      "               "

Bucket 2 size=24

Chunk 4e2a0ec4 sz=       24    free      "               "

Chunk 4d1e8e64 sz=       24    free      "               "

Chunk 4e147954 sz=       24    free      "               "

Chunk 4e33a93c sz=       24    free      "               "

Chunk 4e39b61c sz=       24    free      "               "

Bucket 3 size=28

Chunk 4e218efc sz=       28    free      "               "

Chunk 4e1af51c sz=       28    free      "               "

Chunk 4e17b9dc sz=       28    free      "               "

Chunk 4e1635e4 sz=       28    free      "               "

Chunk 4e1ff95c sz=       28    free      "               "

Chunk 4e1cac74 sz=       28    free      "               "

Chunk 4e294914 sz=       28    free      "               "

Bucket 4 size=32

Bucket 5 size=36

Bucket 6 size=40

Bucket 7 size=44

Bucket 8 size=48

Bucket 9 size=52

Bucket 10 size=56

Bucket 11 size=60

Bucket 12 size=64

Bucket 13 size=68

Chunk 4d202ad4 sz=       68    free      "               "

Chunk 4e12a47c sz=       68    free      "               "

Chunk 4e390234 sz=       68    free      "               "

Bucket 14 size=72

截取一段，我比较脑残，只能这么认为

如果真的不排序，那么当去Bucket循着链表找Chunk的时候，假如所需大小的Chunk刚好在链表的最后一位，就要遍历整条链表，这大大增加了持有Shared pool latch的时间

从我的DUMP可以看出，也许真的没有排序这一步，只不过由于BUCKET数量较8i大大增多，每个BUCKET中存在的Chunk多是一样大的？

真心希望知道的大神能给我解释解释

1.获得shared pool latch在free list中查找合适大小的空闲chunk。如果在获取shared pool latch时发生了争用，则会出现latch：shared pool等待事件。这时Oracle会一直持有shared pool latch，直到获得所需的内存为止。所在内存碎片化比较严重的shared pool中，进程持有shared pool latch的时间也会相应变长。

2.如果不存在合适大小的空闲chunk，则在查找到更大的空闲chunk后分割（split）使用，分割后剩下的内存区域则重新登记到free list中。分割内存意味着内存中的碎片开始增多。由于每个cursor所需内存的大小不同，所以shared pool的空闲内存不像buffer cache中的空闲内存一样具有固定大小.

3.如果检索了free list也没有找到所有合适的空闲chunk，则检索lru list。lru list上的chunk是重建（recreatable）的，而且是当前不使用的（没有处于pin状态）.

4.如果在lru list上也没有找到合适的chunk，且所请求的内存还没有达到隐含参数_shared_pool_reserved_min_alloc的阈值，则追加分配share pool中剩余的内存空间.

5.如果以上请求的内存均失败，则出现ORA-4031错误

Shared pool的内存碎片化是不可避免的.为了减缓Shared Pool过度碎片化，如果释放的链各个内存片在物理上是相邻的，那么Oracle会将其合并成一个大内存片。也就是说Oracle会自动定期进行内存的碎片整理。

Lru List

Lru List主要保存着当前未使用而且可以重建的Chunk，当绘画在Free list中找不到空闲Chunk时，则会在Lru List中寻找

UNPINNED RECREATABLE CHUNKS (lru first):

Chunk 517a621c sz=       32    recreate  "fixed allocatio"  latch=0x2000fc90

Chunk 4ebbd94c sz=      332    recreate  "KGLHD          "  latch=(nil)

Chunk 4eb9c7f8 sz=      332    recreate  "KGLHD          "  latch=(nil)

Chunk 4eb66c68 sz=      332    recreate  "KGLHD          "  latch=(nil)

Chunk 4eb6aaa4 sz=      332    recreate  "KGLHD          "  latch=(nil)

Chunk 4eb3dadc sz=      332    recreate  "KGLHD          "  latch=(nil)

Chunk 4eb3fde0 sz=      332    recreate  "KGLHD          "  latch=(nil)

Chunk 4eb2e7fc sz=      332    recreate  "KGLHD          "  latch=(nil)

Chunk 4efed6ec sz=       40    recreate  "fixed allocatio"  latch=0x4ff04cd8

Chunk 4eb283ec sz=      540    recreate  "KQR PO         "  latch=0x4ff04cd8

Chunk 4eb28608 sz=      540    recreate  "KQR PO         "  latch=0x4ff04cd8

Chunk 4eb27398 sz=       32    recreate  "fixed allocatio"  latch=0x4ff04920

Chunk 4eb2692c sz=       32    recreate  "fixed allocatio"  latch=0x2000e4cc

Chunk 4eb258f4 sz=       32    recreate  "fixed allocatio"  latch=0x4ff04570

Reserved Pool

Oracle是从7.1.5版本开始支持保留池的，保留池的设计目的是为了在共享池碎片化很严重的时候，还能够有一部分保留空间，用于较大的内存分配。

通过shared_pool_reserved_size来设置保留池大小，一般可以不设置，默认是5%

保留池使用条件

1.在共享池freelist中找不到足够大的Chunk

2.在lru list上也没有找不到合适的chunk或可重建的recreatable且状态为unpin的chunk

3.分配的内容要大于_SHARED_POOL_RESERVED_MIN_ALLOC(默认值为4400B)，就是说超过这个值得内存分配才被认为是大内存分配

一些常用的系统对象往往在4000-4400B，因此在碎片化很严重且经常由于ORA-04031导致宕机的系统中，将这个参数设置得小一点(比如4000或3800)是十分有必要的

select indx from  x$ksppi where   upper(ksppinm) =‘_SHARED_POOL_RESERVED_MIN_ALLOC‘;

INDX

----------

153

[email protected]>select ksppstvl from  x$ksppsv where  indx =153;

KSPPSTVL

----------------------------------------------------------------------------------------------------

4400

select indx from  x$ksppi where   upper(ksppinm) =‘_SHARED_POOL_RESERVED_PCT‘;

INDX

----------

152

select ksppstvl from  x$ksppsv where  indx =152;

KSPPSTVL

----------------------------------------------------------------------------------------------------

5

保留池是否过小？

select REQUEST_MISSES from v$shared_pool_reserved;

这个查询，查询出在保留区申请不到空间的次数(request_failures)，我们希望它是0，如果大于0，就要视情况考虑增大保留区大小

保留池是否过大？

reuest_misses为0且没有增长

Free space ≥ SHARED_POOL_RESERVED_SIZE Minimum

需要注意的是保留池会随着shared pool扩大而扩大，且即使缩小Shared Pool后也无法缩小，Flush也没用

时间： 2024-10-11 16:39:21

理解Shared Pool 1的相关文章

理解Shared Pool 2

Shared Pool的Sub Pool技术 由于硬解析时需要从Shared Pool重分配内存(分配内存是需要持有Shared Pool Latch),所以在硬解析比较多的系统中,非常容易引起Shared Pool Latch的征用.为了减缓该Latch的征用,从Oracle 9i开始,共享池可分为多个子池(Sub Pool)来管理(最多7个),下一节将主要讲解Shared Pool的Sub Pool技术. Sub Pool数量受以下几个因素的影响: 系统CPU的数量.默认情况下,在Oracl

[转载】——故障排除：Shared Pool优化和Library Cache Latch冲突优化 (文档 ID 1523934.1)

原文链接:https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=181268979889050&id=62143.1&displayIndex=5&_afrWindowMode=0&_adf.ctrl-state=177vgme69e_105#aref_section212用途   提出问题,得到帮助并分享您的心得   排错步骤   什么是shared pool?   专用术语   Literal S

buffer cache 和shared pool 详解（之三，shared pool原理）

[深入解析--eygle] 学习笔记 1.2 shared pool原理 Shared Pool是Oracle SGA设置中最复杂也是最重要的一部分内容,Oracle通过Shared Pool来实现SQL共享.减少代码硬解析等,从而提高数据库的性能.在某些版本中,如果设置不当,Shared Pool可能会极大影响数据库的正常运行. 在Oracle 7之前,Shared Pool并不存在,每个Oracle连接都有一个独立的Server进程与之相关联,Server进程负责解析和优化所有SQL和PL/

buffer cache 和shared pool详解（之五，问题诊断总结）

[深入解析--eygle] 学习笔记 1.2.7 诊断和解决ORA-04031 错误 Shared  Pool的主要问题在根本上只有一个,就是碎片过多带来的性能影响. 1.2.7.1 什么是ORA-04031错误 当尝试在共享池分配大块的连续内存失败(很多时候是由于碎片过多,而并非真是内存不足)时,Oracle首先清除共享池中当前没使用的所有对象,使空闲内存块合并.如果仍然没有足够大的单块内存可以满足需要,就会产生ORA-04031错误. 如下一段伪代码来描述04031错误的产生: Scan f

Oracle数据库案例整理-Oracle系统执行时故障-Shared Pool内存不足导致数据库响应缓慢

1.1       现象描写叙述 数据库节点响应缓慢,部分用户业务受到影响. 查看数据库告警日志,開始显示ORA-07445错误,然后是大量的ORA-04031错误和ORA-00600错误. 检查数据库日志,数据库仍处于活动状态的信息例如以下: Sat Jul 17 07:51:52 2010 Thread 1 advanced to log sequence 266272   Current log# 2 seq# 266272 mem# 0: /dev/rlv_redo121   Curre

Oracle设置Shared Pool的大小

在oracle 10G或者11G版本中,如何合理设置shared pool大小,对oracle数据库的性能影响很大. Shared Pool的大小设置规则如下: 1.查到shared pool设置的合理值,语句如下: select 'Shared Pool' component, shared_pool_size_for_estimate estd_sp_size, estd_lc_time_saved_factor parse_time_factor, case when current_pa

Shared pool

1. Shared pool是SGA设置中最复杂也是最重要的一部分内容,Oracle通过Shared pool来实现sql共享,减少代码硬分析等,从而提高数据库的性能.Shared pool的大小可以通过初始化参数shared_pool_size设置. 2. 把Shared pool的内存结构在level 2级转储出来,内容被记录在一个trace文件中,这个trace文件在undmp目录下. alter session set events 'immediate trace name heapd

shared pool implement

由于shared pool中最重要的是library cache,所以本文主要讲解Library cache的结构,library cache latch,library cache lock,library cache pin. What is shared pool?   Shared pool是SGA中的一部分,由于它是SGA的一部分,这意味着它可以被所有的进程所访问,Shared Pool当中主要包含了2部分:library cache和 dictionary cache 也称为 row

Gathering Initial Troubleshooting Information for Analysis of ORA-4031 Errors on the Shared Pool

In this Document   Purpose   Troubleshooting Steps   References APPLIES TO: Oracle Database - Enterprise Edition - Version 8.0.6.3 and later Information in this document applies to any platform. PURPOSE The purpose of this document is to provide some