sqlserver資料庫鎖定

⑴ sqlserver怎麼用sql查看具體那個表被鎖住了

查看被鎖表：
select request_session_id spid,OBJECT_NAME(resource_associated_entity_id) tableName
from sys.dm_tran_locks where resource_type='OBJECT'

--spid 鎖表進程
--tableName 被鎖表名

解鎖：

declare @spid int
Set @spid = 57 --鎖表進程
declare @sql varchar(1000)
set @sql='kill '+cast(@spid as varchar)
exec(@sql)

--查詢出死鎖的SPID
select blocked
from (select * from sysprocesses where blocked>0 ) a
where not exists(select * from (select * from sysprocesses where blocked>0 ) b
where a.blocked=spid)

--輸出引起死鎖的操作
DBCC INPUTBUFFER (@spid)
--查詢當前進程數

select count(-1) from sysprocesses
where dbid in (select dbid from sysdatabases where name like '%telcount%');

⑵ sqlserver資料庫ix是什麼鎖

ix是意向鎖。
意向鎖與其說是鎖，倒不如說更像一個指示器。在SQL
Server中，資源是有層次的，一個表中可以包含N個頁，而一個頁中可以包含N個行。當我們在某一個行中加了鎖時。可以理解成包含這個行的頁，和表的一部分已經被鎖定。當另一個查詢需要鎖定頁或是表時，再一行行去看這個頁和表中所包含的數據是否被鎖定就有點太痛苦了。因此SQL
Server鎖定一個粒度比較低的資源時，會在其父資源上加上意向鎖，告訴其他查詢這個資源的某一部分已經上鎖。比如，當我們更新一個表中的某一行時，其所在的頁和表都會獲得意向排他鎖，如圖所示。

⑶ sqlserver資料庫ix是什麼鎖

ix是意向鎖。

意向鎖與其說是鎖，倒不如說更像一個指示器。在SQL Server中，資源是有層次的，一個表中可以包含N個頁，而一個頁中可以包含N個行。當我們在某一個行中加了鎖時。可以理解成包含這個行的頁，和表的一部分已經被鎖定。當另一個查詢需要鎖定頁或是表時，再一行行去看這個頁和表中所包含的數據是否被鎖定就有點太痛苦了。因此SQL Server鎖定一個粒度比較低的資源時，會在其父資源上加上意向鎖，告訴其他查詢這個資源的某一部分已經上鎖。比如，當我們更新一個表中的某一行時，其所在的頁和表都會獲得意向排他鎖，如圖所示。

⑷ 如何解除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的作用是允許用戶先讀取數據（而且不阻塞其他用戶讀數據），並且保證在後來再更新數據時，這一段時間內這些數據沒有被其他用戶修改。

⑸ 如何設置SQLServer資料庫內存

如果能在實例級別為同一SQL伺服器上的不同實例限制其能夠使用的最大和最小內存，就能降低這種情況對啟洞其他應用系統的影響。具體的操作如下：

（一）實例的最大和最小內存設置

右擊資料庫，選擇屬性，如圖。

為實例設置合適的最大和最小內存，如圖。

（二）為操作系統預留足夠的內存

假如一台8GB的伺服器，我們可以限制資料庫使用的內存戚旁鏈上限不超過6GB，剩下的2GB留給操作系統使用。

（三）配置lockpagesinmemory

查看SQL進程的啟動賬戶，如圖。

在組策略里設置啟動SQLServer的賬戶擁有鎖定內存頁的許可權。如圖。

在下圖的添加用戶高孫或組界面，添加SQLserver的服務啟動賬戶，如圖。

⑹ SQLServer與Oracle數據鎖定的比較

資料庫並行訪問 也就是兩個或兩以上用戶同時訪問同一數據 這也是資料庫引擎如何設計和實現適度反應所面臨的最大問題 設計優良 性能卓越的資料庫引擎可以輕松地同時為成千上萬的正悄逗用戶服務 而 底氣不足 的資料庫系統隨著更多的用戶同時訪問系統將大大降低其性能 最糟糕的情況下甚至可能導致系統的崩潰

當然 並行訪問是任何資料庫解決方案都最為重視的問題了 為了解決並行訪問方面的問題各類資料庫系統提出了各種各樣的方案 SQL Server和Oracle兩大DBMS也分別採用了不同的並行處理方法 它們之間的實質差別在哪裡呢？

並行訪問的問題

