开发学院数据库 Oracle library cache pin与PROCEDURE的重建阅读

library cache pin与PROCEDURE的重建

　2008-12-16 13:05:49　来源：WEB开发网　闂傚倸鍊搁崐鎼佸磹閹间礁纾瑰瀣椤愯姤鎱ㄥ鍡楀幊缂傚倹姘ㄩ幉绋款吋閸澀缃曢梻鍌欑濠€閬嶆惞鎼淬劌绐楅柡宥庡亞娑撳秵銇勯弽顐沪闁绘挶鍎甸弻锝夊即閻愭祴鍋撻崷顓涘亾濮樼偓瀚�

闂傚倸鍊搁崐鎼佸磹閹间礁纾瑰瀣捣閻棗銆掑锝呬壕濡ょ姷鍋涢ˇ鐢稿极閹剧粯鍋愰柟缁樺笧閳ь剦鍙冨鍝勑ч崶褏浠奸梺璇茬箲閼归箖鎮鹃悜钘夎摕闁靛濡囬崢鐢告⒑鐟欏嫷鍟忛柛鐘崇墵閵嗗倹绺介崨濠勫幈闁硅壈鎻槐鏇熺墡闂備線娼уú銈団偓姘嵆閻涱噣骞掑Δ鈧粻锝嗙節闂堟稑鏆欏ù婊堢畺閺岋綁濮€閳惰泛婀辨竟鏇熺節濮橆厾鍘甸梺缁樺姦閸撴岸鎮樻潏銊ょ箚闁圭粯甯炴晶娑氱磼缂佹ḿ娲寸€规洖宕灃闁告劕鍟犻崜婵堟崲濞戞ḿ鏆嗗┑鐘辫兌閺佹牜绱撴担浠嬪摵闁圭懓娲ら悾鐑藉箳閹搭厽鍍甸梺鐟板悁閻掞箓鎮楅幖浣光拻濞达絿鍎ら崵鈧梺鎼炲€栭悧鐘荤嵁韫囨稒鏅搁柨鐕傛嫹

婵犵數濮烽弫鍛婃叏閻戣棄鏋侀柛娑橈攻閸欏繑銇勯幘鍗炵仼缂佺媭鍨堕弻娑㈠箛闂堟稒鐏堥悗鐟版啞缁诲啴濡甸崟顖氱閻庨潧鎽滈悾濂告⒑绾拋娼愭繛鑼枎椤繒绱掑Ο鑲╂嚌闂侀€炲苯澧畝锝堝劵椤︽煡鎮￠妶澶嬬厪闁割偅绻冮崑顏呯箾瀹割喕绨婚幆鐔兼⒑鐎圭姵銆冮柤鍐茬埣瀹曟繈鏁冮埀顒勨€旈崘顔嘉ч柛鈩冾殘閻熸劙姊洪悡搴℃毐闁绘牕銈稿畷鐑樼節閸パ冨祮闂侀潧楠忕槐鏇㈠储椤忓牊鈷戦柟鑲╁仜閸旀鏌￠崨顔锯姇缂佸倹甯熼ˇ瀵哥磼鏉堛劌绗氭繛鐓庣箻閸┾剝鎷呴柨瀣垫綗闂傚倷娴囧銊╂倿閿曞倸绠查柛銉墮閺嬩線鏌熼崜褏甯涢柡鍛倐閺屻劑鎮ら崒娑橆伓闂傚倸鍊搁崐鎼佸磹閹间礁纾瑰瀣椤愯姤鎱ㄥ鍡楀幊缂傚倹姘ㄩ幉绋款吋閸澀缃曢梻鍌欑濠€閬嶆惞鎼淬劌绐楅柡宥庡亞娑撳秵銇勯弽顐沪闁绘挶鍎甸弻锝夊即閻愭祴鍋撻崷顓涘亾濮樼偓瀚�　　闂傚倸鍊搁崐鎼佸磹閹间礁纾归柣鎴ｅГ閸ゅ嫰鏌ら崫銉︽毄濞寸姵姘ㄧ槐鎾诲磼濞嗘帒鍘＄紓渚囧櫘閸ㄥ爼濡撮崘顔煎窛闁哄鍨归崢娲倵楠炲灝鍔氭い锔诲灦瀹曪繝骞庨懞銉у帾闂婎偄娲﹀ú鏍ㄧ墡闂備浇顕х€垫帡宕滈悢濂夋綎闁惧繐婀辩壕鍏间繆椤栨碍鎯堟い顐㈢焸濮婃椽宕烽娑欏珱闂佺ǹ顑呭Λ婵嬪箚閳ь剚銇勮箛鎾寸ォ婵☆垰瀚板娲传閸曨剚鎷卞┑鐐插级宀ｅ潡骞戦姀鐘斀濠电姴瀚弶鎼佹⒑閸濆嫭宸濆┑顔惧厴閹即濡烽埡鍌楁嫽婵炶揪绲介幖顐ゆ暜鐠轰警鐔嗛柣鐔峰簻閺€鑽ょ磼閸屾氨孝妤楊亙鍗冲畷鐓庮潩閿濆懍澹曢梺鍝勫暙閻楀棛绮堥崘鈹夸簻闊洤娴烽ˇ锕€霉濠婂牏鐣洪柡灞诲妼閳规垿宕卞☉鎵佸亾濡も偓椤儻顧侀柛鐘崇墵濠€渚€姊虹紒妯曟垿鎮烽妷褉鍋撳鐓庢灓缂侇喚绮妶锝夊礃閳哄啫骞堟俊鐐€栭崝鎴﹀磹閺囥垹鍑犻幖娣妽閻撶喖鐓崶褜鍎忛柛鏃€绮撻弻鏇㈠炊瑜嶉顓犫偓娈垮枟濞兼瑨鐏掗梺鍛婄箓鐎氼剝顤傛繝纰夌磿閸嬫垿宕愰幋锕€鍨傛繛宸簼閸嬶繝鏌嶉崫鍕櫣缂佺姵鐗犻弻宥夊煛娴ｅ憡娈查梺绋挎捣閸犳牠寮婚弴銏犵倞鐟滃秶鑺辨繝姘厵闁告垯鍊栫€氾拷

