转载

深入理解shared pool共享池之library cache系列一

背景

   为了更为直观理解library cache,贴2张相关图,如下:

深入理解shared pool共享池之library cache系列一



深入理解shared pool共享池之library cache系列一

结论

1,oradebug dump library_cache不同级别dump的library cache内容及粒度会有所区别,具体见测试开始部分
2,本文测示基于oradebug dump library_cache 32,即产生最为详细的library cachem内容,进而分析library cache数据结构
3,关于创建表的DDL,表,以及基于表的SQL或DML,皆会存储到不同的bucket的library object handle
4,大小写不同的SQL会存储到不同的bucket的library object handle
5,而基于不同用户的相同SQL,会存储到同一个bucket的library object handle
  不过在library object handle的结构
  CHILDREN: size=16
    child#    table reference   handle
    ------ -------- --------- --------
         0 9da2a040  9da14758 a3552c48 ---同下,这个就是sql的多个子游标,即VERSION_COUNT
         1 9da2a040  9d9cf240 a3541fc0 ---这个就是上述基于用户TEST生成的子游标,handle又会指向ANONYMOUS LIST: 中的对应的bucket


   进而真正指向
   对应不同的 ANONYMOUS LIST: 中的对应的不同的library object handle,所以你从这儿就可以想想,如果一个SQL的子游标过多,它就会花费更多的时间去扫描这些数据结构,哪消耗的LATCH或MUTEX就会更严重     
   ANONYMOUS LIST:
LIBRARY OBJECT HANDLE: handle=a3552c48 mtx=0xa3552d78(0) lct=2 pct=3 cdp=0 --即对应child#=0的上述子游标的SQL
  namespace=CRSR flags=RON/KGHP/PN0/EXP/[10010100]
  kkkk-dddd-llll=0000-0001-0001 lock=0 pin=0 latch#=6 hpc=fffe hlc=fffe
  lwt=0xa3552cf0[0xa3552cf0,0xa3552cf0] ltm=0xa3552d00[0xa3552d00,0xa3552d00]
  pwt=0xa3552cb8[0xa3552cb8,0xa3552cb8] ptm=0xa3552cc8[0xa3552cc8,0xa3552cc8]
  ref=0xa3552d20[0x9da14758,0x9da14758] lnd=0xa3552d38[0xa3552d38,0xa3552d38]
    CHILD REFERENCES:
    reference latch flags
    --------- ----- -------------------
     9da14758     5 CHL[02]
    LIBRARY OBJECT: object=9da13ff0
    type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
    DEPENDENCIES: count=2 size=16    --可见dependencies table结构仅会在ANONYMOUS LIST: 的library object handle中出现
    dependency#    table reference   handle position flags
    ----------- -------- --------- -------- -------- -------------------
              0 9da13ab8  9da137f8 a355af28       16 DEP[01]
              1 9da13ab8  9da138f8 a3552868        0 DEP[01]
    ACCESSES: count=1 size=16
    dependency# types
    ----------- -----
              0 0009
    TRANSLATIONS: count=1 size=16
    original    final
    -------- --------
    a355af28 a355af28
    DATA BLOCKS:
    data#     heap  pointer    status pins change whr alloc(K)  size(K)
    ----- -------- -------- --------- ---- ------ --- -------- --------
        0 a3552b88 9da14108 I/-/A/-/-    0 NONE   00      2.99     3.12
        6 9da14528 9bb9f1d8 I/-/A/-/E    0 NONE   00      5.51     7.90 


 6, 通过反向思维,可见如下的bucket对应ANONYMOUS LIST:的LIBRARY OBJECT HANDLE中的dependencies table
