Library cache pin/lock 在Oracle 10g的增強
從Oracle 10g開始,以上測試將不會看到同樣的效果,這是因為Oracle 10g對於物件編譯與重建做出了增強。注意以下測試(來自Oracle 10gR2環境):
sys@NEI> alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss';
Session altered.
sys@NEI> select object_name,last_ddl_time from user_objects where object_name='PINING';
OBJECT_NAME LAST_DDL_TIME
-------------------- -------------------
PINING 2009-12-06 15:09:24
sys@NEI> create or replace PROCEDURE pining
2 IS
3 BEGIN
4 NULL;
5 END;
6 /
Procedure created.
sys@NEI> select object_name,last_ddl_time from user_objects where object_name='PINING';
OBJECT_NAME LAST_DDL_TIME
-------------------- -------------------
PINING 2009-12-06 15:09:24
注意當重新replace一個過程時,Oracle會首先執行檢查,如果程式碼前後完全相同,則replace工作並不會真正進行(因為沒有變化),物件的LAST_DDL_TIME不會改變,這就意味著Latch的競爭可以減少。
再來看一下此前的測試在Oracle 10g中的情況如果。
首先在Session 1中執行:
sys@NEI> create or replace PROCEDURE pining
2 IS
3 BEGIN
4 NULL;
5 END;
6 /
Procedure created.
sys@NEI> create or replace procedure calling
2 is
3 begin
4 pining;
5 dbms_lock.sleep(60);
6 end;
7 /
Procedure created.
sys@NEI> select object_name,last_ddl_time from dba_objects where object_name in ('PINING','CALLING');
OBJECT_NAME LAST_DDL_TIME
-------------------- -------------------
PINING 2009-12-06 15:26:58
CALLING 2009-12-06 15:19:38
sys@NEI> set time on
15:31:49 sys@NEI> exec calling;
PL/SQL procedure successfully completed.
15:32:59 sys@NEI>
在Session 1過程中,切換到Session 2執行授權:
sys@NEI> set time on
15:32:00 sys@NEI> grant execute on pining to tq;
Grant succeeded.
可以看到Session 2的授權順利通過,再轉到Session 1:
15:32:59 sys@NEI> select object_name,last_ddl_time from dba_objects where object_name in ('PINING','CALLING');
OBJECT_NAME LAST_DDL_TIME
-------------------- -------------------
PINING 2009-12-06 15:32:02
CALLING 2009-12-06 15:19:38
注意到物件pining的LAST_DDL_TIME已經變化。grant授權已經能夠繞過library cache pin的競爭,這是Oracle 10g的增強。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/8183550/viewspace-659590/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- library cache pin和library cache lock(一)
- library cache pin和library cache lock (zt)
- library cache pin和library cache lock(二)
- Library Cache最佳化篇(一)降低library cache lock和library cache pin的方法
- 【ASK_ORACLE】Library cache pin 與 library load lock的關係和區別Oracle
- [20240920]跟蹤library cache lock library cache pin使用gdb.txt
- [20240824]跟蹤library cache lock library cache pin使用gdb.txt
- Library Cache 診斷:Lock, Pin 以及 Load Lock (文件 ID 1548524.1)
- 【ASK_ORACLE】Library Cache概念篇(二)之Library Cache Pin的定義Oracle
- [20241105]跟蹤library cache lock library cache pin使用gdb(11g)2.txt
- [20241108]跟蹤library cache lock library cache pin使用gdb(11g)4.txt
- [20241108]跟蹤library cache lock library cache pin使用gdb(11g)3.txt
- library cache pin(轉)
- 【等待事件】library cache pin事件
- 【TUNE_ORACLE】等待事件之“library cache lock”Oracle事件
- library cache lock和library cache bin實驗_2.0
- 【ASM_ORACLE】Library Cache最佳化篇(二)Library cache load lock的概念和解決辦法ASMOracle
- ORACLE LOCK,LATCH,PINOracle
- latch:library cache lock等待事件事件
- Oracle Library cacheOracle
- DBA手記(學習)-library cache pin
- Oracle 11g 密碼延遲認證與 library cache lock 等待Oracle密碼
- 一次library cache lock 問題分析
- Oracle11g 密碼延遲認證導致library cache lock的情況分析Oracle密碼
- 10G FGA的增強
- 徹底搞清楚library cache lock的成因和解決方法(轉)
- 【TUNE_ORACLE】等待事件之“library cache pins”Oracle事件
- Oracle RAC Cache Fusion 系列十:Oracle RAC Enqueues And Lock Part 1OracleENQ
- [20220301]oracle如何定位使用library cache mutex.txtOracleMutex
- Oracle 10g 增刪節點Oracle 10g
- [20240827]分析為什麼出現library cache lock等待事件2.txt事件
- [20240828]分析為什麼出現library cache lock等待事件5.txt事件
- [20220302]oracle如何定位使用library cache mutex 2.txtOracleMutex
- [20220303]oracle如何定位使用library cache mutex 3.txtOracleMutex
- 重啟大法失效?詳述Oracle11g因JDBC bug引發異常Library Cache Lock等待處理事件OracleJDBC事件
- [20190402]Library Cache mutex.txtMutex
- [20210507]dump library_cache.txt
- [20190530]DISABLE TABLE LOCK(10g).txt
- 故障:核心表業務高峰期授權導致library cache lock和mutex x競爭Mutex