shared pool 原理

﹏ヽ暗。殇╰゛Y 2022-05-28 05:36 233阅读 0赞

![技术分享][29492784_142209311827BZ.png]

堆管理

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文件

sys@PROD>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

sys@PROD>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的大小

![技术分享][29492784_14220931575QPP.png]

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思想天空中也有相似说明  
![技术分享][29492784_1422094214g3gw.png]  
![技术分享][29492784_1422094223C67s.png]

那么实际是什么情况呢？

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多是一样大的？

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

![技术分享][29492784_1422093282sp9y.png]

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  
  
sys@PROD>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也没用

==========================================================================

由于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 cache。

Library cache包含了共享SQL区(shared SQL areas),私有SQL区(private SQLareas,如果配置了共享服务器),PL/SQL存储过程以及包，还有一些控制信息，比如说locks以及library cache handles。

Dictionary cache包含了表，视图的依赖信息，比如表结构，它的用户，Oracle在解析SQL的时候就会频繁的访问dictionary cache。

**How is it managed?**

** **

Shared pool和PGA都是由一个Oracle的内存管理器来管理，我们称之为KGH heap manager。Heap Manager不是一个进程，而是一串代码。Heap Manager主要目的就是满足server 进程请求memory 的时候分配内存或者释放内存。Heap Manager在管理PGA的时候，Heap Manager需要和操作系统来打交道来分配或者回收内存。但是呢，在shared pool中，内存是预先分配的，Heap Manager管理所有的空闲内存。当某个进程需要分配shared pool的内存的时候，Heap Manager就满足该请求，Heap Manager也和其他ORACLE模块一起工作来回收shared pool的空闲内存。

**Library Cache Manager**

** **

Library cache Manager 可以看做是Heap Manager的客户端，因为library cache manager是根据Heap Manager来分配内存从而存放library cache objects。Library cache Manager控制所有的library cache object，包括package/procedure, cursor, trigger等等。

**Hash Table and Hash Bucket**

** **

Library cache是由一个hash table组成，这个hash table又由hash bucket组成的数组构成，每个hash bucket又是由一些相互指向的library cache handle所组成，library cache object handle就指向具体的library cache object以及一些引用列表。

Library Cache结构示意图如下：

![0_1290763340ai3J.gif][]

**Library Cache handle**

我们对Library cache中所有对象的访问是通过利用library cache handle来实现的，也就是说我们想要访问library cache object，我们必须先找到library cache handle。Library cache handle指向library cache object,它包含了library object的名字，命名空间，时间戳，引用列表，lock对象以及pin对象的列表信息等等。Library cache handle也被library cache用来记录哪个用户在这个这个handle上有lock，或者是哪个用户正在等待获得这个lock。那么这里我们也知道了library cache lock是发生在handle上的。

当一个进程请求library cache object, library cache manager就会应用一个hash 算法，从而得到一个hash 值，根据相应的hash值到相应的hash bucket中去寻找。这里的hash算法原理与buffer cache中快速定位block的原理是一样的。如果library cache object在内存中，那么这个library cache handle就会被找到。有时候，当shared pool不够大，library cache handle会保留在内存中，然而library cache heap由于内存不足被age out，这个时候我们请求的object heap就会被重载。最坏的情况下，library cache handle在内存中没有找到，这个时候就必须分配一个新的library cache handle，同时object heap也会被加载到内存中。

**Library Cache Object**

** **

Library Cache Object是由一些独立的heap所组成，前面说了Library cache handle指向Library cache Object，其实handle是指向第一个heap,这个heap 我们就称之为heap 0。Heap 0记录了指向其他heap的指针信息。

![0_1290763414mRrE.gif][]

根据上面描述，Library cache中的的Library cache object结构示意图可以用上图来表示(本图摘自DSI405)

**Library cache lock/pin**

** **

Library cache lock/pin是用来控制对library cache object的并发访问的。Lock管理并发，pin管理一致性，lock是针对于library cache handle,而pin是针对于heap。

当我们想要访问某个library cache object，我们首先要获得这个指向这个object的handle的lock，获得这个lock之后我们就需要pin住指向这个object的heap。

当我们对包，存储过程，函数，视图进行编译的时候，Oracle就会在这些对象的handle上面首先获得一个library cache lock，然后再在这些对象的heap上获得pin，这样就能保证在编译的时候其它进程不会来更改这些对象的定义，或者将对象删除。

当一个session对SQL语句进行硬解析的时候，这个session就必须获得library cache lock，这样其他session就不能够访问或者更改这个SQL所引用的对象。如果这个等待事件花了很长时间，通常表明共享池太小(由于共享池太小，需要搜索free的chunk，或者将某些可以被移出的object page out，这样要花很长时间)，当然了，也有可能另外的session正在对object进行修改(比如split 分区),而当前session需要引用那个table，那么这种情况下我们必须等另外的session进行完毕。

