㈠ 資料庫鎖死了應該怎麼處理
乾等不如重新啟動，注意死鎖出現的地方,分析這部分程序,加以優化修改.
加內存，還有是不是硬碟空間小了、
㈡ 資料庫死鎖處理方法
mysql資料庫死鎖解決方法如下：
1、對於按鈕等控制項，點擊後使其立刻失效，不讓用戶重復點擊，避免對同時對同一條記錄操作。
2、使用樂觀鎖進行控制。樂觀鎖大多是基於數據版本（Version）記錄機制實現。即為數據增加一個版本標識，在基於資料庫表的版本解決方案中，一般是 通過為資料庫表增加一個「version」欄位來實現。讀取出數據時，將此版本號一同讀出，之後更新時，對此版本號加一。此時，將提交數據的版本數據與數 據庫表對應記錄的當前版本信息進行比對，如果提交的數據版本號大於資料庫表當前版本號，則予以更新，否則認為是過期數據。樂觀鎖機制避免了長事務中的數據 庫加鎖開銷（用戶A和用戶B操作過程中，都沒有對資料庫數據加鎖），大大提升了大並發量下的系統整體性能表現。Hibernate 在其數據訪問引擎中內置了樂觀鎖實現。需要注意的是，由於樂觀鎖機制是在系統中實現，來自外部系統的用戶更新操作不受系統的控制，因此可能會造 成臟數據被更新到資料庫中。
㈢ 資料庫進程死鎖,該如何處理
資料庫進程死鎖 應用場景如下：使用BizTalk從webservice介面獲取數據，在存儲過程GetExchangeConfig中設置每次獲取的數據數量以及開始時間，獲取數據後，Update獲取數據的開始時間，使用存儲過程UpdateExchangeConfig，在存儲過程GetExchangeConfig中對開始時間進行Select操作，在存儲過程UpdateExchangeConfig中對開始時間進行Update操作，產生資料庫死鎖，導致數據獲取中斷。 SQL code USE [NotaryBusiness]GO/****** 對象: StoredProcere [dbo].[GetExchangeConfig] 腳本日期: 01/26/2011 17:26:57 ******/ SET ANSI_NULLS ONGOSET QUOTED_IDENTIFIER ONGOALTER PROCEDURE [dbo].[GetExchangeConfig]/*(@parameter1 int = 5, @parameter2 datatype OUTPUT)*/AS/* SET NOCOUNT ON */ select [Count],TimeBegin from ExchangeConfig for xml autoRETURNSQL code SET ANSI_NULLS ONGOSET QUOTED_IDENTIFIER ONGOALTER PROCEDURE [dbo].[UpdateExchangeConfig] @TimeBegin as datetimeASupdate ExchangeConfig set TimeBegin=@TimeBeginRETURN ------解決方案--------------------------------------------------------
㈣ 資料庫被鎖定了怎麼辦急急急急急急十萬火急
開啟Windows Image Acquisition (WIA)服務就可以了
打開控制面板，打開管理工具，打開服務，找到Windows Image Acquisition (WIA)服務，在上面點右鍵，然後點屬性，然後把啟動類型改為自動，再按確定就可以了
㈤ 資料庫死鎖怎麼產生，怎樣能解決
資料庫操作的死鎖是不可避免的，本文並不打算討論死鎖如何產生，重點在於解決死鎖，通過SQL Server 2005, 現在似乎有了一種新的解決辦法。
將下面的SQL語句放在兩個不同的連接裡面，並且在5秒內同時執行，將會發生死鎖。
use Northwind
begin tran
insert into Orders(CustomerId) values(@#ALFKI@#)
waitfor delay @#00:00:05@#
select * from Orders where CustomerId = @#ALFKI@#
commit
print @#end tran@#
SQL Server對付死鎖的辦法是犧牲掉其中的一個，拋出異常，並且回滾事務。在SQL Server 2000，語句一旦發生異常，T-SQL將不會繼續運行，上面被犧牲的連接中， print @#end tran@#語句將不會被運行，所以我們很難在SQL Server 2000的T-SQL中對死鎖進行進一步的處理。
現在不同了，SQL Server 2005可以在T-SQL中對異常進行捕獲，這樣就給我們提供了一條處理死鎖的途徑：
下面利用的try ... catch來解決死鎖。
SET XACT_ABORT ON
declare @r int
set @r = 1
while @r <= 3
begin
begin tran
begin try
insert into Orders(CustomerId) values(@#ALFKI@#)
waitfor delay @#00:00:05@#
select * from Orders where CustomerId = @#ALFKI@#
commit
break
end try
begin catch
rollback
waitfor delay @#00:00:03@#
set @r = @r + 1
continue
end catch
end
解決方法當然就是重試，但捕獲錯誤是前提。rollback後面的waitfor不可少，發生沖突後需要等待一段時間，@retry數目可以調整以應付不同的要求。
但是現在又面臨一個新的問題: 錯誤被掩蓋了，一但問題發生並且超過3次，異常卻不會被拋出。SQL Server 2005 有一個RaiseError語句，可以拋出異常，但卻不能直接拋出原來的異常，所以需要重新定義發生的錯誤，現在，解決方案變成了這樣:
declare @r int
set @r = 1
while @r <= 3
begin
begin tran
begin try
insert into Orders(CustomerId) values(@#ALFKI@#)
waitfor delay @#00:00:05@#
select * from Orders where CustomerId = @#ALFKI@#
commit
break
end try
begin catch
rollback
waitfor delay @#00:00:03@#
set @r = @r + 1
continue
end catch
end
if ERROR_NUMBER() <> 0
begin
declare @ErrorMessage nvarchar(4000);
declare @ErrorSeverity int;
declare @ErrorState int;
select
@ErrorMessage = ERROR_MESSAGE(),
@ErrorSeverity = ERROR_SEVERITY(),
@ErrorState = ERROR_STATE();
raiserror (@ErrorMessage,
@ErrorSeverity,
@ErrorState
);
end
我希望將來SQL Server 2005能夠直接拋出原有異常，比如提供一個無參數的RaiseError。
因此方案有點臃腫，但將死鎖問題封裝到T-SQL中有助於明確職責，提高高層系統的清晰度。現在，對於DataAccess的代碼，或許再也不需要考慮死鎖問題了。
㈥ 資料庫死鎖一般都什麼原因導致的
一般情況只發生鎖超時，就是一個進程需要訪問資料庫表或者欄位的時候，另外一個程序正在執行帶鎖的訪問（比如修改數據），那麼這個進程就會等待，當等了很久鎖還沒有解除的話就會鎖超時，報告一個系統錯誤，拒絕執行相應的SQL操作。
發生死鎖的情況比較少，比如一個進程需要訪問兩個資源（資料庫表或者欄位），當獲取一個資源的時候進程就對它執行鎖定，然後等待下一個資源空閑，這時候如果另外一個進程也需要兩個資源，而已經獲得並鎖定了第二個資源，那麼就會死鎖，因為當前進程鎖定第一個資源等待第二個資源，而另外一個進程鎖定了第二個資源等待第一個資源，兩個進程都永遠得不到滿足。