Ⅰ 請問sql事務鎖如何使用
資料庫中的鎖是指一種軟體機制，用來指示某個用戶（也即進程會話，下同）已經佔用了某種資源，從而防止其他用戶做出影響本用戶的數據修改或導致資料庫數據的非完整性和非一致性。
能夠鎖定的資源粒度包括：資料庫、表、區域、頁面、鍵值（指帶有索引的行數據）、行標識符（RID，即表中的單行數據）
所指定的鎖類型有如下幾種：
1．HOLDLOCK: 在該表上保持共享鎖，直到整個事務結束，而不是在語句執行完立即釋放所添加的鎖。
2．NOLOCK：不添加共享鎖和排它鎖，當這個選項生效後，可能讀到未提交讀的數據或「臟數據」，這個選項僅僅應用於SELECT語句。
3．PAGLOCK：指定添加頁面鎖（否則通常可能添加表鎖）。
4．READCOMMITTED：設置事務為讀提交隔離性級別。
5．READPAST: 跳過已經加鎖的數據行，這個選項將使事務讀取數據時跳過那些已經被其他事務鎖定的數據行，而不是阻塞直到其他事務釋放鎖，READPAST僅僅應用於READ COMMITTED隔離性級別下事務操作中的SELECT語句操作。
Ⅱ 如果一條sql被鎖住怎麼看它是被哪個線程鎖住
您好！鎖是資料庫中的一個非常重要的概念，它主要用於多用戶環境下保證資料庫完整性和一致性。
我們知道，多個用戶能夠同時操縱同一個資料庫中的數據，會發生數據不一致現象。即如果沒有鎖定且多個用戶同時訪問一個資料庫，則當他們的事務同時使用相同的數據時可能會發生問題。這些問題包括：丟失更新、臟讀、不可重復讀和幻覺讀。資料庫加鎖就是為了解決以上的問題。
當然，加鎖固然好，但是一定要避免死鎖的出現。
在資料庫系統中，死鎖是指多個用戶（進程）分別鎖定了一個資源，並又試圖請求鎖定對方已經鎖定的資源，這就產生了一個鎖定請求環，導致多個用戶（進程）都處於等待對方釋放所鎖定資源的狀態。這種死鎖是最典型的死鎖形式, 例如在同一時間內有兩個事務A和B，事務A有兩個操作：鎖定表part和請求訪問表supplier；事務B也有兩個操作：鎖定表supplier和請求訪問表part。結果，事務A和事務B之間發生了死鎖。死鎖的第二種情況是，當在一個資料庫中時，有若干個長時間運行的事務執行並行的操作，當查詢分析器處理一種非常復雜的查詢例如連接查詢時，那麼由於不能控制處理的順序，有可能發生死鎖現象。
在應用程序中就可以採用下面的一些方法來盡量避免死鎖了： （1）合理安排表訪問順序。 （2）在事務中盡量避免用戶干預，盡量使一個事務處理的任務少些, 保持事務簡短並在一個批處理中。 （3）數據訪問時域離散法, 數據訪問時域離散法是指在客戶機/伺服器結構中，採取各種控制手段控制對資料庫或資料庫中的對象訪問時間段。主要通過以下方式實現: 合理安排後台事務的執行時間，採用工作流對後台事務進行統一管理。工作流在管理任務時，一方面限制同一類任務的線程數（往往限制為1個），防止資源過多佔用; 另一方面合理安排不同任務執行時序、時間，盡量避免多個後台任務同時執行，另外， 避免在前台交易高峰時間運行後台任務。 （4）數據存儲空間離散法。數據存儲空間離散法是指採取各種手段，將邏輯上在一個表中的數據分散到若干離散的空間上去，以便改善對表的訪問性能。主要通過以下方法實現: 第一，將大表按行或列分解為若干小表; 第二，按不同的用戶群分解。 （5）使用盡可能低的隔離性級別。隔離性級別是指為保證資料庫數據的完整性和一致性而使多用戶事務隔離的程度，SQL92定義了4種隔離性級別：未提交讀、提交讀、可重復讀和可串列。如果選擇過高的隔離性級別，如可串列，雖然系統可以因實現更好隔離性而更大程度上保證數據的完整性和一致性，但各事務間沖突而死鎖的機會大大增加，大大影響了系統性能。 （6）使用綁定連接, 綁定連接允許兩個或多個事務連接共享事務和鎖，而且任何一個事務連接要申請鎖如同另外一個事務要申請鎖一樣，因此可以允許這些事務共享數據而不會有加鎖的沖突。
總之，了解SQL Server的鎖機制，掌握資料庫鎖定方法, 對一個合格的DBA來說是很重要的。
Ⅲ 如何解除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的鎖的問題
有沒有辦法讓B進程的select返回A進程的事務修改前的數據版本而不等待？
這樣是有問題的，會造成所謂的臟讀，也就是讀到的信息是錯誤的。
所以SQL在設計的時候，遇到這樣的鎖，要麼跳過去，要麼等待鎖釋放讀到正確的信息
Ⅳ sql server死鎖了怎麼辦
死鎖是這樣形成的，假設有兩個事物A和B
A事物在執行中需要更新兩個表，假設為T1，T2，此時A已執行完T1，正在申請使用T2.
B事物也需要更新這兩個表，但B事物先執行了T2,正在申請使用T1，
因為T1已被A事物鎖定，所以B必須等待A事物執行完後釋放鎖，但A事物此時正在申請T2，而T2確被B事物先鎖定了，需等待B事物完成後釋放鎖後才可獲得T2的鎖，此時死鎖就發生了，如果沒有死鎖機制，這兩個事物就會一直等下去。
sql server會定期檢查死鎖，如果發現死鎖，就會權衡兩個事物，犧牲掉其中一個執行代價較小的事物，使另一個事物能繼續執行。
要避免死鎖的發生，有很多需要注意的，如
1.保持事物盡可能的簡短。
2。事物更新的順序盡量一致，如上例中A和B如果更新順序都為T1，T2或T2，T1的話就不會發生死鎖了。
3.可以修改鎖的粒度，如頁鎖改為行鎖
Ⅵ SQL事務與鎖
如果有beginTrans和submitTrans，那麼鎖定從beginTrans開始，到submitTrans結束；否則，sqlserver將自動判定。
Ⅶ sql 事務死鎖
解鎖唄
USE [master]
DECLARE @cmdKill VARCHAR(50)
DECLARE killCursor CURSOR FOR
SELECT 'KILL ' + Convert(VARCHAR(5), p.spid)
FROM master.dbo.sysprocesses AS p
WHERE p.dbid = db_id('auth_ldjt')
OPEN killCursor
FETCH killCursor INTO @cmdKill
WHILE 0 = @@fetch_status
BEGIN
EXECUTE (@cmdKill)
FETCH killCursor INTO @cmdKill
END
CLOSE killCursor
DEALLOCATE killCursor
Ⅷ 事務發生死鎖時,資料庫引擎是如何處理的
如果在某個事務中的某個鎖或者某些鎖沒有正常釋放時，就會發生死鎖。很常見的一種情況是在一個事務中的某個SQL語句發生了錯誤而導致程序沒有正常結束，所以沒有執行到出錯代碼段後面的commit或者rollback時，這個事務中的鎖就不會被釋放，從而造成事務的死鎖。死鎖的現象很明顯的就是在執行SQL語句資料庫會一直執行而沒有響應。
Ⅸ sql死鎖怎麼解決，幫幫忙！
這個以前是在網上看到的你可以試試
運行時錯誤：-2147217900(80040e14)
SqlDumpExceptionHandler:進程53發生嚴重的異常c0000005 EXCEPTION_ACCESS_VIOLATION.SQL Server將終止進程
運行時錯誤 -2147467259(80004005)
事務（進程ID 63）與另一個進程已被鎖在 LOCK 資源上，且該事務已被選作死鎖犧牲品。請重新運行該事物
1. 用下面的語句檢查表是否有問題, 如果有, 按檢查的結果提示修復
use 你的庫名
dbcc checktable('vw_T_Dept')
2. 重建索引
dbcc dbreindex('vw_T_Dept')
Ⅹ SQL Server表鎖定原理以及如何解除鎖定
1. 資料庫表鎖定原理
1.1 目前的C/S,B/S結構都是多用戶訪問資料庫,每個時間點會有成千上萬個user來訪問DB,其中也會同時存取同一份數據,會造成數據的不一致性或者讀臟數據.
SELECT
request_session_idasSpid,
Coalesce(s.name+'.'+o.name+isnull('.'+i.name,''),
s2.name+'.'+o2.name,
db.name)ASObject,
l.resource_typeasType,
request_modeasMode,
request_statusasStatus
FROMsys.dm_tran_locksl
LEFTJOINsys.partitionsp
ONl.resource_associated_entity_id=p.hobt_id
LEFTJOINsys.indexesi
ONp.object_id=i.object_id
ANDp.index_id=i.index_id
LEFTJOINsys.objectso
ONp.object_id=o.object_id
LEFTJOINsys.schemass
ONo.schema_id=s.schema_id
LEFTJOINsys.objectso2
ONl.resource_associated_entity_id=o2.object_id
LEFTJOINsys.schemass2
ONo2.schema_id=s2.schema_id
LEFTJOINsys.databasesdb
ONl.resource_database_id=db.database_id
WHEREresource_database_id=DB_ID()
ORDERBYSpid,Object,CASEl.resource_type
When'database'Then1
when'object'then2
when'page'then3
when'key'then4
Else5end