Library Cache lock有3中模式：

l  Share(S):     当读取一个library cache object的时候获得

l  Exclusive(X): 当创建/修改一个library cache object的时候获得

l  Null(N)：     用来确保对象依赖性

比如一个进程想要编译某个视图，那么就会获得一个共享锁，如果我们要create/drop/alter某个对象，那么就会获得exclusive lock。Null锁非常特殊，我们在任何可以执行的对象(cursor，function)上面都拥有NULL锁，我们可以随时打破这个NULL锁，当这个NULL锁被打破了,就表示这个对象被更改了，需要从新编译。NULL锁主要的目的就是标记某个对象是否有效。比如一个SQL语句在解析的时候获得了NULL 锁，如果这个SQL的对象一直在共享池中，那么这个NULL锁就会一直存在下去，当这个SQL语句所引用的表被修改之后，这个NULL锁就被打破了，因为修改这个SQL语句的时候会获得Exclusive 锁，

由于NULL锁被打破了，下次执行这个SQL的时候就需要从新编译。

Library Cache pin有2种模式：

l  Share(S):     读取object heap

l  Exclusive(X)：修改object heap

Library Cache pin没有什么好说的，当某个session想要读取object heap，就需要获得一个共享模式的pin，当某个session想要修改object heap，就需要获得排他的pin。当然了在获得pin之前必须获得lock。

下面就是一个在Oracle10g RAC环境中的Library cache lock的案例

这个RAC环境有2个节点

SQL> select inst\_id from gv$instance;

INST\_ID

\----------

在第一个节点中，session 4538被library cache lock阻塞

SQL> select inst\_id,sid,serial\#,event ,p1raw,machine,status from gv$session where username='BX5685';

INST\_ID        SID    SERIAL\# EVENT                          P1RAW            MACHINE              STATUS

\---------- ---------- ---------- ------------------------ ------------     --------

1       4538      39833 library cache lock       C000000346FBA458 bdhp4462         ACTIVE

在Node1上面查询

SQL> select \* from dba\_kgllock where kgllkreq > 0;

KGLLKUSE         KGLLKHDL           KGLLKMOD   KGLLKREQ KGLLKTYPE

\---------------- ---------------- ---------- ---------- ------------

C0000004789EF9D0 C000000346FBA458          0          2 Lock

SQL> select kglnaown, kglnaobj from x$kglob where kglhdadr = 'C000000346FBA458';

KGLNAOWN             KGLNAOBJ

\-------------------- --------------------

IDWSU1               PROD\_ASSOC\_DNORM

SQL> select kglhdadr, kglnaown, kglnaobj from x$kglob where kglnaobj = 'PROD\_ASSOC\_DNORM' and KGLNAOWN='IDWSU1';

KGLHDADR         KGLNAOWN             KGLNAOBJ

\---------------- -------------------- --------------------

C000000346FBA458 IDWSU1               PROD\_ASSOC\_DNORM

在Node2上面查询

SQL> select kglhdadr, kglnaown, kglnaobj from x$kglob where kglnaobj = 'PROD\_ASSOC\_DNORM' and KGLNAOWN='IDWSU1';

KGLHDADR                       KGLNAOWN             KGLNAOBJ

\------------------------------ -------------------- ------------------------------

C000000443267070               IDWSU1               PROD\_ASSOC\_DNORM

C00000035C33E248               IDWSU1               PROD\_ASSOC\_DNORM

SQL> col event format a30

select sid, serial\#,s.event, sql\_text from dba\_kgllock w, v$session s, v$sqlarea a

where w.kgllkuse = s.saddr and w.kgllkhdl='C000000443267070'

and s.sql\_address = a.address

and s.sql\_hash\_value = a.hash\_value;SQL>   2    3    4

SID    SERIAL\# EVENT                          SQL\_TEXT

\---------- ---------- ------------------------------

4774      36583 db file scattered read         ALTER TABLE PROD\_ASSOC\_DNORM ENABLE CONSTRAINT PROD\_ASSOC\_DNORM\_PK USING INDEX STORAGE ( INITIAL 4194304 NEXT 4194304 PCTINCREASE 0 ) TABLESPACE CDW\_REFERENCE01M LOCAL

在Oracle10gR2中，library cache pin被library cache mutex 所取代

**Library cache Latch**

Library cache latch用来控制对library cache object的并发访问。前面已经提到，我们要访问library cache object之前必须获得library cache lock， lock不是一个原子操作(原子操作就是在操作程中不会被打破的操作，很明显这里的lock可以被打破),Oracle为了保护这个lock，引入了library cache latch机制，也就是说在获得library cache lock之前，需要先获得library cache latch，当获得library cache lock之后就释放library cache latch。

如果某个library cache object没有在内存中，那么这个lock就不能被获取，这个时候需要获得一个library cache load lock latch，然后再获取一个library cache load lock,当load lock获得之后就释放library cache load lock latch。