这里存储的是SQL的基表,即dependencies table结构存储SQL的基表
BUCKET 6797:
  LIBRARY OBJECT HANDLE: handle=a355af28 mtx=0xa355b058(0) lct=5 pct=5 cdp=0
  name=SCOTT.T_LIBRARYCACHE_TEST 
  hash=05c45c99776e0d8b6ac751c65d6a1a8d timestamp=11-23-2015 12:13:49
  namespace=TABL flags=KGHP/TIM/SML/[02000000]
  kkkk-dddd-llll=0000-0701-0201 lock=N pin=0 latch#=1 hpc=0004 hlc=0004
  lwt=0xa355afd0[0xa355afd0,0xa355afd0] ltm=0xa355afe0[0xa355afe0,0xa355afe0]
  pwt=0xa355af98[0xa355af98,0xa355af98] ptm=0xa355afa8[0xa355afa8,0xa355afa8]
  ref=0xa355b000[0xa355b000,0xa355b000] lnd=0xa355b018[0xa056f858,0xa3561368]
    DEPENDENCY REFERENCES:
    reference latch flags
    --------- ----- -------------------
     9da05028     7 DEP[01] whr=0 timestamp=11-23-2015 12:13:49
     9da137f8     5 DEP[01] whr=0 timestamp=11-23-2015 12:13:49
     9da03618     1 DEP[01] whr=0 timestamp=11-23-2015 12:13:49
     9d9c3340     1 DEP[01] whr=0 timestamp=11-23-2015 12:13:49
    LOCK OWNERS:
        lock     user  session count mode flags
    -------- -------- -------- ----- ---- ------------------------
    9eb68b78 a4726cc0 a4726cc0     0 N    [4044]
    LIBRARY OBJECT: object=9da24a60
    type=TABL flags=EXS/LOC[0005] pflags=[0000] status=VALD load=0
    DATA BLOCKS:
    data#     heap  pointer    status pins change whr alloc(K)  size(K)
    ----- -------- -------- --------- ---- ------ --- -------- --------
        0 a355ae68 9da24bb8 I/-/A/-/-    0 NONE   00      0.43     1.09
        8 9da1baf0 9bb7be98 I/-/A/-/-    0 NONE   00      0.84     1.09
  BUCKET 6797 total object count=1  


  真白说就是dependency table存储SQL的基表信息
 
 7,可见authorization table结构仅存在于ANONYMOUS LIST中的library object handle
ANONYMOUS LIST:
LIBRARY OBJECT HANDLE: handle=a354e960 mtx=0xa354ea90(0) lct=4 pct=22 cdp=0
  namespace=CRSR flags=RON/KGHP/PN0/EXP/[10010100]
  kkkk-dddd-llll=0000-0001-0001 lock=0 pin=0 latch#=11 hpc=fffa hlc=fffa
  lwt=0xa354ea08[0xa354ea08,0xa354ea08] ltm=0xa354ea18[0xa354ea18,0xa354ea18]
  pwt=0xa354e9d0[0xa354e9d0,0xa354e9d0] ptm=0xa354e9e0[0xa354e9e0,0xa354e9e0]
  ref=0xa354ea38[0x9da0a3a8,0x9da0a3a8] lnd=0xa354ea50[0xa354ea50,0xa354ea50]
    CHILD REFERENCES:
    reference latch flags
    --------- ----- -------------------
     9da0a3a8     0 CHL[02]
    LIBRARY OBJECT: object=9da09c40
    type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
    DEPENDENCIES: count=1 size=16
    dependency#    table reference   handle position flags
    ----------- -------- --------- -------- -------- -------------------
              0 9da09708  9da09448 a39b2420       18 DEP[01]
    AUTHORIZATIONS: count=1 size=16 minimum entrysize=18
    0000 00000000 00004000 00000000 00000000 
    ACCESSES: count=1 size=16
    dependency# types
    ----------- -----
              0 0006
    DATA BLOCKS:
    data#     heap  pointer    status pins change whr alloc(K)  size(K)
    ----- -------- -------- --------- ---- ------ --- -------- --------
        0 a354e8a0 9da09d58 I/-/A/-/-    0 NONE   00      3.63     4.16
        6 9da0a178 9bb516e0 I/-/A/-/E    0 NONE   00     20.03    23.74    


   直白的说就是:存储SQL查询相关的授权信息,当然这块内容我的理解还不够,还要研究


8,可见SQL的子游标信息是存储在ANONYMOUS LIST:中,而其没有bucket的概念,仅有library object handle的概念

9,关于lco的数据结构data block还没有研究,下文进行测试

测试



----基于之前的文章:oracle library cache之trace小记,了解下DUMP LIBRARY CACHE的命令区别
http://blog.itpub.net/9240380/viewspace-759136/


