深入理解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
深入理解shared pool共享池之library cache系列一的更多相关文章
- 深入理解shared pool共享池之library cache系列二
背景 继续上文:深入理解shared pool共享池之library cache系列一,学习library cache数据结构,本文主要学习library cache object(lco)的数据结构 ...
- 深入理解shared pool共享池之library cache的library cache lock系列四
本文了解下等待事件library cache lock,进一步理解library cache,之前的文章请见: 深入理解shared pool共享池之library cache的library ca ...
- 深入理解shared pool共享池之library cache的library cache pin系列三
关于library cache相关的LATCH非常多,名称差不多,我相信一些人对这些概念还是有些晕,我之前也有些晕,希望此文可以对这些概念有个更为清晰的理解,本文主要学习library cache p ...
- 共享内存shared pool （3）：Library cache
Shared pool物理层面上由许多内存块(chunck)组成.从逻辑功能划分,Shared pool主要由三部分组成:Library cache,Dictionary cache和Control ...
- shared pool详解
共享池shared pool的概念用户提交的命令:解析.执行用户命令的解析解析的过程是一个相当复杂的过程,它要考虑各种可能的异常情况比如SQL语句涉及到的对象不存在.提交的用户没有权限等等而且还需要考 ...
- Oracle-buffer cache、shared pool
http://blog.csdn.net/panfelix/article/details/38347059 buffer pool 和shared pool 详解 http://blog.csd ...
- Oracle Shared Pool 原理
Oracle Shared Pool 原理 由于shared pool中最重要的是library cache,所以本文主要讲解Library cache的结构,library cache latch, ...
- Oracle数据库体系结构-Shared Pool
Oracle数据库简单介绍 对象关系型数据库 重点:一致性+性能 一致性优于性能 处理模型:C/S模型 Client:用户和用户进程 Server:服务器进程,实例,数据库本身 ...
- Oracle内存详解之 Library cache 库缓冲
Oracle内存详解之 Library cache 库缓冲 2017年11月09日 11:38:39 阅读数:410更多 个人分类: 体系结构 Library cache是Shared pool的一部 ...
随机推荐
- 海量jQuery插件
转自:http://blog.csdn.net/zzq58157383/article/details/6900142 提醒大家在使用的时候注意jQuery包的版本问题,最好是使用相同的版本,因为使用 ...
- selenium webdriver(6)---cookie相关操作
介绍selenium操作cookie之前,先简单介绍一下cookie的基础知识 cookie cookie一般用来识别用户身份和记录用户状态,存储在客户端电脑上.IE的cookie文件路径(win7) ...
- poj 1039 Pipe（几何基础）
Pipe Time Limit: 1000MS Memory Limit: 10000K Total Submissions: 9932 Accepted: 3045 Description ...
- HW4.20
public class Solution { public static void main(String[] args) { boolean isPrime = true; int count = ...
- ZOJ Problem Set - 1025解题报告
ZOJ Problem Set - 1025 题目分类:基础题 原题地址:http://acm.zju.edu.cn/onlinejudge/showProblem.do?problemCode=10 ...
- usaco 猜数游戏
Description 为了提高智商,锻炼思维能力,奶牛设计了一个猜数游戏.游戏开始前,贝西会在牛棚后面摆上N个数字.所有数字排成一条直线,按次序从1到N编号.每个数字在1到10^9之间,没有两个数字 ...
- 【Java重构系列】重构31式之搬移方法
重构第二式:搬移方法 (Refactoring 2: Move Method) 毋容置疑,搬移方法(Move Method)应该是最常用的重构手段之一,正因为太常用而且较为简单,以至于很多人并不认为它 ...
- 337. House Robber III
二刷吧..不知道为什么house robbery系列我找不到笔记,不过印象中做了好几次了. 不是很难,用的post-order做bottom-up的运算. 对于一个Node来说,有2种情况,一种是选( ...
- WebBindingInitializer学习
今天在看开源代码的时候遇到了这个接口,于是查阅了下相关的资料 Spring web mvc学习笔记 http://www.cnblogs.com/crazy-fox/archive/2012/02/1 ...
- hdu 4634 Swipe Bo 搜索
典型的bfs模拟 (广度优先搜索) ,不过有好多细节要注意,比如图中如果是 R# 走到这个R的话就无限往右走了,这样就挂了~肯定到不了出口.还有一种容易造成死循环的,比如 #E## DLLL D. ...