如何批量殺死sqlserver死鎖

如何批量殺死sqlserver死鎖

創新互聯公司專注于赫章網站建設服務及定制，我們擁有豐富的企業做網站經驗。 熱誠為您提供赫章營銷型網站建設，赫章網站制作、赫章網頁設計、赫章網站官網定制、成都小程序開發服務，打造赫章網絡公司原創品牌,更為您提供赫章網站排名全網營銷落地服務。

使用sp_lock可以查看鎖的信息， 使用kill 可以把產生鎖的聯接刪除。 產生鎖，一般是開發過程的處理有問題。 還有就是增加關鍵字或是索引，減小鎖的粒度。

怎樣徹底刪除掉sqlserver

卸載SQL Server 2008 R2

1。首先在控制面板里卸載sqlserver和相關的依賴項。

2。然后重啟電腦，以防有些組件駐留內存無法刪除。

3。使用Windows Install Clean Up 工具清理其他垃圾

4。刪除C:\Program?Files\Microsoft?SQL?Server下的工作目錄。

5。刪除C:\Program?Files?(x86)\Microsoft?SQL?Server下的工作目錄。

6。打開注冊表編輯器(開始→運行→regedit→確定)

然后找到下面的文件夾，刪除掉：

6.1。HKEY_CURRENT_USER\Software\Microsoft\Microsoft SQL Server

6.2。HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server和

Microsoft SQL Server開頭的一并刪除

7。清理其他包含Microsoft?SQL?Server的目錄。如

8。如果不能正常安裝SQL Server的話，請盡量重新安裝系統。這是代價最小的方法。

如何徹底刪除sqlserver

1、 用360軟件管家或者控制面板先將SQL Server卸載。

2 、開始--運行--輸入指令“regedit”，打開注冊表編輯器。

3、 然后依次按下面的目錄，將指定文件刪除掉：

HKEY_CURRENT_USER\Software\Microsoft\Microsoft SQL Server;

HKEY_CURRENT_USER\Software\Microsoft\MSSQLServer.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server;

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSDTC;

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer;

4 、最后我們的目標是把所有跟SQL有關的文件夾全部刪掉，然后當重啟電腦的時候，會發現該刪除的都刪除掉了。

5 當然，這個時候，可能C盤目錄下C:\Program Files\Microsoft SQL Server可能還沒有完全刪除，這時再手動刪除，就可以刪掉了。（在清除注冊表信息之前，這個是刪不掉的，它會不停的提示你有文件夾沒有關閉，重啟之后就可以刪掉了。）

sqlserver怎么清除死鎖

查詢語句的表名后加(nolock)少用臨時表和group by HAVING。

這是與檢測死鎖相配套的一種措施。

當檢測到系統中已發生死鎖時，須將進程從死鎖狀態中解脫出來。

常用的實施方法是撤銷或掛起一些進程，以便回收一些資源，再將這些資源分配給已處于阻塞狀態的進程，使之轉為就緒狀態，以繼續運行。

死鎖的檢測和解除措施，有可能使系統獲得較好的資源利用率和吞吐量，但在實現上難度也最大。

如何解除sql server數據庫數據被鎖定

(1)

HOLDLOCK:

在該表上保持共享鎖，直到整個事務結束，而不是在語句執行完立即釋放所添加的鎖。

(2)

NOLOCK：不添加共享鎖和排它鎖，當這個選項生效后，可能讀到未提交讀的數據或“臟數據”，這個選項僅僅應用于SELECT語句。

(3)

PAGLOCK：指定添加頁鎖（否則通常可能添加表鎖）。

(4)

READCOMMITTED用與運行在提交讀隔離級別的事務相同的鎖語義執行掃描。默認情況下，SQL

Server

2000

在此隔離級別上操作。

(5)

READPAST:

跳過已經加鎖的數據行，這個選項將使事務讀取數據時跳過那些已經被其他事務鎖定的數據行，而不是阻塞直到其他事務釋放鎖，

READPAST僅僅應用于READ

COMMITTED隔離性級別下事務操作中的SELECT語句操作。

(6)

READUNCOMMITTED：等同于NOLOCK。

(7)

REPEATABLEREAD：設置事務為可重復讀隔離性級別。