核心提示： 当第一个session执行完成之后，第二个session的操作随之完成，library cache pin与PROCEDURE的重建(2)，我们可以看到LAST_DDL_TIME并未改变：SQL> exec calling;PL/SQL procedure successfully

当第一个session执行完成之后，第二个session的操作随之完成，我们可以看到LAST_DDL_TIME并未改变：

SQL> exec calling;PL/SQL procedure successfully completed. SQL> SQL> select object_name,last_ddl_time from dba_objects where object_name in ('PINING','CALLING'); OBJECT_NAME LAST_DDL_TIME ------------------------------ ------------------- CALLING 2007-04-02 09:12:57 PINING 2007-04-02 09:12:57

实际上session 2执行了一次无谓的Library Cache Pin，理想的方式应该是，Oracle能够判断之前的Library Cache Pin的模式，如果是共享模式，则可以跳过Pin请求，如果是排他模式，则必须等待，目前的处理并不能从实质上改变竞争。

不过并非全无益处，我们发现，对于另一类DDL操作，Oracle完全可以跳过Library Cache Pin的请求，这类操作是Grant，在以前版本中的行为可以参考：

http://www.eygle.com/archives/2004/10/shared_pool-5.html

在Oracle10g中，Grant授权操作无需再获得Library Cache Pin的排他锁，我们看以下测试：

在Session 1中执行：

09:40:18 SQL> drop procedure calling;Procedure dropped. 09:40:18 SQL> 09:40:18 SQL> drop procedure pining; Procedure dropped. 09:40:18 SQL> 09:40:18 SQL> create or replace PROCEDURE pining 09:40:18 2 IS 09:40:18 3 BEGIN 09:40:18 4 NULL; 09:40:18 5 END; 09:40:18 6 / Procedure created. 09:40:18 SQL> 09:40:18 SQL> alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss'; Session altered. 09:40:18 SQL> create or replace procedure calling 09:40:18 2 is 09:40:18 3 begin 09:40:18 4 pining; 09:40:18 5 dbms_lock.sleep(60); 09:40:18 6 end; 09:40:18 7 / Procedure created. 09:40:18 SQL> 09:40:18 SQL> col object_name for a30 09:40:18 SQL> select object_name,last_ddl_time from dba_objects where object_name in ('PINING','CALLING'); OBJECT_NAME LAST_DDL_TIME ------------------------------ ------------------- CALLING 2007-04-02 09:40:18 PINING 2007-04-02 09:40:18 09:40:18 SQL> 09:40:18 SQL> exec calling;

在Session 2执行授权：

SQL> set time on 09:40:22 SQL> grant execute on pining to sys;Grant succeeded. 09:40:22 SQL>

我们看到Session 2的授权顺利通过，再转到Session 1：

09:40:18 SQL> exec calling;PL/SQL procedure successfully completed. 09:41:18 SQL> 09:41:18 SQL> select object_name,last_ddl_time from dba_objects where object_name in ('PINING','CALLING'); OBJECT_NAME LAST_DDL_TIME ------------------------------ ------------------- CALLING 2007-04-02 09:40:18 PINING 2007-04-02 09:40:22

我们看到对象PINING的LAST_DDL_TIME已经变化。

看来Grant已经能够绕过了Library Cache Pin的竞争，这是Oracle10g的增强。

这个问题最早由网友dqpylf在阅读我的新书《深入浅出Oracle》，在不同版本中测试案例时发现，今天才有时间做一点探究，感谢dqpylf。

-The End-

-----

上一页 1 2