我们来看一下在 Oracle10gR2 中的一个有关library cache latch，

library cache lock, library cache pin 的统计情况

SQL> select name,gets,misses,sleeps  from v$latch where name like '%library%';

NAME                                 GETS     MISSES     SLEEPS

\------------------------------ ---------- ---------- ----------

library cache                  1937415298    5513866    2346346

library cache lock              734620587     425030       3021

library cache pin               171326029     108613        868

library cache pin allocation      2930490         35          1

library cache lock allocation     5226147        349          2

library cache load lock            720252       1762         34

library cache hash chains               0          0          0

library cache latch受隐含参数\_KGL\_LATCH\_COUNT的控制，默认值为大于等于系统中CPU个数的最小素数，但是Oracle对其有一个硬性限制，该参数不能大于67。注意：我们去查询\_kgl\_latch\_count有时候显示为0,这是一个bug。

那么library cache object handle是由哪个子latch来保护的呢？Oracle利用下面算法来确定：

**latch\# = mod(bucket\#, \#latches)(摘自DSI405)**

也就是说用哪个子latch去保护某个handle是根据那个handle所在的bucket号，以及总共有多少个子latch来进行hash运算得到的，对此我们不必深究。

**latch contention**

根据前面的讲解，存在大量硬解析的系统上面就必然引发library cache latch, library cache lock竞争，下面就是一个每秒高达74个硬解析所引发

Library cache lock 成为Top wait event的一个案例。

**Load Profile**

<table> 
 <tbody> 
 <tr> 
 <td style="background:#FFFFFF;">&nbsp;</td> 
 <td style="background:#0066cc;">Per Second</td> 
 <td style="background:#0066cc;">Per Transaction</td> 
 </tr> 
 <tr> 
 <td style="background:#FFFFFF;">Redo size:</td> 
 <td style="background:#FFFFFF;">832,040.22</td> 
 <td style="background:#FFFFFF;">10,738.95</td> 
 </tr> 
 <tr> 
 <td style="background:#ffffcc;">Logical reads:</td> 
 <td style="background:#ffffcc;">56,114.37</td> 
 <td style="background:#ffffcc;">724.26</td> 
 </tr> 
 <tr> 
 <td style="background:#FFFFFF;">Block changes:</td> 
 <td style="background:#FFFFFF;">5,897.48</td> 
 <td style="background:#FFFFFF;">76.12</td> 
 </tr> 
 <tr> 
 <td style="background:#ffffcc;">Physical reads:</td> 
 <td style="background:#ffffcc;">3,442.07</td> 
 <td style="background:#ffffcc;">44.43</td> 
 </tr> 
 <tr> 
 <td style="background:#FFFFFF;">Physical writes:</td> 
 <td style="background:#FFFFFF;">174.41</td> 
 <td style="background:#FFFFFF;">2.25</td> 
 </tr> 
 <tr> 
 <td style="background:#ffffcc;">User calls:</td> 
 <td style="background:#ffffcc;">273.48</td> 
 <td style="background:#ffffcc;">3.53</td> 
 </tr> 
 <tr> 
 <td style="background:#FFFFFF;">Parses:</td> 
 <td style="background:#FFFFFF;">82.02</td> 
 <td style="background:#FFFFFF;">1.06</td> 
 </tr> 
 <tr> 
 <td style="background:#ffffcc;">Hard parses:</td> 
 <td style="background:#ffffcc;">74.53</td> 
 <td style="background:#ffffcc;">0.96</td> 
 </tr> 
 <tr> 
 <td style="background:#FFFFFF;">Sorts:</td> 
 <td style="background:#FFFFFF;">121.00</td> 
 <td style="background:#FFFFFF;">1.56</td> 
 </tr> 
 <tr> 
 <td style="background:#ffffcc;">Logons:</td> 
 <td style="background:#ffffcc;">0.09</td> 
 <td style="background:#ffffcc;">0.00</td> 
 </tr> 
 <tr> 
 <td style="background:#FFFFFF;">Executes:</td> 
 <td style="background:#FFFFFF;">160.67</td> 
 <td style="background:#FFFFFF;">2.07</td> 
 </tr> 
 <tr> 
 <td style="background:#ffffcc;">Transactions:</td> 
 <td style="background:#ffffcc;">77.48</td> 
 <td style="background:#ffffcc;">&nbsp;</td> 
 </tr> 
 </tbody> 
</table>

**Top 5 Timed Events**