(8)

ROWLOCK：使用行級鎖，而不使用粒度更粗的頁級鎖和表級鎖。

(9)

SERIALIZABLE：用與運行在可串行讀隔離級別的事務相同的鎖語義執行掃描。等同于

HOLDLOCK。

(10)

TABLOCK：指定使用表級鎖，而不是使用行級或頁面級的鎖，SQL

Server在該語句執行完后釋放這個鎖，而如果同時指定了...(1)

HOLDLOCK:

在該表上保持共享鎖，直到整個事務結束，而不是在語句執行完立即釋放所添加的鎖。

(2)

NOLOCK：不添加共享鎖和排它鎖，當這個選項生效后，可能讀到未提交讀的數據或“臟數據”，這個選項僅僅應用于SELECT語句。

(3)

PAGLOCK：指定添加頁鎖（否則通常可能添加表鎖）。

(4)

READCOMMITTED用與運行在提交讀隔離級別的事務相同的鎖語義執行掃描。默認情況下，SQL

Server

2000

在此隔離級別上操作。

(5)

READPAST:

跳過已經加鎖的數據行，這個選項將使事務讀取數據時跳過那些已經被其他事務鎖定的數據行，而不是阻塞直到其他事務釋放鎖，

READPAST僅僅應用于READ

COMMITTED隔離性級別下事務操作中的SELECT語句操作。

(6)

READUNCOMMITTED：等同于NOLOCK。

(7)

REPEATABLEREAD：設置事務為可重復讀隔離性級別。

(8)

ROWLOCK：使用行級鎖，而不使用粒度更粗的頁級鎖和表級鎖。

(9)

SERIALIZABLE：用與運行在可串行讀隔離級別的事務相同的鎖語義執行掃描。等同于

HOLDLOCK。

(10)

TABLOCK：指定使用表級鎖，而不是使用行級或頁面級的鎖，SQL

Server在該語句執行完后釋放這個鎖，而如果同時指定了HOLDLOCK，該鎖一直保持到這個事務結束。

(11)

TABLOCKX：指定在表上使用排它鎖，這個鎖可以阻止其他事務讀或更新這個表的數據，直到這個語句或整個事務結束。

(12)

UPDLOCK

：指定在

讀表中數據時設置更新

鎖（update

lock）而不是設置共享鎖，該鎖一直保持到這個語句或整個事務結束，使用UPDLOCK的作用是允許用戶先讀取數據（而且不阻塞其他用戶讀數據），并且保證在后來再更新數據時，這一段時間內這些數據沒有被其他用戶修改。

如何處理SQL Server死鎖問題

死鎖，簡而言之，兩個或者多個trans，同時請求對方正在請求的某個對象，導致雙方互相等待。簡單的例子如下：

trans1 trans2

------------------------------------------------------------------------

1.IDBConnection.BeginTransaction 1.IDBConnection.BeginTransaction

2.update table A 2.update table B

3.update table B 3.update table A

4.IDBConnection.Commit 4.IDBConnection.Commit

那么，很容易看到，如果trans1和trans2，分別到達了step3，那么trans1會請求對于B的X鎖，trans2會請求對于A的X鎖，而二者的鎖在step2上已經被對方分別持有了。由于得不到鎖，后面的Commit無法執行，這樣雙方開始死鎖。

好，我們看一個簡單的例子，來解釋一下，應該如何解決死鎖問題。

-- Batch #1

CREATE DATABASE deadlocktest

GO

USE deadlocktest

SET NOCOUNT ON

DBCC TRACEON (1222, -1)

-- 在SQL2005中，增加了一個新的dbcc參數，就是1222，原來在2000下，我們知道，可以執行dbcc

--traceon(1204,3605,-1)看到所有的死鎖信息。SqlServer 2005中，對于1204進行了增強，這就是1222。

GO

IF OBJECT_ID ('t1') IS NOT NULL DROP TABLE t1

IF OBJECT_ID ('p1') IS NOT NULL DROP PROC p1

IF OBJECT_ID ('p2') IS NOT NULL DROP PROC p2

GO

CREATE TABLE t1 (c1 int, c2 int, c3 int, c4 char(5000))

GO