如下命令含义:
ALTER SESSION SET EVENTS 'immediate trace name LIBRARY_CACHE level LL';(也适用于oradebug dump library_cache,只是2种命令形式)
 
其中LL代表Level级别,对于9.2.0及以后版本,不同Level含义如下:
Level =1 ,转储Library cache统计信息
Level =2 ,转储hash table概要
Level =4 ,转储Library cache对象,只包含基本信息
Level =8 ,转储Library cache对象,包含详细信息(包括child references,pin waiters等)
Level =16,增加heap sizes信息
Level =32,增加heap信息




---为了针对性分析library cache的结构,生成测试用例
SQL> show user
USER is "SCOTT"


SQL> create table t_librarycache_test(a int,b int);


Table created.


SQL> select a,b from t_librarycache_test;


no rows selected


---转储LIBRARY_CACHE
SQL> oradebug setmypid
Statement processed.
SQL> oradebug dump library_cache 32
Statement processed.
SQL> oradebug tracefile_name
/home/ora10g/admin/ora10g/udump/ora10g_ora_12595.trc


----这就是上述测试示例中查询SQL对应的bucket
BUCKET 103856:
  LIBRARY OBJECT HANDLE: handle=a3552e78 mtx=0xa3552fa8(1) lct=1 pct=1 cdp=1
  name=select a,b from t_librarycache_test
  hash=af65d142f6d90c766be1ab2d410795b0 timestamp=11-23-2015 12:14:05
  namespace=CRSR flags=RON/KGHP/TIM/PN0/SML/KST/DBN/MTX/[120100d0]
  kkkk-dddd-llll=0000-0001-0001 lock=N pin=0 latch#=6 hpc=0002 hlc=0002
  lwt=0xa3552f20[0xa3552f20,0xa3552f20] ltm=0xa3552f30[0xa3552f30,0xa3552f30]
  pwt=0xa3552ee8[0xa3552ee8,0xa3552ee8] ptm=0xa3552ef8[0xa3552ef8,0xa3552ef8]
  ref=0xa3552f50[0xa3552f50,0xa3552f50] lnd=0xa3552f68[0xa3552f68,0xa3552f68]
    LOCK OWNERS:
        lock     user  session count mode flags
    -------- -------- -------- ----- ---- ------------------------
    9ebce080 a4726cc0 a4726cc0     1 N    [00]
    LIBRARY OBJECT: object=9da2a140
    type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
    CHILDREN: size=16
    child#    table reference   handle
    ------ -------- --------- --------
         0 9da2a040  9da14758 a3552c48
    DATA BLOCKS:
    data#     heap  pointer    status pins change whr alloc(K)  size(K)
    ----- -------- -------- --------- ---- ------ --- -------- --------
        0 a3552db8 9da2a258 I/P/A/-/-    0 NONE   00      1.59     2.17
  BUCKET 103856 total object count=1


---可见与测试示例中查询SQL所依赖的表也对应一个BUCKET
  BUCKET 6797:
  LIBRARY OBJECT HANDLE: handle=a355af28 mtx=0xa355b058(0) lct=2 pct=2 cdp=0
  name=SCOTT.T_LIBRARYCACHE_TEST 
  略
  BUCKET 6797 total object count=1




---同上,可见相关表的DDL及DML及基表皆会归属到不同的BUCKET中
  BUCKET 92409:
  LIBRARY OBJECT HANDLE: handle=a3560e98 mtx=0xa3560fc8(1) lct=1 pct=1 cdp=0
  name=create table t_librarycache_test(a int,b int)
  略
  BUCKET 92409 total object count=1




----继续测试用例
SQL> select a,b from t_librarycache_test where rownum<1;


no rows selected


SQL> select a,b from t_librarycache_test where rownum<2;


no rows selected


可见上述2个测试SQL示例,是会对应2个不同的BUCKET中的LIBRARY OBJECT HANDLE
BUCKET 48737:
  LIBRARY OBJECT HANDLE: handle=a35c5208 mtx=0xa35c5338(1) lct=1 pct=1 cdp=1
  name=select a,b from t_librarycache_test where rownum<1


BUCKET 94348:
  LIBRARY OBJECT HANDLE: handle=a357b328 mtx=0xa357b458(1) lct=1 pct=1 cdp=1
  name=select a,b from t_librarycache_test where rownum<2  