<table> 
 <tbody> 
 <tr> 
 <td style="background:#0066cc;">Event</td> 
 <td style="background:#0066cc;">Waits</td> 
 <td style="background:#0066cc;">Time(s)</td> 
 <td style="background:#0066cc;">Avg Wait(ms)</td> 
 <td style="background:#0066cc;">% Total Call Time</td> 
 <td style="background:#0066cc;">Wait Class</td> 
 </tr> 
 <tr> 
 <td style="background:#FFFFFF;">library cache lock</td> 
 <td style="background:#FFFFFF;">3,603</td> 
 <td style="background:#FFFFFF;">10,588</td> 
 <td style="background:#FFFFFF;">2,939</td> 
 <td style="background:#FFFFFF;">51.7</td> 
 <td style="background:#FFFFFF;">Concurrency</td> 
 </tr> 
 <tr> 
 <td style="background:#ffffcc;">CPU time</td> 
 <td style="background:#ffffcc;">&nbsp;</td> 
 <td style="background:#ffffcc;">7,059</td> 
 <td style="background:#ffffcc;">&nbsp;</td> 
 <td style="background:#ffffcc;">34.5</td> 
 <td style="background:#ffffcc;">&nbsp;</td> 
 </tr> 
 <tr> 
 <td style="background:#FFFFFF;">db file sequential read</td> 
 <td style="background:#FFFFFF;">1,454,620</td> 
 <td style="background:#FFFFFF;">1,932</td> 
 <td style="background:#FFFFFF;">1</td> 
 <td style="background:#FFFFFF;">9.4</td> 
 <td style="background:#FFFFFF;">User I/O</td> 
 </tr> 
 <tr> 
 <td style="background:#ffffcc;">db file scattered read</td> 
 <td style="background:#ffffcc;">863,507</td> 
 <td style="background:#ffffcc;">1,178</td> 
 <td style="background:#ffffcc;">1</td> 
 <td style="background:#ffffcc;">5.7</td> 
 <td style="background:#ffffcc;">User I/O</td> 
 </tr> 
 <tr> 
 <td style="background:#FFFFFF;">log file parallel write</td> 
 <td style="background:#FFFFFF;">269,164</td> 
 <td style="background:#FFFFFF;">260</td> 
 <td style="background:#FFFFFF;">1</td> 
 <td style="background:#FFFFFF;">1.3</td> 
 <td style="background:#FFFFFF;">System I/O</td> 
 </tr> 
 </tbody> 
</table>

如果shared pool过小，也会引发library cache latch竞争，与此同时还会伴随shared pool latch竞争。下面就是一个由于shared pool过小，导致library cache latch成为top wait event的案例

**Load Profile**

<table> 
 <tbody> 
 <tr> 
 <td style="background:#FFFFFF;">&nbsp;</td> 
 <td style="background:#0066cc;">Per Second</td> 
 <td style="background:#0066cc;">Per Transaction</td> 
 </tr> 
 <tr> 
 <td style="background:#FFFFFF;">Redo size:</td> 
 <td style="background:#FFFFFF;">81,060.24</td> 
 <td style="background:#FFFFFF;">32,559.33</td> 
 </tr> 
 <tr> 
 <td style="background:#ffffcc;">Logical reads:</td> 
 <td style="background:#ffffcc;">11,204.65</td> 
 <td style="background:#ffffcc;">4,500.55</td> 
 </tr> 
 <tr> 
 <td style="background:#FFFFFF;">Block changes:</td> 
 <td style="background:#FFFFFF;">414.99</td> 
 <td style="background:#FFFFFF;">166.69</td> 
 </tr> 
 <tr> 
 <td style="background:#ffffcc;">Physical reads:</td> 
 <td style="background:#ffffcc;">0.50</td> 
 <td style="background:#ffffcc;">0.20</td> 
 </tr> 
 <tr> 
 <td style="background:#FFFFFF;">Physical writes:</td> 
 <td style="background:#FFFFFF;">5.62</td> 
 <td style="background:#FFFFFF;">2.26</td> 
 </tr> 
 <tr> 
 <td style="background:#ffffcc;">User calls:</td> 
 <td style="background:#ffffcc;">189.05</td> 
 <td style="background:#ffffcc;">75.93</td> 
 </tr> 
 <tr> 
 <td style="background:#FFFFFF;">Parses:</td> 
 <td style="background:#FFFFFF;">38.51</td> 
 <td style="background:#FFFFFF;">15.47</td> 
 </tr> 
 <tr> 
 <td style="background:#ffffcc;">Hard parses:</td> 
 <td style="background:#ffffcc;">3.58</td> 
 <td style="background:#ffffcc;">1.44</td> 
 </tr> 
 <tr> 
 <td style="background:#FFFFFF;">Sorts:</td> 
 <td style="background:#FFFFFF;">24.27</td> 
 <td style="background:#FFFFFF;">9.75</td> 
 </tr> 
 <tr> 
 <td style="background:#ffffcc;">Logons:</td> 
 <td style="background:#ffffcc;">0.02</td> 
 <td style="background:#ffffcc;">0.01</td> 
 </tr> 
 <tr> 
 <td style="background:#FFFFFF;">Executes:</td> 
 <td style="background:#FFFFFF;">85.29</td> 
 <td style="background:#FFFFFF;">34.26</td> 
 </tr> 
 <tr> 
 <td style="background:#ffffcc;">Transactions:</td> 
 <td style="background:#ffffcc;">2.49</td> 
 <td style="background:#ffffcc;">&nbsp;</td> 
 </tr> 
 </tbody> 