DECLARE @x int

SET @x = 1

WHILE (@x = 1000) BEGIN

INSERT INTO t1 VALUES (@x*2, @x*2, @x*2, @x*2)

SET @x = @x + 1

END

GO

CREATE CLUSTERED INDEX cidx ON t1 (c1)

CREATE NONCLUSTERED INDEX idx1 ON t1 (c2)

GO

CREATE PROC p1 @p1 int AS SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1

GO

CREATE PROC p2 @p1 int AS

UPDATE t1 SET c2 = c2+1 WHERE c1 = @p1

UPDATE t1 SET c2 = c2-1 WHERE c1 = @p1

GO

上述sql創建一個deadlock的示范數據庫，插入了1000條數據，并在表t1上建立了c1列的聚集索引，和c2列的非聚集索引。另外創建了兩個sp，分別是從t1中select數據和update數據。

好，打開一個新的查詢窗口，我們開始執行下面的query：

-- Batch #2

USE deadlocktest

SET NOCOUNT ON

WHILE (1=1) EXEC p2 4

GO

開始執行后，然后我們打開第三個查詢窗口，執行下面的query：

-- Batch #3

USE deadlocktest

SET NOCOUNT ON

CREATE TABLE #t1 (c2 int, c3 int)

GO

WHILE (1=1) BEGIN

INSERT INTO #t1 EXEC p1 4

TRUNCATE TABLE #t1

END

GO

開始執行，哈哈，很快，我們看到了這樣的錯誤信息：

Msg 1205, Level 13, State 51, Procedure p1, Line 4

Transaction (Process ID 54) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

spid54發現了死鎖。

那么，我們該如何解決它？

在SqlServer 2005中，我們可以這么做：

1.在trans3的窗口中，選擇EXEC p1 4，然后right click，看到了菜單了嗎？選擇Analyse Query in Database Engine Tuning Advisor。

2.注意右面的窗口中，wordload有三個選擇：負載文件、表、查詢語句，因為我們選擇了查詢語句的方式，所以就不需要修改這個radio option了。

3.點左上角的Start Analysis按鈕

4.抽根煙，回來后看結果吧！出現了一個分析結果窗口，其中，在Index Recommendations中，我們發現了一條信息：大意是，在表t1上增加一個非聚集索引索引：t2+t1。

5.在當前窗口的上方菜單上，選擇Action菜單，選擇Apply Recommendations，系統會自動創建這個索引。

重新運行batch #3，呵呵，死鎖沒有了。

這種方式，我們可以解決大部分的Sql Server死鎖問題。那么，發生這個死鎖的根本原因是什么呢？為什么增加一個non clustered index，問題就解決了呢？ 這次，我們分析一下，為什么會死鎖呢？再回顧一下兩個sp的寫法：

CREATE PROC p1 @p1 int AS

SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1

GO

CREATE PROC p2 @p1 int AS

UPDATE t1 SET c2 = c2+1 WHERE c1 = @p1

UPDATE t1 SET c2 = c2-1 WHERE c1 = @p1

GO

很奇怪吧！p1沒有insert，沒有delete，沒有update，只是一個select，p2才是update。這個和我們前面說過的，trans1里面updata A，update B；trans2里面upate B，update A，根本不貼邊??！

那么，什么導致了死鎖？

需要從事件日志中，看sql的死鎖信息：

Spid X is running this query (line 2 of proc [p1], inputbuffer “… EXEC p1 4 …”):

SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1

Spid Y is running this query (line 2 of proc [p2], inputbuffer “EXEC p2 4”):

UPDATE t1 SET c2 = c2+1 WHERE c1 = @p1

The SELECT is waiting for a Shared KEY lock on index t1.cidx. The UPDATE holds a conflicting X lock.

The UPDATE is waiting for an eXclusive KEY lock on index t1.idx1. The SELECT holds a conflicting S lock.

首先，我們看看p1的執行計劃。怎么看呢？可以執行set statistics profile on，這句就可以了。下面是p1的執行計劃

SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1

|--Nested Loops(Inner Join, OUTER REFERENCES:([Uniq1002], [t1].[c1]))

