⑴ 怎麼能查到造成鎖等待的sql語句
sql server：
Select * from sysprocesses where blocked<>0
--找到SPID
exec sp_lock
--根據SPID找到OBJID
select object_name(85575343)
--根據OBJID找到表名
Oracle：
SELECT P.SPID,
A.SERIAL#,
C.OBJECT_NAME,
B.SESSION_ID,
B.ORACLE_USERNAME,
B.OS_USER_NAME
FROM V$PROCESS P,
V$SESSION A,
V$LOCKED_OBJECT B,
ALL_OBJECTS C
WHERE P.ADDR = A.PADDR
AND A.PROCESS = B.PROCESS
AND C.OBJECT_ID = B.OBJECT_ID;
⑵ SQL更新語句執行很久都不行,語法沒錯
查詢一下，是否有死鎖的情況，
這個表被鎖了，或者 這部分數據頁面 被鎖了。
就是別人在 修改這個數據或者這個表的其他數據，一直沒有提交啊什麼的。
導致你的修改一直在等待。
⑶ plsql,做update操作,沒有submit,表一直被鎖3個小時,請問有沒有辦法在鎖一定時間後自動釋放鎖
Oracle 11g has a problem that is session timeout problem. You can add a row to sqlnet.ora file and listener.ora file to resolve session timeout problem.
sqlnet.ora
Note : Add this line to below of sqlnet.ora file.
INBOUND_CONNECT_TIMEOUT=3600
listener.ora
Note : Add this line to below of listener.ora file.
INBOUND_CONNECT_TIMEOUT_LISTENER=2400
基本上這樣可以解決session超時就會被kill掉
⑷ 當你在更新某條數據時，怎麼用SQL語句鎖定而不讓別人同時更新 請知道的說下。 謝謝了
你更新的時候，你更新的數據上本身就加了排他鎖的，在你更新的這段時間其他人無法再修改數據。或者還有別的操作後再釋放這些數據的話可以用事務。
⑸ sql server里update時，是行鎖還是表鎖問題
看錶結構,如果沒有主鍵無法只鎖定行
如果要驗證的話,只需要類似下面的方法就行了:
--開事務,以保持鎖
BEGINTRAN
--更新
updatetablea
setcolumn1=1
whereidx=1
--列出鎖信息
EXECsp_lock@@spid
--提交或者回滾事務
COMMIT/ROLLBACKTRAN
輸出的結果大致是這樣:
通過dbid,ObjId可以找到你更新的表相關的鎖記錄
如果IndId為0,表示鎖在表上,否則在對應的索引上
通過Type列,可以確定被鎖定的是行/表,或者是其他,並且可以通過Mode看到是什麼鎖
在Status中,還可以看到鎖是已經加上了,還是在等待其他資源釋放(以取得加鎖的權利)
-------------------------------------------------------------------------
53111151510180TABISGRANT
鎖的類型(Tyep列值,RID和KEY的話,表示鎖在行上)有如下幾種：
RID=表中單個行的鎖，由行標識符(RID)標識。
KEY=索引內保護可串列事務中一系列鍵的鎖。
PAG=數據頁或索引頁的鎖。
EXT=對某區的鎖。
TAB=整個表（包括所有數據和索引）的鎖。
DB=資料庫的鎖。
FIL=資料庫文件的鎖。
APP=指定的應用程序資源的鎖。
MD=元數據或目錄信息的鎖。
HBT=堆或B樹索引的鎖。在SQLServer2005中此信息不完整。
AU=分配單元的鎖。在SQLServer2005中此信息不完整。
⑹ SQL SERVER 數據是不是查詢時用數據鎖那更新(update)可以帶鎖嗎
處理多用戶並發訪問的方法是加鎖。鎖是防止其他事務訪問指定的資源控制、實現並發控制的一種主要手段。行是可以鎖定的最小空間, 行級鎖佔用的數據資源最少，所以在事務的處理過程中，允許其他事務繼續操縱同一個表或者同一個頁的其他數據，大大降低了其他事務等待處理的時間，提高了系統的並發性。為了使鎖定的成本減至最少，SQL Server 自動將資源鎖定在適合任務的級別。鎖定在較小的粒度（例如行）可以增加並發但需要較大的開銷，因為如果鎖定了許多行，則需要控制更多的鎖。
行級鎖是一種最優鎖，因為行級鎖不可能出現數據既被佔用又沒有使用的浪費現象。但是，如果用戶事務中頻繁對某個表中的多條記錄操作，將導致對該表的許多記錄行都加上了行級鎖，資料庫系統中鎖的數目會急劇增加，這樣就加重了系統負荷，影響系統性能。因此，在SQL Server中，還支持鎖升級(lock escalation)。所謂鎖升級是指調整鎖的粒度，將多個低粒度的鎖替換成少數的更高粒度的鎖，以此來降低系統負荷。在SQL Server中當一個事務中的鎖較多，達到鎖升級門限時，系統自動將行級鎖和頁面鎖升級為表級鎖。特別值得注意的是，在SQL Server中，鎖的升級門限以及鎖升級是由系統自動來確定的，不需要用戶設置。
網上找的，不知道能不能幫到你。原文的鏈接是：http://soft.zdnet.com.cn/techupdate/2007/0824/467522.shtml
⑺ 在資料庫（MS-SQL)中，UPDATE的用法，UPDATE表示用(NOLOCK)與不用（NOLOCK）的區別
NOLOCK是指在多用戶存取資料庫時別的用戶是否對某一紀錄或表加鎖,如果加鎖了,就不更新,等鎖被釋放後再更新.避免數據的"臟讀".
http://blog.csdn.net/riyao/article/details/8113372
⑻ 如何解決 SQL Server 中的鎖升級所致的阻塞問題
防止鎖升級的最簡單和最安全方法是使短的事務，以便不超過鎖升級閾值，會減少昂貴查詢的鎖定佔地面積。有多種方法可以獲得這一目標，其中許多將列出：
拆分成幾個較小的操作大的批處理操作。例如，假設您運行下面的查詢從審核表中，刪除幾個幾十萬舊記錄並隨後發現它導致阻塞其他用戶的鎖升級：
DELETE FROM LogMessages WHERE LogDate < '2/1/2002'
通過一次刪除這些記錄幾百，可以極大地減少積累每個交易記錄，並防止鎖升級的鎖數。例如：
SET ROWCOUNT 500
delete_more:
DELETE FROM LogMessages WHERE LogDate < '2/1/2002'
IF @@ROWCOUNT > 0 GOTO delete_more
SET ROWCOUNT 0
使查詢盡可能高效，從而減少查詢的鎖的佔地面積。大范圍的搜索或大量的書簽查找可能會增加鎖升級 ； 的機會此外，它增加了死鎖的可能性，並通常會影響並發性和性能。查找查詢後，會導致鎖升級，力圖尋找銷售機會，以創建新的索引，或者若要將列添加到現有索引刪除索引和表掃描和索引的效率的最大化。請考慮將查詢粘貼到查詢分析器的查詢窗口以在其上執行自動索引分析。為此，請在查詢菜單上，單擊在 SQL Server 2000 中，索引優化向導，或單擊執行索引分析SQL Server 7.0 中。
這種優化的目標之一是使索引搜索返回盡可能少的行，以書簽查找 （最大化的選擇性的特定查詢的索引） 的成本降到最低。如果 SQL Server 估計書簽查找邏輯運算符可能會返回多個行，它可能使用的預取來書簽查找。如果 SQL Server 不會使用書簽查找預取，必須增加對該查詢的一部分可重復的讀取查詢的一部分的事務隔離級別。這意味著什麼可能看起來類似於在讀取已提交的隔離級別的 SELECT 語句可能會獲取數以千計的鍵鎖 （聚集的索引和上一個非聚集的索引），這可能會導致此類查詢超過鎖升級閾值。這一點尤其重要，如果您發現已呈報的鎖不共享的表鎖，其中，但是，通常看不到在默認讀取已提交的隔離級別。如果使用預取的書簽查找子句導致升級，請考慮將其他列添加到索引查找或下方的書簽查找邏輯運算符掃描索引的邏輯運算符出現在查詢計劃中的非聚集索引。可能會創建覆蓋索引 （包括在查詢中使用表中的所有列的索引），或至少一個覆蓋已選擇的列的列表中包括的所有內容如果使用聯接條件或 WHERE 子句中的列的索引是不切實際的。
嵌套循環聯接也可以使用預取，，這將導致相同的鎖定行為。
如果不同的 SPID 當前持有的不兼容表鎖，則不會發生鎖升級。始終鎖升級升級到表級鎖，而從不頁鎖。此外，如果鎖定升級嘗試失敗，因為另一個 SPID 持有的不兼容的選項卡鎖，嘗試升級該查詢不會阻止在等待選項卡鎖。相反，它將繼續獲取鎖定在其原始、 更精細的級別 （行、 鍵或頁），定期進行其他升級嘗試。因此，防止在某個特定的表上的鎖升級的一種方法是獲取並與升級的鎖類型不兼容的不同連接保持鎖定。IX （意向排它） 鎖在表級別不會鎖定任何行或頁，但它仍不兼容已呈報 s （共享的） 或 X （獨占） 選項卡上的鎖。例如，假設您必須運行的批處理作業修改大量mytable表中的行和已導致阻塞的出現是由於鎖升級。如果此作業始終在不到一小時內完成，可能會創建包含以下代碼中，事務處理性 SQL 作業和計劃新作業啟動批處理作業的開始時間前幾分鍾的時間：
BEGIN TRAN
SELECT * FROM mytable (UPDLOCK, HOLDLOCK) WHERE 1=0
WAITFOR DELAY '1:00:00'
COMMIT TRAN
此查詢獲取，並一小時，這可以防止在表上的鎖升級這段時間內保持在mytable的 IX 鎖。這批不會修改任何數據或阻止其他查詢 （除非其他查詢強制使用 TABLOCK 提示的表鎖，或如果管理員已經禁用頁或行鎖，通過使用sp_indexoption存儲過程）。
此外，您可以通過啟用跟蹤標志 1211年禁用鎖升級。但是，此跟蹤標記會禁用所有的鎖升級的 SQL Server 實例中的全局范圍內。鎖升級最大化 ； 否則減速的獲取和釋放鎖的數千開銷的查詢的效率在 SQL Server 中提供非常有用的目的。鎖升級還有助於最小化所需的內存，以跟蹤的鎖。可以將 SQL Server 鎖結構中動態分配的內存是有限的的因此如果您禁用鎖升級和鎖定內存增長足夠大、 分配額外的鎖包含任何查詢可能會失敗並出現下面的錯誤：
錯誤: 1204，嚴重性： 19 日狀態： 1
這一次，SQL Server 無法獲得鎖資源。有較少的活動用戶時重新運行該語句，或者請求系統管理員檢查 SQL Server 鎖和內存配置。
注意"1204"錯誤時，它會停止當前語句的處理，並導致回滾當前事務。回滾本身可能會阻止用戶或導致很長的資料庫恢復時間，如果您在重新啟動 SQL Server 服務。
使用鎖定提示 （如 ROWLOCK 只會更改初始鎖定計劃。鎖提示不能防止鎖升級。
防止鎖升級的前面部分討論的其他方法是更好的方法比啟用跟蹤標記。此外，其他方法通常會導致查詢性能優於禁用整個實例的鎖升級。Microsoft 建議您啟用此跟蹤標記只是為了緩解嚴重阻塞引起鎖升級，而其他選項，如那些討論先前在本文中，所調查的。要啟用跟蹤標志，以便它打開時 SQL Server 啟動時，將其添加為伺服器啟動參數。
添加伺服器啟動參數，用滑鼠右鍵單擊該伺服器在 SQL 企業管理器中，單擊屬性然後單擊在常規選項卡上的啟動參數，然後添加下面的參數 （嚴格按照所示）：
-T1211
您必須重新打開 SQL Server 服務為新的啟動參數才會生效。如果您在查詢分析器中運行下面的查詢跟蹤標記將立即生效：DBCC TRACEON (1211, -1)
但是，如果您沒有添加-T1211啟動參數traceon命令的效果時會丟失關閉並重新打開 SQL Server 服務。打開跟蹤標志可防止任何將來的鎖升級，但它不會反轉任何已經發生的活動事務的鎖升級。
⑼ mysql直接set鎖等待時間需要重啟mysql嗎
把php.ini中的 ;date.timezone = 修改成 date.timezone = PRC 重啟即可 還有 我們一般使用「date -s」命令來修改系統時間。比如將系統時間設定成2005年7月26日的命令如下。 #date -s 03/28/2008 將系統時間設定成下午11點12分0秒的命令如下。 #dat...
⑽ 為什麼我們需要在SQL Server里更新鎖
首先介紹下當更新鎖（Update（U）Lock）獲得時，根據它的兼容性鎖本身是如何應對的。
一般來說，當執行UPDATE語句時，SQL Server會用到更新鎖（Update Lock）。如果查看對應的執行計劃，會看到它包含3個部分：
讀取數據
計算新值
寫入數據
這是其中一個主要原因，為什麼關系資料庫引擎引入更新鎖來實現避免特定的死鎖情形。一個更新鎖只與一個共享鎖兼容，但不與另一個更新或排它鎖兼容。因此死鎖情形可以被避免，應為2個更新查詢計劃不可能同時並發運行。在查詢的第1階段，第2個查詢會一直等到獲得更新鎖。System R的一個未公開研究也展示如何避免這類顯著的死鎖。System R不實用任何更新鎖來實現避免死鎖。
提升的並發
在第1階段不獲得更新鎖，在這個階段直接獲得排它鎖也是可見選項。這會克服死鎖問題，因為排它鎖與另一個排它鎖不兼容。但這個方法的問題是並發受限制，因為同時沒有其他的SELECT查詢可以讀取當前有排它鎖的數據。因此需要更新鎖，因為這個特定鎖與傳統的共享鎖兼容。這樣的話其他的SELECT查詢可以讀取數據，只要這個更新鎖還沒轉化為排它鎖。作為副作用，這會提高我們並發運行查詢的並發性。
在以前關系學術上，更新鎖是所謂的非對稱鎖（Asymmetric Lock）。在更新鎖的上下文里，這個更新鎖與共享鎖兼容，但反之就不是：共享鎖與更新鎖不兼容。但SQL Server並不把共享鎖作為非對稱鎖實現。更新鎖是個對稱（symmetric）的，就是說更新鎖和共享鎖是彼此雙向兼容的。這會提供系統的整體並發，因為在2個鎖類型鍵不會引入阻塞情形。
小結
在今天的文章里你介紹了共享鎖，還有為什麼需要共享鎖在關系資料庫，是強烈需要更新鎖的，因為不然的就會帶來死鎖並降低並發。