---继续测试,在新的用户创建上述相同的测试用例(即相同表且相同查询SQL)
SQL> conn test/system
Connected.
SQL> create table t_librarycache_test(a int,b int);


Table created.


SQL> select a,b from t_librarycache_test;


no rows selected


可见如果基于不同用户但查询SQL相同,会生成多少子游标的SQL
BUCKET 103856:
  LIBRARY OBJECT HANDLE: handle=a3552e78 mtx=0xa3552fa8(2) lct=2 pct=1 cdp=2
  name=select a,b from t_librarycache_test
  hash=af65d142f6d90c766be1ab2d410795b0 timestamp=11-23-2015 12:14:05
  namespace=CRSR flags=RON/KGHP/TIM/PN0/SML/KST/DBN/MTX/[120100d0]
  kkkk-dddd-llll=0000-0001-0001 lock=0 pin=0 latch#=6 hpc=0000 hlc=0000
  lwt=0xa3552f20[0xa3552f20,0xa3552f20] ltm=0xa3552f30[0xa3552f30,0xa3552f30]
  pwt=0xa3552ee8[0xa3552ee8,0xa3552ee8] ptm=0xa3552ef8[0xa3552ef8,0xa3552ef8]
  ref=0xa3552f50[0xa3552f50,0xa3552f50] lnd=0xa3552f68[0xa3552f68,0xa3552f68]
    LIBRARY OBJECT: object=9da2a140
    type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
    CHILDREN: size=16
    child#    table reference   handle
    ------ -------- --------- --------
         0 9da2a040  9da14758 a3552c48 ---同下,这个就是sql的多个子游标,即VERSION_COUNT
         1 9da2a040  9d9cf240 a3541fc0 ---这个就是上述基于用户TEST生成的子游标,handle又会指向ANONYMOUS LIST: 中的对应的bucket
    DATA BLOCKS:
    data#     heap  pointer    status pins change whr alloc(K)  size(K)
    ----- -------- -------- --------- ---- ------ --- -------- --------
        0 a3552db8 9da2a258 I/P/A/-/-    0 NONE   00      1.59     2.17
  BUCKET 103856 total object count=1


--继续测试,相同SQL,但大小写不同
SQL> select a,b from t_librarycache_TEST;


no rows selected


可见相同SQL,但大小写相同,仍会创建新的BUCKET及所属的library object handle
BUCKET 72150:
  LIBRARY OBJECT HANDLE: handle=a3546fa0 mtx=0xa35470d0(1) lct=1 pct=1 cdp=1
  name=select a,b from t_librarycache_TEST
  hash=d1d69941caf41b2804ac6df2538519d6 timestamp=11-23-2015 12:47:40
  namespace=CRSR flags=RON/KGHP/TIM/PN0/SML/KST/DBN/MTX/[120100d0]
  kkkk-dddd-llll=0000-0001-0001 lock=N pin=0 latch#=10 hpc=0002 hlc=0002
  lwt=0xa3547048[0xa3547048,0xa3547048] ltm=0xa3547058[0xa3547058,0xa3547058]
  pwt=0xa3547010[0xa3547010,0xa3547010] ptm=0xa3547020[0xa3547020,0xa3547020]
  ref=0xa3547078[0xa3547078,0xa3547078] lnd=0xa3547090[0xa3547090,0xa3547090]
    LOCK OWNERS:
        lock     user  session count mode flags
    -------- -------- -------- ----- ---- ------------------------
    9ebce080 a4726cc0 a4726cc0     1 N    [00]
    LIBRARY OBJECT: object=9d9c4840
    type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
    CHILDREN: size=16
    child#    table reference   handle
    ------ -------- --------- --------
         0 9d9c4740  9d9c42a0 a3546d60
    DATA BLOCKS:
    data#     heap  pointer    status pins change whr alloc(K)  size(K)
    ----- -------- -------- --------- ---- ------ --- -------- --------
        0 a3546ee0 9d9c4958 I/P/A/-/-    0 NONE   00      1.59     2.17
  BUCKET 72150 total object count=1