</table>

**Top 5 Timed Events**

<table> 
 <tbody> 
 <tr> 
 <td style="background:#0066cc;">Event</td> 
 <td style="background:#0066cc;">Waits</td> 
 <td style="background:#0066cc;">Time(s)</td> 
 <td style="background:#0066cc;">Avg Wait(ms)</td> 
 <td style="background:#0066cc;">% Total Call Time</td> 
 <td style="background:#0066cc;">Wait Class</td> 
 </tr> 
 <tr> 
 <td style="background:#FFFFFF;">CPU time</td> 
 <td style="background:#FFFFFF;">&nbsp;</td> 
 <td style="background:#FFFFFF;">6,663</td> 
 <td style="background:#FFFFFF;">&nbsp;</td> 
 <td style="background:#FFFFFF;">61.0</td> 
 <td style="background:#FFFFFF;">&nbsp;</td> 
 </tr> 
 <tr> 
 <td style="background:#ffffcc;">latch: library cache</td> 
 <td style="background:#ffffcc;">1,306</td> 
 <td style="background:#ffffcc;">157</td> 
 <td style="background:#ffffcc;">120</td> 
 <td style="background:#ffffcc;">1.4</td> 
 <td style="background:#ffffcc;">Concurrency</td> 
 </tr> 
 <tr> 
 <td style="background:#FFFFFF;">latch: shared pool</td> 
 <td style="background:#FFFFFF;">5,527</td> 
 <td style="background:#FFFFFF;">152</td> 
 <td style="background:#FFFFFF;">28</td> 
 <td style="background:#FFFFFF;">1.4</td> 
 <td style="background:#FFFFFF;">Concurrency</td> 
 </tr> 
 <tr> 
 <td style="background:#ffffcc;">log file parallel write</td> 
 <td style="background:#ffffcc;">81,192</td> 
 <td style="background:#ffffcc;">122</td> 
 <td style="background:#ffffcc;">2</td> 
 <td style="background:#ffffcc;">1.1</td> 
 <td style="background:#ffffcc;">System I/O</td> 
 </tr> 
 <tr> 
 <td style="background:#FFFFFF;">log file sync</td> 
 <td style="background:#FFFFFF;">74,187</td> 
 <td style="background:#FFFFFF;">120</td> 
 <td style="background:#FFFFFF;">2</td> 
 <td style="background:#FFFFFF;">1.1</td> 
 <td style="background:#FFFFFF;">Commit</td> 
 </tr> 
 </tbody> 
</table>

**Shared Pool Advisory**

*  **SP: Shared Pool Est LC: Estimated Library Cache Factr: Factor** 
 *  **Note there is often a 1:Many correlation between a single logical object in the Library Cache, and the physical number of memory objects associated with it. Therefore comparing the number of Lib Cache objects (e.g. in v$librarycache), with the number of Lib Cache Memory Objects is invalid.**

