背景介紹：
知識理解：
事務回滾：在銀行給別人轉賬，但可能錢已經扣了，對方也沒有得到錢，自己肯定不樂意了，然後銀行就進行事務回滾，不儲存你剛才轉賬的操作，恢復到原來未轉賬的狀態。
步入正題：
我們的資料庫中是不允許死鎖發生的，死鎖會導致其中乙個事務的回滾，整個事務的提交失敗，而且死鎖還會占用大量的資源，使我們的系統執行起來會緩慢，所以要避免死鎖的發生。
一、死鎖的建立：
新建查詢sa（53）：
建立乙個事務t1，但是不提交。然後執行。
begin
tran
t1--
建立乙個事務更新表
update
online_info
setontime
=getdate()
系統會預設的在這個表中上乙個鎖，表示這個事務是未提交狀態。
新建查詢sa（54）：
然後再建立另乙個事務t2，也不進行提交。
begin
tran
t2--
建立另乙個事務更新表
update
line_info
setontime
=getdate()
這個也是，line_info 也被上了乙個鎖。
然後在sa（53）中：
更新line_info表然後執行。
update
line_info
setontime
=getdate()
此時會發現，系統會一直處於等待狀態，因為此時事務t2中的line_info表是鎖定的。所以，只有當t2事務提交或著回滾之後，資源被釋放出來，等待狀態才會結束。
現在讓t2事務中執行。讓t2事務爭奪online_info表中的資源。
update
online_info
setontime
=getdate()
執行成功後，我們在t1事務中，就可以看到。事務t1被作為死鎖的乙個犧牲品。所以t1整個事務就已經回滾了。
整體的效果：
事務t1是先訪問online_info表，然後再訪問line_info表。
事務t2是先訪問line_info表，然後在訪問online_info表。
由於這兩個事務訪問的順序不一致，導致出現了死鎖。
二、死鎖的監測
有兩種辦法。
方法一：
通過dbcc命令，將死鎖資訊記錄到我們的日誌中去。
執行命令後，在重複執行剛剛建立死鎖的步驟。就是先讓事務t2回滾（rollback）。也可以用commit（事務提交語句）提交事務（對應的語句看資料庫自考書）
dbcc traceon(1222,1204,3605,-1)
知識點積累：
3605-將dbcc的結果輸出到錯誤日誌1222 -返回參與死鎖的鎖的資源和型別，以及使用了不符合任何 xsd 架構的 xml 格式的受影響的當前命令
-1 以全域性方式開啟指定的跟蹤標記。
1204 返回參與死鎖的鎖的資源和型別，以及受影響的當前命令
/* 對於這個命令的理解，還有欠缺，等以後在解決，暫時儲備的知識還有限。*/
我們可以同過日誌檔案檢視器，來判斷在**個語句出現了錯誤。這裡面雖然有了乙個死鎖的日誌，但是這種方法不能很好的直接檢視死鎖產生的原因。
不如方法二好：
方法二：（設定死鎖的追蹤）
工具----sql sever profiler---事件選擇---顯示所有事件
deadlock graph這個是圖形化顯示死鎖。
再執行建立死鎖的操作，這樣就可以對發現死鎖的語句進行追蹤了。
同時這樣就可以看到到底是哪條語句出現了死鎖，然後就可以對這個語句進行修改了。 （錯誤的語句會顯示出來）
總結：
資料庫系列之死鎖（四）
概要 什麼是死鎖？死鎖是怎麼造成的？怎麼查詢？如何解決及避免？死鎖 deadlock，是指兩個或兩個以上的程序在執行過程中,因爭奪資源而造成的一種互相等待的現象,若無外 力作用,它們都將無法推進下去.此時稱系統處於死鎖狀態或系統產生了死鎖,這些永遠在互相等待的程序稱為死 鎖程序.阻塞 當來自應用程式...
oracle資料庫簡易故障排查之死鎖處理
有時候我們的儲存過程執行很久，從日誌又沒辦法確定這個儲存過程是否正常的情況下，如何確定是否存在問題呢。後面想了下日常執行一些儲存過程或者資料庫執行緩慢的時候除了收集awr報告和看日誌外，簡易的處理方法，總結如下 1 查詢資料庫中有哪些鎖 select t2.username,t2.sid,t2.se...
例項分析資料庫死鎖的產生
近日由於系統操作過程中會提示 事務 程序 id 54 與另乙個程序被死鎖在 鎖 資源上，並且已被選作死鎖犧牲品。請重新執行該事務。以前也出現過，但是無從下手，不知道該從 下手。朱總提示應該以出錯這條語句訪問到的表為中心查詢所有跟此表有關的sql語句，看有沒有可能造成死鎖。其實聽到這個提示，我腦子裡也...