由下可见相同SQL的不同子游标存储到ANONYMOUS LIST的不同的library object handle
ANONYMOUS LIST:
LIBRARY OBJECT HANDLE: handle=a3552c48 mtx=0xa3552d78(0) lct=2 pct=3 cdp=0 --即对应child#=0的上述子游标的SQL
  namespace=CRSR flags=RON/KGHP/PN0/EXP/[10010100]
  kkkk-dddd-llll=0000-0001-0001 lock=0 pin=0 latch#=6 hpc=fffe hlc=fffe
  lwt=0xa3552cf0[0xa3552cf0,0xa3552cf0] ltm=0xa3552d00[0xa3552d00,0xa3552d00]
  pwt=0xa3552cb8[0xa3552cb8,0xa3552cb8] ptm=0xa3552cc8[0xa3552cc8,0xa3552cc8]
  ref=0xa3552d20[0x9da14758,0x9da14758] lnd=0xa3552d38[0xa3552d38,0xa3552d38]
    CHILD REFERENCES:
    reference latch flags
    --------- ----- -------------------
     9da14758     5 CHL[02]
    LIBRARY OBJECT: object=9da13ff0
    type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
    DEPENDENCIES: count=2 size=16    --可见dependencies table结构仅会在ANONYMOUS LIST: 的library object handle中出现
    dependency#    table reference   handle position flags
    ----------- -------- --------- -------- -------- -------------------
              0 9da13ab8  9da137f8 a355af28       16 DEP[01]
              1 9da13ab8  9da138f8 a3552868        0 DEP[01]
    ACCESSES: count=1 size=16
    dependency# types
    ----------- -----
              0 0009
    TRANSLATIONS: count=1 size=16
    original    final
    -------- --------
    a355af28 a355af28
    DATA BLOCKS:
    data#     heap  pointer    status pins change whr alloc(K)  size(K)
    ----- -------- -------- --------- ---- ------ --- -------- --------
        0 a3552b88 9da14108 I/-/A/-/-    0 NONE   00      2.99     3.12
        6 9da14528 9bb9f1d8 I/-/A/-/E    0 NONE   00      5.51     7.90




LIBRARY OBJECT HANDLE: handle=a3541fc0 mtx=0xa35420f0(0) lct=1 pct=2 cdp=0 --即对应child#=1的上述子游标的SQL
  namespace=CRSR flags=RON/KGHP/PN0/EXP/[10010100]
  kkkk-dddd-llll=0000-0001-0001 lock=0 pin=0 latch#=6 hpc=0000 hlc=0000
  lwt=0xa3542068[0xa3542068,0xa3542068] ltm=0xa3542078[0xa3542078,0xa3542078]
  pwt=0xa3542030[0xa3542030,0xa3542030] ptm=0xa3542040[0xa3542040,0xa3542040]
  ref=0xa3542098[0x9d9cf240,0x9d9cf240] lnd=0xa35420b0[0xa35420b0,0xa35420b0]
    CHILD REFERENCES:
    reference latch flags
    --------- ----- -------------------
     9d9cf240     5 CHL[02]
    LIBRARY OBJECT: object=9d9ceba8
    type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
    DEPENDENCIES: count=2 size=16
    dependency#    table reference   handle position flags
    ----------- -------- --------- -------- -------- -------------------
              0 9d9c58c0  9d9c5600 a3542c08       16 DEP[01]
              1 9d9c58c0  9d9c5700 a3552868        0 DEP[01]
    ACCESSES: count=1 size=16
    dependency# types
    ----------- -----
              0 0009
    TRANSLATIONS: count=1 size=16
    original    final
    -------- --------
    a3542c08 a3542c08
    DATA BLOCKS:
    data#     heap  pointer    status pins change whr alloc(K)  size(K)
    ----- -------- -------- --------- ---- ------ --- -------- --------
        0 a3541f00 9d9cecc0 I/-/A/-/-    0 NONE   00      2.93     3.12
        6 9d9cf0e0 9bb2c580 I/-/A/-/E    0 NONE   00      5.05     7.90