<table> 
 <tbody> 
 <tr> 
 <td style="background:#0066cc;">Shared Pool Size(M)</td> 
 <td style="background:#0066cc;">SP Size Factr</td> 
 <td style="background:#0066cc;">Est LC Size (M)</td> 
 <td style="background:#0066cc;">Est LC Mem Obj</td> 
 <td style="background:#0066cc;">Est LC Time Saved (s)</td> 
 <td style="background:#0066cc;">Est LC Time Saved Factr</td> 
 <td style="background:#0066cc;">Est LC Load Time (s)</td> 
 <td style="background:#0066cc;">Est LC Load Time Factr</td> 
 <td style="background:#0066cc;">Est LC Mem Obj Hits</td> 
 </tr> 
 <tr> 
 <td style="background:#ffffcc;">352</td> 
 <td style="background:#ffffcc;">0.38</td> 
 <td style="background:#ffffcc;">115</td> 
 <td style="background:#ffffcc;">15,602</td> 
 <td style="background:#ffffcc;">547,132</td> 
 <td style="background:#ffffcc;">0.88</td> 
 <td style="background:#ffffcc;">82,833</td> 
 <td style="background:#ffffcc;">7.60</td> 
 <td style="background:#ffffcc;">13,561,473</td> 
 </tr> 
 <tr> 
 <td style="background:#FFFFFF;">448</td> 
 <td style="background:#FFFFFF;">0.48</td> 
 <td style="background:#FFFFFF;">210</td> 
 <td style="background:#FFFFFF;">20,206</td> 
 <td style="background:#FFFFFF;">559,218</td> 
 <td style="background:#FFFFFF;">0.90</td> 
 <td style="background:#FFFFFF;">70,747</td> 
 <td style="background:#FFFFFF;">6.49</td> 
 <td style="background:#FFFFFF;">13,681,539</td> 
 </tr> 
 <tr> 
 <td style="background:#ffffcc;">544</td> 
 <td style="background:#ffffcc;">0.59</td> 
 <td style="background:#ffffcc;">304</td> 
 <td style="background:#ffffcc;">25,430</td> 
 <td style="background:#ffffcc;">564,732</td> 
 <td style="background:#ffffcc;">0.91</td> 
 <td style="background:#ffffcc;">65,233</td> 
 <td style="background:#ffffcc;">5.99</td> 
 <td style="background:#ffffcc;">13,732,206</td> 
 </tr> 
 <tr> 
 <td style="background:#FFFFFF;">640</td> 
 <td style="background:#FFFFFF;">0.69</td> 
 <td style="background:#FFFFFF;">397</td> 
 <td style="background:#FFFFFF;">29,804</td> 
 <td style="background:#FFFFFF;">585,824</td> 
 <td style="background:#FFFFFF;">0.95</td> 
 <td style="background:#FFFFFF;">44,141</td> 
 <td style="background:#FFFFFF;">4.05</td> 
 <td style="background:#FFFFFF;">13,761,147</td> 
 </tr> 
 <tr> 
 <td style="background:#ffffcc;">736</td> 
 <td style="background:#ffffcc;">0.79</td> 
 <td style="background:#ffffcc;">492</td> 
 <td style="background:#ffffcc;">31,706</td> 
 <td style="background:#ffffcc;">606,741</td> 
 <td style="background:#ffffcc;">0.98</td> 
 <td style="background:#ffffcc;">23,224</td> 
 <td style="background:#ffffcc;">2.13</td> 
 <td style="background:#ffffcc;">13,779,369</td> 
 </tr> 
 <tr> 
 <td style="background:#FFFFFF;">832</td> 
 <td style="background:#FFFFFF;">0.90</td> 
 <td style="background:#FFFFFF;">587</td> 
 <td style="background:#FFFFFF;">33,581</td> 
 <td style="background:#FFFFFF;">614,849</td> 
 <td style="background:#FFFFFF;">0.99</td> 
 <td style="background:#FFFFFF;">15,116</td> 
 <td style="background:#FFFFFF;">1.39</td> 
 <td style="background:#FFFFFF;">13,791,238</td> 
 </tr> 
 <tr> 
 <td style="background:#ffffcc;">928</td> 
 <td style="background:#ffffcc;">1.00</td> 
 <td style="background:#ffffcc;">682</td> 
 <td style="background:#ffffcc;">35,624</td> 
 <td style="background:#ffffcc;">619,069</td> 
 <td style="background:#ffffcc;">1.00</td> 
 <td style="background:#ffffcc;">10,896</td> 
 <td style="background:#ffffcc;">1.00</td> 
 <td style="background:#ffffcc;">13,795,452</td> 
 </tr> 
 <tr> 
 <td style="background:#FFFFFF;">1,024</td> 
 <td style="background:#FFFFFF;">1.10</td> 
 <td style="background:#FFFFFF;">777</td> 
 <td style="background:#FFFFFF;">37,928</td> 
 <td style="background:#FFFFFF;">621,113</td> 
 <td style="background:#FFFFFF;">1.00</td> 
 <td style="background:#FFFFFF;">8,852</td> 
 <td style="background:#FFFFFF;">0.81</td> 
 <td style="background:#FFFFFF;">13,798,083</td> 
 </tr> 
 <tr> 
 <td style="background:#ffffcc;">1,120</td> 
 <td style="background:#ffffcc;">1.21</td> 
 <td style="background:#ffffcc;">872</td> 
 <td style="background:#ffffcc;">40,162</td> 
 <td style="background:#ffffcc;">623,021</td> 
 <td style="background:#ffffcc;">1.01</td> 
 <td style="background:#ffffcc;">6,944</td> 
 <td style="background:#ffffcc;">0.64</td> 
 <td style="background:#ffffcc;">13,799,705</td> 
 </tr> 
 <tr> 
 <td style="background:#FFFFFF;">1,216</td> 
 <td style="background:#FFFFFF;">1.31</td> 
 <td style="background:#FFFFFF;">967</td> 
 <td style="background:#FFFFFF;">42,895</td> 
 <td style="background:#FFFFFF;">624,574</td> 
 <td style="background:#FFFFFF;">1.01</td> 
 <td style="background:#FFFFFF;">5,391</td> 
 <td style="background:#FFFFFF;">0.49</td> 
 <td style="background:#FFFFFF;">13,800,847</td> 
 </tr> 
 <tr> 
 <td style="background:#ffffcc;">1,312</td> 
 <td style="background:#ffffcc;">1.41</td> 
 <td style="background:#ffffcc;">1,062</td> 
 <td style="background:#ffffcc;">45,835</td> 
 <td style="background:#ffffcc;">626,304</td> 
 <td style="background:#ffffcc;">1.01</td> 
 <td style="background:#ffffcc;">3,661</td> 
 <td style="background:#ffffcc;">0.34</td> 
 <td style="background:#ffffcc;">13,801,787</td> 
 </tr> 
 <tr> 
 <td style="background:#FFFFFF;">1,408</td> 
 <td style="background:#FFFFFF;">1.52</td> 
 <td style="background:#FFFFFF;">1,157</td> 
 <td style="background:#FFFFFF;">48,677</td> 
 <td style="background:#FFFFFF;">627,737</td> 
 <td style="background:#FFFFFF;">1.01</td> 
 <td style="background:#FFFFFF;">2,228</td> 
 <td style="background:#FFFFFF;">0.20</td> 
 <td style="background:#FFFFFF;">13,802,717</td> 
 </tr> 
 <tr> 
 <td style="background:#ffffcc;">1,504</td> 
 <td style="background:#ffffcc;">1.62</td> 
 <td style="background:#ffffcc;">1,252</td> 
 <td style="background:#ffffcc;">52,032</td> 
 <td style="background:#ffffcc;">636,469</td> 
 <td style="background:#ffffcc;">1.03</td> 
 <td style="background:#ffffcc;">1</td> 
 <td style="background:#ffffcc;">0.00</td> 
 <td style="background:#ffffcc;">13,803,727</td> 
 </tr> 
 <tr> 
 <td style="background:#FFFFFF;">1,600</td> 
 <td style="background:#FFFFFF;">1.72</td> 
 <td style="background:#FFFFFF;">1,347</td> 
 <td style="background:#FFFFFF;">56,719</td> 
 <td style="background:#FFFFFF;">637,734</td> 
 <td style="background:#FFFFFF;">1.03</td> 
 <td style="background:#FFFFFF;">1</td> 
 <td style="background:#FFFFFF;">0.00</td> 
 <td style="background:#FFFFFF;">13,804,715</td> 
 </tr> 
 <tr> 
 <td style="background:#ffffcc;">1,696</td> 
 <td style="background:#ffffcc;">1.83</td> 
 <td style="background:#ffffcc;">1,442</td> 
 <td style="background:#ffffcc;">60,885</td> 
 <td style="background:#ffffcc;">638,457</td> 
 <td style="background:#ffffcc;">1.03</td> 
 <td style="background:#ffffcc;">1</td> 
 <td style="background:#ffffcc;">0.00</td> 
 <td style="background:#ffffcc;">13,805,622</td> 
 </tr> 
 <tr> 
 <td style="background:#FFFFFF;">1,792</td> 
 <td style="background:#FFFFFF;">1.93</td> 
 <td style="background:#FFFFFF;">1,537</td> 
 <td style="background:#FFFFFF;">63,993</td> 
 <td style="background:#FFFFFF;">638,640</td> 
 <td style="background:#FFFFFF;">1.03</td> 
 <td style="background:#FFFFFF;">1</td> 
 <td style="background:#FFFFFF;">0.00</td> 
 <td style="background:#FFFFFF;">13,806,647</td> 
 </tr> 
 <tr> 
 <td style="background:#ffffcc;">1,888</td> 
 <td style="background:#ffffcc;">2.03</td> 
 <td style="background:#ffffcc;">1,632</td> 
 <td style="background:#ffffcc;">66,977</td> 
 <td style="background:#ffffcc;">638,660</td> 
 <td style="background:#ffffcc;">1.03</td> 
 <td style="background:#ffffcc;">1</td> 
 <td style="background:#ffffcc;">0.00</td> 
 <td style="background:#ffffcc;">13,807,680</td> 
 </tr> 
 </tbody> 