並行訪問出現問題存在若干種情況 在最簡單的情形下 數量超過一個的用戶可能同時查詢同一數據 就這種情況而言資料庫的操作目標很簡單 盡可能地為用戶們提供快速的數據訪問 這對我們現在常見的資料庫來說不成問題 SQL Server和 Oracle 都採用了多線程機制 它們當然能夠一次處理多個請求

不過 在用戶修改數據的情況下並行訪問問題就變得復雜起來了 顯然 資料庫通常只允許唯一用戶一次修改特定的數據 當某一用戶開始修改某塊數據時 SQL Server和 Oracle 都能很快地鎖定數據 阻止其他用戶對這塊數據進行更新 直到修改該數據的第 位用戶完成其操作並提交交易（mit transaction） 但是 當某一位用戶正在修改某塊數據時假設另一位用戶又正想查詢該數據的信息時會發生什麼情況呢？在這種情況下資料庫管理系統又該如何動作呢？Oracle 和 SQL Server針對這一問題採取運頌了不同的解決方案

SQL Server方法

現在不妨假設有人開始修改SQL Server上存儲的數據 於是這塊數據立即被資料庫鎖定 數據鎖定操作阻塞其他任何訪問該數據的連接——連查詢操作都不會放過 於是 這塊被鎖定的數據只有在交易被提交或者回滾之後才能接受其他訪問操作

下面用SQL Server隨帶的pubs示例資料庫做一個簡單示範 在Query Analyzer內打開兩個窗口 在第 個窗口中執行下列SQL操作語句 更新pubs資料庫中某一圖書的價格

use pubs go begin tran update titles set price = price * where title_id = BU

由於代碼中並沒有執行mit語句 所以數據變動操作實際上還沒有最終完成 接下來 在另一個窗口裡執行下列語句查詢titles數據表

select title_id title price from titles 舉賣order by title_id

你什麼結果也得不到 窗口底部的小地球圖標會轉個不停 盡管我在先前的操作中僅僅更新了一行 但是 select語句的執行對象卻恰好包含了其數據正被修改的一行 因此 上面的操作不會返回任何數據 除非回到第 個窗口提交交易或者回滾

lishixin/Article/program/Oracle/201311/17702

⑺ 減少SQL Server資料庫死鎖的技巧