通过反向思维,可见如下的bucket对应ANONYMOUS LIST:的LIBRARY OBJECT HANDLE中的dependencies table
这里存储的是SQL的基表,即dependencies table结构存储SQL的基表
BUCKET 6797:
  LIBRARY OBJECT HANDLE: handle=a355af28 mtx=0xa355b058(0) lct=5 pct=5 cdp=0
  name=SCOTT.T_LIBRARYCACHE_TEST 
  hash=05c45c99776e0d8b6ac751c65d6a1a8d timestamp=11-23-2015 12:13:49
  namespace=TABL flags=KGHP/TIM/SML/[02000000]
  kkkk-dddd-llll=0000-0701-0201 lock=N pin=0 latch#=1 hpc=0004 hlc=0004
  lwt=0xa355afd0[0xa355afd0,0xa355afd0] ltm=0xa355afe0[0xa355afe0,0xa355afe0]
  pwt=0xa355af98[0xa355af98,0xa355af98] ptm=0xa355afa8[0xa355afa8,0xa355afa8]
  ref=0xa355b000[0xa355b000,0xa355b000] lnd=0xa355b018[0xa056f858,0xa3561368]
    DEPENDENCY REFERENCES:
    reference latch flags
    --------- ----- -------------------
     9da05028     7 DEP[01] whr=0 timestamp=11-23-2015 12:13:49
     9da137f8     5 DEP[01] whr=0 timestamp=11-23-2015 12:13:49
     9da03618     1 DEP[01] whr=0 timestamp=11-23-2015 12:13:49
     9d9c3340     1 DEP[01] whr=0 timestamp=11-23-2015 12:13:49
    LOCK OWNERS:
        lock     user  session count mode flags
    -------- -------- -------- ----- ---- ------------------------
    9eb68b78 a4726cc0 a4726cc0     0 N    [4044]
    LIBRARY OBJECT: object=9da24a60
    type=TABL flags=EXS/LOC[0005] pflags=[0000] status=VALD load=0
    DATA BLOCKS:
    data#     heap  pointer    status pins change whr alloc(K)  size(K)
    ----- -------- -------- --------- ---- ------ --- -------- --------
        0 a355ae68 9da24bb8 I/-/A/-/-    0 NONE   00      0.43     1.09
        8 9da1baf0 9bb7be98 I/-/A/-/-    0 NONE   00      0.84     1.09
  BUCKET 6797 total object count=1




可见authorization table结构仅存在于ANONYMOUS LIST中的library object handle
ANONYMOUS LIST:
LIBRARY OBJECT HANDLE: handle=a354e960 mtx=0xa354ea90(0) lct=4 pct=22 cdp=0
  namespace=CRSR flags=RON/KGHP/PN0/EXP/[10010100]
  kkkk-dddd-llll=0000-0001-0001 lock=0 pin=0 latch#=11 hpc=fffa hlc=fffa
  lwt=0xa354ea08[0xa354ea08,0xa354ea08] ltm=0xa354ea18[0xa354ea18,0xa354ea18]
  pwt=0xa354e9d0[0xa354e9d0,0xa354e9d0] ptm=0xa354e9e0[0xa354e9e0,0xa354e9e0]
  ref=0xa354ea38[0x9da0a3a8,0x9da0a3a8] lnd=0xa354ea50[0xa354ea50,0xa354ea50]
    CHILD REFERENCES:
    reference latch flags
    --------- ----- -------------------
     9da0a3a8     0 CHL[02]
    LIBRARY OBJECT: object=9da09c40
    type=CRSR flags=EXS[0001] pflags=[0000] status=VALD load=0
    DEPENDENCIES: count=1 size=16
    dependency#    table reference   handle position flags
    ----------- -------- --------- -------- -------- -------------------
              0 9da09708  9da09448 a39b2420       18 DEP[01]
    AUTHORIZATIONS: count=1 size=16 minimum entrysize=18
    0000 00000000 00004000 00000000 00000000 
    ACCESSES: count=1 size=16
    dependency# types
    ----------- -----
              0 0006
    DATA BLOCKS:
    data#     heap  pointer    status pins change whr alloc(K)  size(K)
    ----- -------- -------- --------- ---- ------ --- -------- --------
        0 a354e8a0 9da09d58 I/-/A/-/-    0 NONE   00      3.63     4.16
        6 9da0a178 9bb516e0 I/-/A/-/E    0 NONE   00     20.03    23.74
正文到此结束
Loading...