解決SQL server2005數據庫死鎖的經驗心得

        前段時間提到的"sql server 2005 死鎖解決探索"，死鎖嚴重，平均天天會發生一次死鎖，在解決和處理SQL server2005死鎖中查了不少資料和想了不少辦法，後來咱們就使用瞭如下方法： 
   
   1，將數據庫隔離級別改爲行版本控制隔離級別。（沒有了共享鎖死鎖） 
   
   2，重建和優化索引，優化SQL語句和採用分區視圖等方法。提升訪問速度。（減小了鎖定時間） 
   
   3，水平拆分表（分區）並在程序讀寫時儘可能作到分區消除，減小讀寫的行數，下降鎖定升級的頻率和時間。 (減小鎖的升級) 
  對爲什麼出現死鎖和怎樣較少死鎖有了進一步認識，在這裏和你們一塊兒分享： 
   
   
   
   SQL Server 鎖類型 
   在數據庫中主要存在兩種鎖: S(共享鎖）和X(排他鎖） 
   
   S(共享鎖）：在執行查詢數據時，SQL server會將行鎖定，這時只能查詢數據，刪，改被阻塞， 
   
   X(排他鎖）：在插入和刪除數據時，將行鎖定，這時增，刪，改都被阻塞 
   
   以上兩種鎖都會引發死鎖： 
   
   死鎖定義：在兩個或多個任務中，若是每一個任務鎖定了其餘任務試圖鎖定的資源，此時會形成這些任務永久阻塞，從而出現死鎖 
   
   
   
   這裏模擬一下死鎖環境： 
   
   創建環境： 
  ----死鎖例子,創建表數據 
  create table [dbo].[[zping.com1]]]( 
  A varchar(2) 
  ,B varchar(2) 
  ,C varchar(2)) 
   
  --插入數據 
  insert into [dbo].[[zping.com1]]] 
  select 'a1','b1','c1' 
  union all select 'a2','b2','c2' 
  union all select 'a3','b3','c3' 
   
  --創建表數據 
  create table [dbo].[[zping.com2]]] 
  (D varchar(2) 
  ,E varchar(2)) 
   
   --插入數據 
  insert into [dbo].[[zping.com2]]] 
  select 'd1','e1' 
  union all select 'd2','e2' 
   
   
   
   1. 1 排他鎖引發的死鎖 
   執行語句： 
   
  begin tran 
  update [dbo].[[zping.com2]]] 
  set D='d5' 
  where E='e1' 
  waitfor delay '00:00:05' 
   
  update [dbo].[[zping.com1]]] 
  set A='aa' 
  where B='b2' 
   
   
  begin tran 
  update [dbo].[[zping.com1]]] 
  set A='aa' 
  where B='b2' 
  waitfor delay '00:00:05' 
   
  update [dbo].[[zping.com2]]] 
  set D='d5' 
  where E='e1' 
   
   
   新建兩個窗口，在5秒鐘內執行上面語句，不久就會出現死鎖提示。（結束後記住要把事務回滾啊） 
   
   1.2 共享鎖引發的死鎖 
  begin tran 
  update [dbo].[[zping.com2]]] 
  set D='d5' 
  where E='e1' 
  waitfor delay '00:00:05' 
   
  select * from [dbo].[[zping.com1]]] 
  where B='b2' 
   
   
  begin tran 
  update [dbo].[[zping.com1]]] 
  set A='aa' 
  where B='b2' 
  waitfor delay '00:00:05' 
   
  select * from [dbo].[[zping.com2]]] 
  where E='e1' 
   
   
   新建兩個窗口，在5秒鐘內執行上面語句。不久就會出現死鎖提示。（結束後記住要把事務回滾啊） 
   
   
   
   知道死鎖產生的緣由，在生產環境產生的死鎖就相似這兩種狀況。 
   
   
   
   後來在網上查閱了不少資料，包括sql server 2005的幫助文檔。總結有如下有主要幾點： 
   
   1，下降隔離級別或者使用行版本控制隔離級別 
   
   2，提升數據的訪問速度 
   
   3，減小事務長度 
   
   4，將按順序訪問熱點表（如將訪問頻繁的表放在最後訪問） 
   
   
   
   遇到的困難 
   但在咱們此次優化中，有些是不太好處理的 如： 
   
   1，減小事務長度，事務的大小不是咱們來決定的，是由業務邏輯來決定的（來自tom的《Oracle 9i/10g深刻內部體系機構》中） 
   
   2，按順序訪問熱點表，咱們發現代碼中方法間互相調用很頻繁，常常一個表調用屢次，要修改表的訪問順序是比較困難的。