如果兩個用戶進程分別鎖定了不同的資源 接著又試圖鎖定對方所鎖定的資源 就會產生死鎖 此時 SQL Server將自動地選擇並中止其中一個進程以解除死鎖 使得另外一個進程能夠繼續處理 系統將回退被中止的事務 並向被回退事務的用戶發送錯誤信息 大多數設計良好的應用都會在接收到這個錯誤信息之後重新提交該事務 此時提交成功的可能性是很大的 但是 如果伺服器上經常出現這種情況 就會顯著地降低伺服器性能 為避免死鎖 設計應用應當遵循一定的原則 包括 ▲ 讓應用每次都以相同的次序訪問伺服器資源 ▲ 在事務期間禁止任何用戶輸入 應當在事務開始之前收集用戶輸入 ▲ 盡量保持事務的短小和簡單 ▲ 如合適的話 為運行事務的用戶連接指定盡可能低的隔離級別 [適用於 ]此外 對於SQL Server的死鎖問題 下面是幾則實踐中很有用的小技巧 ■ 使用SQL Server Profiler的Create Trace Wizard運行 Identify The Cause of a Deadlock 跟蹤來輔助識別死鎖問題 它將提供幫助查找資料庫產生死鎖原因的原始數據 [適用於 ]■ 如果無法消除應用中的所有死鎖 請確保提供了這樣一種程序邏輯 它能夠在死鎖出現並中止用戶事務之後 以隨機的時間間隔自動重新提交事務 這里等待時間的隨機性非大銷常重要 這是因為另一個競爭的事務也可能在等待 我們不應該讓兩個競爭的事務等待同樣的時間 然後再在同一時間執行它們 這樣的話將導致新的死鎖 [適用於 ]■ 盡可能地簡化所有T SQL事務 此舉將減少各種類型的鎖的數量 有助於提高SQL Server應用的整體性能 如果可能的話 應將較復雜的事務分割成多個較簡單的事務 [適用於 ]■ 所有條件邏輯 變數賦值以及其他相關的預備設置操作應當在事務之外完成 而不應該放到事務之內 永遠不要為了接受用戶輸入而暫停某個事務 用戶輸入應當總是在事務之外完成 [適用於 ]■ 在存儲過程內封裝所有事務 包括BEGIN TRANSACTION和MIT TRANSACTION語句 此舉從兩個方面幫助減少阻塞的鎖 首先 它限制了事務運行時客戶程序和SQL Server之間的通信 從而使得兩者之間的任何消息只能出現於非事務運行時間（減少了事務運行的時間） 其次 由於存儲過程強制它所啟動的事務或者完成 或者中止 從而防止了用戶留下未完成的事務（留下未撤銷的鎖） [適用於 ]■ 如果客戶程序需要先用一定的時間賀瞎檢查數據 然後可能更新數據 也可能不更新數據 那麼最好不要在整個記錄檢查期間都鎖定記錄 假設大部分時間都是檢查數據而不是更新數據 那麼處理這種特殊情況的一種方法就是 先選擇出記錄（不加UPDATE子句 UPDATE子句將在記錄上加上共享鎖） 然後把它發送給客戶 如果用戶只查看記錄但從來不更新它 程序可以什麼也不做 反過來 如果用戶決定更新某個記錄 那麼他可以通過一個WHERE子句檢查當前的數據是否和以前提取的數據相同 然後執行UPDATE 類似地 我們還可以檢查記錄中的時間標識列（如果它存在的話） 如果數據相滾拍游同 則執行UPDATE操作 如果記錄已經改變 則應用應該提示用戶以便用戶決定如何處理 雖然這種方法需要編寫更多的代碼 但它能夠減少加鎖時間和次數 提高應用的整體性能 [適用於 ]■ 盡可能地為用戶連接指定具有最少限制的事務隔離級別 而不是總是使用默認的READ MITTED 為了避免由此產生任何其他問題 應當參考不同隔離級別將產生的效果 仔細地分析事務的特性 [適用於 ] ■ 使用游標會降低並發性 為避免這一點 如果可以使用只讀的游標則應該使用READ_ONLY游標選項 否則如果需要進行更新 嘗試使用OPTIMISTIC游標選項以減少加鎖 設法避免使用SCROLL_LOCKS游標選項 該選項會增加由於記錄鎖定引起的問題 [適用於 ]■ 如果用戶抱怨說他們不得不等待系統完成事務 則應當檢查伺服器上的資源鎖定是否是導致該問題的原因 進行此類檢查時可以使用SQL Server Locks Object: Average Wait Time (ms) 用該計數器來度量各種鎖的平均等待時間 如果可以確定一種或幾種類型的鎖導致了事務延遲 就可以進一步探究是否可以確定具體是哪個事務產生了這種鎖 Profiler是進行這類具體分析的最好工具 [適用於 ]■ 使用sp_who和sp_who （SQL Server Books Online沒有關於sp_who 的說明 但sp_who 提供了比sp_who更詳細的信息）來確定可能是哪些用戶阻塞了其他用戶 [適用於 ]■ 試試下面的一個或多個有助於避免阻塞鎖的建議 ）對於頻繁使用的表使用集簇化的索引 ）設法避免一次性影響大量記錄的T SQL語句 特別是INSERT和UPDATE語句 ）設法讓UPDATE和DELETE語句使用索引 ）使用嵌套事務時 避免提交和回退沖突 [適用於 ] lishixin/Article/program/SQLServer/201311/22222

⑻ 關於Sqlserver資料庫 鎖機制的小疑問，下種情況是否需要加入鎖機制

不需要，就算確實用戶同時執行，資料庫的操作機制是有隊列的，所以不存在並發情況。
鎖基本用不到，我反正開發了5年了沒用到過。
你要了解死鎖發生的情況，一般是用事務的時候可能會碰到死鎖，你申請了A資源，鎖住了A然後申請B資源，其他人申請了B資源，然後申請A，這樣就互不相讓，導致A,B資源都不可訪問了，不過其他數據我不知道，SQLSERVER發生這種死鎖不是一直鎖死的，過幾分鍾就會發現這個死鎖，把鎖釋放掉，2個事務都失敗。

⑼ sqlserver怎麼實現一個行鎖

1如何鎖一個表的某一行


SELECT*FROMtableROWLOCKWHEREid=1

2鎖定資料庫的一個表

SELECT*FROMtableWITH(HOLDLOCK)

加鎖語句：
sybase:
update表setcol1=col1where1=0;
MSSQL:
selectcol1from表(tablockx)where1=0;
oracle:
LOCKTABLE表INEXCLUSIVEMODE；
加鎖後其它人不可操作，直到加鎖用戶解鎖，用commit或rollback解鎖