|--Index Seek(OBJECT:([t1].[idx1]), SEEK:([t1].[c2] = [@p1] AND [t1].[c2] = [@p1]+(1)) ORDERED FORWARD)

|--Clustered Index Seek(OBJECT:([t1].[cidx]), SEEK:([t1].[c1]=[t1].[c1] AND [Uniq1002]=[Uniq1002]) LOOKUP ORDERED FORWARD)

我們看到了一個nested loops，第一行，利用索引t1.c2來進行seek，seek出來的那個rowid，在第二行中，用來通過聚集索引來查找整行的數據。這是什么？就是bookmark lookup?。槭裁?？因為我們需要的c2、c3不能完全的被索引t1.c1帶出來，所以需要書簽查找。

好，我們接著看p2的執行計劃。

UPDATE t1 SET c2 = c2+1 WHERE c1 = @p1

|--Clustered Index Update(OBJECT:([t1].[cidx]), OBJECT:([t1].[idx1]), SET:([t1].[c2] = [Expr1004]))

|--Compute Scalar(DEFINE:([Expr1013]=[Expr1013]))

|--Compute Scalar(DEFINE:([Expr1004]=[t1].[c2]+(1), [Expr1013]=CASE WHEN CASE WHEN ...

|--Top(ROWCOUNT est 0)

|--Clustered Index Seek(OBJECT:([t1].[cidx]), SEEK:([t1].[c1]=[@p1]) ORDERED FORWARD)

通過聚集索引的seek找到了一行，然后開始更新。這里注意的是，update的時候，它會申請一個針對clustered index的X鎖的。

實際上到這里，我們就明白了為什么update會對select產生死鎖。update的時候，會申請一個針對clustered index的X鎖，這樣就阻塞住了（注意，不是死鎖?。﹕elect里面最后的那個clustered index seek。死鎖的另一半在哪里呢？注意我們的select語句，c2存在于索引idx1中，c1是一個聚集索引cidx。問題就在這里！我們在p2中更新了c2這個值，所以sqlserver會自動更新包含c2列的非聚集索引：idx1。而idx1在哪里？就在我們剛才的select語句中。而對這個索引列的更改，意味著索引集合的某個行或者某些行，需要重新排列，而重新排列，需要一個X鎖。

SO………，問題就這樣被發現了。

總結一下，就是說，某個query使用非聚集索引來select數據，那么它會在非聚集索引上持有一個S鎖。當有一些select的列不在該索引上，它需要根據rowid找到對應的聚集索引的那行，然后找到其他數據。而此時，第二個的查詢中，update正在聚集索引上忙乎：定位、加鎖、修改等。但因為正在修改的某個列，是另外一個非聚集索引的某個列，所以此時，它需要同時更改那個非聚集索引的信息，這就需要在那個非聚集索引上，加第二個X鎖。select開始等待update的X鎖，update開始等待select的S鎖，死鎖，就這樣發生鳥。

那么，為什么我們增加了一個非聚集索引，死鎖就消失鳥？我們看一下，按照上文中自動增加的索引之后的執行計劃：

SELECT c2, c3 FROM t1 WHERE c2 BETWEEN @p1 AND @p1+1

|--Index Seek(OBJECT:([deadlocktest].[dbo].[t1].[_dta_index_t1_7_2073058421__K2_K1_3]), SEEK:([deadlocktest].[dbo].[t1].[c2] = [@p1] AND [deadlocktest].[dbo].[t1].[c2] = [@p1]+(1)) ORDERED FORWARD)

哦，對于clustered index的需求沒有了，因為增加的覆蓋索引已經足夠把所有的信息都select出來。就這么簡單。

實際上，在sqlserver 2005中，如果用profiler來抓eventid：1222，那么會出現一個死鎖的圖，很直觀的說。

下面的方法，有助于將死鎖減至最少（詳細情況，請看SQLServer聯機幫助，搜索：將死鎖減至最少即可。

按同一順序訪問對象。

避免事務中的用戶交互。

保持事務簡短并處于一個批處理中。

使用較低的隔離級別。

使用基于行版本控制的隔離級別。

將 READ_COMMITTED_SNAPSHOT 數據庫選項設置為 ON，使得已提交讀事務使用行版本控制。

使用快照隔離。

使用綁定連接。