</table>

**Library Cache Activity**

*  **"Pct Misses" should be very low**

<table> 
 <tbody> 
 <tr> 
 <td style="background:#0066cc;">Namespace</td> 
 <td style="background:#0066cc;">Get Requests</td> 
 <td style="background:#0066cc;">Pct Miss</td> 
 <td style="background:#0066cc;">Pin Requests</td> 
 <td style="background:#0066cc;">Pct Miss</td> 
 <td style="background:#0066cc;">Reloads</td> 
 <td style="background:#0066cc;">Invali- dations</td> 
 </tr> 
 <tr> 
 <td style="background:#ffffcc;">BODY</td> 
 <td style="background:#ffffcc;">5,545</td> 
 <td style="background:#ffffcc;">0.20</td> 
 <td style="background:#ffffcc;">7,806</td> 
 <td style="background:#ffffcc;">0.40</td> 
 <td style="background:#ffffcc;">20</td> 
 <td style="background:#ffffcc;">0</td> 
 </tr> 
 <tr> 
 <td style="background:#FFFFFF;">CLUSTER</td> 
 <td style="background:#FFFFFF;">91</td> 
 <td style="background:#FFFFFF;">4.40</td> 
 <td style="background:#FFFFFF;">155</td> 
 <td style="background:#FFFFFF;">3.23</td> 
 <td style="background:#FFFFFF;">1</td> 
 <td style="background:#FFFFFF;">0</td> 
 </tr> 
 <tr> 
 <td style="background:#ffffcc;">INDEX</td> 
 <td style="background:#ffffcc;">75</td> 
 <td style="background:#ffffcc;">25.33</td> 
 <td style="background:#ffffcc;">140</td> 
 <td style="background:#ffffcc;">34.29</td> 
 <td style="background:#ffffcc;">29</td> 
 <td style="background:#ffffcc;">0</td> 
 </tr> 
 <tr> 
 <td style="background:#FFFFFF;">SQL AREA</td> 
 <td style="background:#FFFFFF;">660,357</td> 
 <td style="background:#FFFFFF;">26.67</td> 
 <td style="background:#FFFFFF;">3,184,169</td> 
 <td style="background:#FFFFFF;">9.38</td> 
 <td style="background:#FFFFFF;">8,452</td> 
 <td style="background:#FFFFFF;">120</td> 
 </tr> 
 <tr> 
 <td style="background:#ffffcc;">TABLE/PROCEDURE</td> 
 <td style="background:#ffffcc;">20,169</td> 
 <td style="background:#ffffcc;">2.45</td> 
 <td style="background:#ffffcc;">965,511</td> 
 <td style="background:#ffffcc;">0.30</td> 
 <td style="background:#ffffcc;">1,268</td> 
 <td style="background:#ffffcc;">0</td> 
 </tr> 
 <tr> 
 <td style="background:#FFFFFF;">TRIGGER</td> 
 <td style="background:#FFFFFF;">202</td> 
 <td style="background:#FFFFFF;">0.00</td> 
 <td style="background:#FFFFFF;">1,472</td> 
 <td style="background:#FFFFFF;">0.20</td> 
 <td style="background:#FFFFFF;">3</td> 
 <td style="background:#FFFFFF;">0</td> 
 </tr> 
 </tbody> 
