基於oracle 10.2.0.1 rac死鎖deadlock檢測時間相關隱含引數及機制之一_lm_dd_interval

wisdomone1發表於2015-11-10

背景

   在分析基於oracle 10.2.0.1 rac的死鎖時,發現ORACLE檢測死鎖的時間明顯要慢於單例項資料庫,當然,這是取決於ORACLE RAC的架構設計;不過我想,肯定會有相關引數控制死鎖
檢測時間,本文主要研究這方面的相關知識,達到進一步理解基於RAC死鎖相關的知識。   


結論

1,基於oracle 10.2.0.1 rac的死鎖檢測,由引數:_lm_dd_interval控制,其預設值為60,單位為秒
  此引數可以調整,須重啟庫
2,如果要調整此引數,要從幾方面考量下:
   在測試環境進行大量全面測試後,方可上線到生產環境
   查詢相關與此引數相關的BUG,避免有此風險
   調整此引數可以引發LMD程式更為繁忙,或者引發RAC資料庫資料不一致,因為你想,檢測死鎖的時間更長了
3,我分析思路如下:
    透過如下指令碼  
set linesize 300
col name_1 for a50
col value_1 for a50
col desc1 for a50




select
ksppinm as name_1,
ksppstvl as value_1,
ksppdesc as desc1
from x$ksppi x, x$ksppcv y
where (x.indx = y.indx) and lower(x.ksppinm) like '%&parameter%';


查詢關鍵字lock,找到相關相關引數,進行依次測試,發現不成
然後轉換思路,查詢關鍵字lm(其含義為lock manager,即鎖管理器),找到相關引數,進行測試對應,最終定位到引數


這個有個最為重要的地方,就是如何理解這些隱含引數:
我的方法:
   1,從引數的命名,進行猜測,
   2,如果引數命名還不能得到引數的含義,結合其註解
   3,然後為其配置不同的值,進行對比測試,瞭解此引數的真正含義
   4,如果測試完全和你期望不一樣,可能是你的方法不對,具體就是要找的隱含引數不對,你要採用新的關鍵字進行查詢
   5,這個到底要用什麼新的關鍵字,就看你對ORACLE原理的理解了,只有你理解更多更深,才能聯想到相關的一些技術的關鍵字
   6,最後如果實在不成,可以BAIDU或GOOGLE,強烈不建議直接查它們,我們要提升自己的分析能力,你直接找到答案,卻錯過了分析解決的問題的機會,你自己選吧


4,感嘆,ORACLE隱含引數確實非常深入,還要很多點要學習   




測試



--oracle version
SQL> select * from v$version where rownum=1;


BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bi


---oracle deadlock
SQL> update t_lock set a=11 where a=1;


1 row updated.


SQL> update t_lock set a=22 where a=2;
update t_lock set a=22 where a=2
       *
ERROR at line 1:
ORA-00060: deadlock detected while waiting for resource


11g和10g的死鎖檢測時間不一樣,且引數是什麼,是否有變化




oracle 10.2.0.1推測與死鎖檢測相關的引數:
_kgl_time_to_wait_for_locks                        15                                                 time to wait for locks and pins before timing out




不過從死鎖檢測的時間好像不止是上述指定的15秒喲,超過1分鐘了
01:28:50 SQL> update t_lock set a=22 where a=2;
update t_lock set a=22 where a=2
       *
ERROR at line 1:
ORA-00060: deadlock detected while waiting for resource




Elapsed: 00:01:08.01




先試著加大上述引數,看有無效果,即可判斷是否此引數控制死鎖檢測的時間


此引數須重啟RAC資料庫
(2個節點皆操作)
01:31:28 SQL> alter system set "_kgl_time_to_wait_for_locks"=25;
alter system set "_kgl_time_to_wait_for_locks"=25
                 *
ERROR at line 1:
ORA-02095: specified initialization parameter cannot be modified




Elapsed: 00:00:00.00
01:33:12 SQL> alter system set "_kgl_time_to_wait_for_locks"=25 scope=spfile;


System altered.


01:33:44 SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
01:34:08 SQL> startup
ORACLE instance started.


Total System Global Area  599785472 bytes
Fixed Size                  2022632 bytes
Variable Size             260047640 bytes
Database Buffers          335544320 bytes
Redo Buffers                2170880 bytes
Database mounted.
Database opened.


NAME_1                                             VALUE_1                                            DESC1
-------------------------------------------------- -------------------------------------------------- --------------------------------------------------
_kgl_time_to_wait_for_locks                        25                                                 time to wait for locks and pins before timing out




重現死鎖
01:41:46 SQL> update t_lock set a=22 where a=2;
update t_lock set a=22 where a=2
       *
ERROR at line 1:
ORA-00060: deadlock detected while waiting for resource




Elapsed: 00:01:07.81


可見不是上述引數控制死鎖檢測的時間




我們繼續找相關的引數


--可見此引數的值為空
_ksmg_lock_check_interval                                                                             timeout action interval in minutes


同上理,重啟庫以使引數生效
01:48:17 SQL> conn /as sysdba
Connected.
01:48:52 SQL> alter system set "_ksmg_lock_check_interval"=2 scope=spfile;


System altered.


Elapsed: 00:00:00.13


調整引數已生效
NAME_1                                             VALUE_1                                            DESC1
-------------------------------------------------- -------------------------------------------------- --------------------------------------------------
_ksmg_lock_check_interval                          2                                                  timeout action interval in minutes




--重現死鎖
01:57:24 SQL> update t_lock set a=22 where a=2;
update t_lock set a=22 where a=2
       *
ERROR at line 1:
ORA-00060: deadlock detected while waiting for resource




Elapsed: 00:01:08.60
01:58:46 SQL> 


可見也不是此引數在控制


說明是其它引數在控制著,我們來分析下,我上面獲取相關引數的指令碼為
set linesize 300
col name_1 for a50
col value_1 for a50
col desc1 for a50




select
ksppinm as name_1,
ksppstvl as value_1,
ksppdesc as desc1
from x$ksppi x, x$ksppcv y
where (x.indx = y.indx) and lower(x.ksppinm) like '%&parameter%';


一直採用lock關鍵字進行匹配


我們換個思路,會不會要用其它關鍵字進行查詢呢,哪到底是什麼關鍵字呢,我想可能是lm,因為lm表明lock manager鎖管理器(當然這個需要你對RAC要有一點的瞭解)
然後基於上述基礎,再查詢interval,何義呢,就是多久查詢一次,也就是說死鎖檢測的間隔是多久


_lm_dd_interval                                    60                                                 dd time interval in seconds  --從這個值我看和上述發現死鎖的時間差不多
_lm_dd_scan_interval                               5                                                  dd scan interval in seconds






我們調整此引數


調整後
NAME_1                                             VALUE_1                                            DESC1
-------------------------------------------------- -------------------------------------------------- --------------------------------------------------
_lm_dd_interval                                    120                                                dd time interval in seconds


重現死鎖


02:18:32 SQL> update t_lock set a=11 where a=1;
update t_lock set a=11 where a=1
       *
ERROR at line 1:
ORA-00060: deadlock detected while waiting for resource




Elapsed: 00:02:07.87


可見確實是此引數控制死鎖檢測的時間


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/9240380/viewspace-1826578/,如需轉載,請註明出處,否則將追究法律責任。

相關文章