</table>

我是怎么判断shared pool过小的呢？AWR里面提供了多个指标，这里硬解析不是太高，每秒3个，说明硬解析不会导致该问题，shared pool advice已经说得很明白了，当前shared pool只有928m,Oracle建议把shared pool至少调整到1504m。同时查看 Library cache activtiy，大家注意观察pct miss，SQL AREA的pct miss居然达到26.67%，而且重载了8452次，那么我完全可以肯定就是由于shared pool太小，导致SQL被大量重载，从而引发library cache latch竞争。

Library cache latch竞争还有可能是具有高version\_count的SQL导致的，某个session去执行一个具有很高version\_count的SQL需要pin住child cursor,而由于child cursor过多，在未pin住child cursor之前不会释放library cache latch，这样当其他session想运行该SQL的时候就会发生library cache latch争用，那么遇到这种情况请检查cursor\_sharing参数的设置，另外请查询是否遇到bug，或者由于系统中不同schema出现大量同名的表名，这样请更改设计。

在第二个案例中，由于shared pool设置过小还导致了shared pool latch处于top wait event 中的第二名。Shared pool latch是用来干嘛的呢？Shared pool latch用来保护共享池的结构，在分配，释放共享池空间的时候就会获得该latch，那么在这个案例中，由于共享池太小，在对一个新的SQL进行硬解析的时候需要老化某些对象，为新对象腾出空间，那么这个释放空间的过程就需要获得shared pool latch。当然了，在进行硬解析，也需要获得一个shared pool latch因为硬解析需要申请分配shared pool空间，而分配空间的时候就需要获得该latch。

[29492784_142209311827BZ.png]: http://blog.itpub.net/attachment/201501/24/29492784_142209311827BZ.png
[29492784_14220931575QPP.png]: http://blog.itpub.net/attachment/201501/24/29492784_14220931575QPP.png
[29492784_1422094214g3gw.png]: http://blog.itpub.net/attachment/201501/24/29492784_1422094214g3gw.png
[29492784_1422094223C67s.png]: http://blog.itpub.net/attachment/201501/24/29492784_1422094223C67s.png
[29492784_1422093282sp9y.png]: http://blog.itpub.net/attachment/201501/24/29492784_1422093282sp9y.png
[0_1290763340ai3J.gif]: /images/20220528/6c0f72d83b1c4ab6b53c0ad808ecec6a.png
[0_1290763414mRrE.gif]: /images/20220528/c56a23058e654279b389f6be92a247f9.png