資料庫被鎖會如何

⑴ oracle資料庫表被鎖了不能操作怎麼辦

首先你要知道表鎖住了是不是正常鎖？因為任何DML語句都會對表加鎖。
你要先查一下是那個會話那個sql鎖住了表，有可能這是正常業務需求，不建議隨便KILL
session，如果這個鎖表是正常業務你把session
kill掉了會影響業務的。
建議先查原因再做決定。
(1)鎖表查詢的代碼有以下的形式：
select
count(*)
from
v$locked_object;
select
*
from
v$locked_object;
(2)查看哪個表被鎖
select
b.owner,b.object_name,a.session_id,a.locked_mode
from
v$locked_object
a,dba_objects
b
where
b.object_id
=
a.object_id;
(3)查看是哪個session引起的
select
b.username,b.sid,b.serial#,logon_time
from
v$locked_object
a,v$session
b
where
a.session_id
=
b.sid
order
by
b.logon_time;
(4)查看是哪個sql引起的
select
b.username,b.sid,b.serial#,c.*
from
v$locked_object
a,v$session
b,v$sql
c
where
a.session_id
=
b.sid
and
b.SQL_ID
=
c.sql_id
and
c.sql_id
=
''
order
by
b.logon_time;
(5)殺掉對應進程
執行命令：alter
system
kill
session'1025,41';
其中1025為sid,41為serial#.

⑵ MySQL資料庫表被鎖、解鎖，刪除事務

在程序員的職業生涯中，總會遇到資料庫表被鎖的情況，前些天就又撞見一次。由於業務突發需求，各個部門都在批量操作、導出數據，而資料庫又未做讀寫分離，結果就是：資料庫的某張表被鎖了！

用戶反饋系統部分功能無法使用，緊急排查，定位是資料庫表被鎖，然後進行緊急處理。這篇文章給大家講講遇到類似緊急狀況的排查及解決過程，建議點贊收藏，以備不時之需。

用戶反饋某功能頁面報502錯誤，於是第一時間看服務是否正常，資料庫是否正常。在控制台看到資料庫CPU飆升，堆積大量未提交事務，部分事務已經阻塞了很長時間，基本定位是資料庫層出現問題了。

查看阻塞事務列表，發現其中有鎖表現象，本想利用控制台直接結束掉阻塞的事務，但控制台賬號許可權有限，於是通過客戶端登錄對應賬號將鎖表事務kill掉，才避免了情況惡化。

下面就聊聊，如果當突然面對類似的情況，我們該如何緊急響應？

想像一個場景，當然也是軟體工程師職業生涯中會遇到的一種場景：原本運行正常的程序，某一天突然資料庫的表被鎖了，業務無法正常運轉，那麼我們該如何快速定位是哪個事務鎖了表，如何結束對應的事物？

首先最簡單粗暴的方式就是：重啟MySQL。對的，網管解決問題的神器——「重啟」。至於後果如何，你能不能跑了，要你自己三思而後行了！

重啟是可以解決表被鎖的問題的，但針對線上業務很顯然不太具有可行性。

下面來看看不用跑路的解決方案：

遇到資料庫阻塞問題，首先要查詢一下表是否在使用。

如果查詢結果為空，那麼說明表沒在使用，說明不是鎖表的問題。

如果查詢結果不為空，比如出現如下結果：

則說明表（test）正在被使用，此時需要進一步排查。

查看資料庫當前的進程，看看是否有慢SQL或被阻塞的線程。

執行命令：

該命令只顯示當前用戶正在運行的線程，當然，如果是root用戶是能看到所有的。

在上述實踐中，阿里雲控制台之所以能夠查看到所有的線程，猜測應該使用的就是root用戶，而筆者去kill的時候，無法kill掉，是因為登錄的用戶非root的資料庫賬號，無法操作另外一個用戶的線程。

如果情況緊急，此步驟可以跳過，主要用來查看核對：

如果情況緊急，此步驟可以跳過，主要用來查看核對：

看事務表INNODB_TRX中是否有正在鎖定的事務線程，看看ID是否在show processlist的sleep線程中。如果在，說明這個sleep的線程事務一直沒有commit或者rollback，而是卡住了，需要手動kill掉。

搜索的結果中，如果在事務表發現了很多任務，最好都kill掉。

執行kill命令：

對應的線程都執行完kill命令之後，後續事務便可正常處理。

針對緊急情況，通常也會直接操作第一、第二、第六步。

這里再補充一些MySQL鎖相關的知識點：資料庫鎖設計的初衷是處理並發問題，作為多用戶共享的資源，當出現並發訪問的時候，資料庫需要合理地控制資源的訪問規則，而鎖就是用來實現這些訪問規則的重要數據結構。

根據加鎖的范圍，MySQL裡面的鎖大致可以分成全局鎖、表級鎖和行鎖三類。MySQL中表級別的鎖有兩種：一種是表鎖，一種是元數據鎖（metadata lock，MDL)。

表鎖是在Server層實現的，ALTER TABLE之類的語句會使用表鎖，忽略存儲引擎的鎖機制。表鎖通過lock tables… read/write來實現，而對於InnoDB來說，一般會採用行級鎖。畢竟鎖住整張表影響范圍太大了。

另外一個表級鎖是MDL（metadata lock），用於並發情況下維護數據的一致性，保證讀寫的正確性，不需要顯式的使用，在訪問一張表時會被自動加上。

常見的一種鎖表場景就是有事務操作處於：Waiting for table metadata lock狀態。

MySQL在進行alter table等DDL操作時，有時會出現Waiting for table metadata lock的等待場景。

一旦alter table TableA的操作停滯在Waiting for table metadata lock狀態，後續對該表的任何操作（包括讀）都無法進行，因為它們也會在Opening tables的階段進入到Waiting for table metadata lock的鎖等待隊列。如果核心表出現了鎖等待隊列，就會造成災難性的後果。

通過show processlist可以看到表上有正在進行的操作（包括讀），此時alter table語句無法獲取到metadata 獨占鎖，會進行等待。

通過show processlist看不到表上有任何操作，但實際上存在有未提交的事務，可以在information_schema.innodb_trx中查看到。在事務沒有完成之前，表上的鎖不會釋放，alter table同樣獲取不到metadata的獨占鎖。

處理方法：通過 select * from information_schema.innodb_trxG, 找到未提交事物的sid，然後kill掉，讓其回滾。

通過show processlist看不到表上有任何操作，在information_schema.innodb_trx中也沒有任何進行中的事務。很可能是因為在一個顯式的事務中，對表進行了一個失敗的操作（比如查詢了一個不存在的欄位），這時事務沒有開始，但是失敗語句獲取到的鎖依然有效，沒有釋放。從performance_schema.events_statements_current表中可以查到失敗的語句。

處理方法：通過performance_schema.events_statements_current找到其sid，kill 掉該session，也可以kill掉DDL所在的session。

總之，alter table的語句是很危險的（核心是未提交事務或者長事務導致的），在操作之前要確認對要操作的表沒有任何進行中的操作、沒有未提交事務、也沒有顯式事務中的報錯語句。

如果有alter table的維護任務，在無人監管的時候運行，最好通過lock_wait_timeout設置好超時時間，避免長時間的metedata鎖等待。

關於MySQL的鎖表其實還有很多其他場景，我們在實踐的過程中盡量避免鎖表情況的發生，當然這需要一定經驗的支撐。但更重要的是，如果發現鎖表我們要能夠快速的響應，快速的解決問題，避免影響正常業務，避免情況進一步惡化。所以，本文中的解決思路大家一定要收藏或記憶一下，做到有備無患，避免突然狀況下抓瞎。

⑶ 資料庫鎖定後，還有問題如何處理

資料庫已經鎖定，總結會已經召開。就是說已經完成揭盲了，揭盲後不能更回改數據答庫(讓人不由質疑：你根據組別更改了資料庫的內容，在可操作層面使得對研究葯物的評價更優)。在鎖庫之前要解決所有數據問題的(數據錄入完畢至盲態審核期結束)。揭盲後發現數據問題建議寫說明(什麼問題，為什麼沒有處理)，研究者簽字，申辦單位蓋章之類的。

⑷ oracle資料庫被鎖了怎麼辦

用戶被鎖了？
FAILED_LOGIN_ATTEMPTS參數默認是10，即：用戶連續輸入10次錯誤密碼，用戶會被鎖住；
可以使內用其他擁有DBA許可權的容用戶進行解鎖；
alter user username account unlock;

如果是資料庫內部出現死鎖或阻塞會話，可以先查出阻塞的會話，
select * from dba_waiters;
在殺掉阻塞的會話
alter system kill session 'sid,serial#';

測試環境，可以直接重啟資料庫！

⑸ 資料庫發生死鎖會出現什麼情況

資料庫操作的死鎖是不可避免的，本文並不打算討論死鎖如何產生，重點在於解決死鎖，通過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

⑹ 資料庫用戶被鎖連續訪問幾千次有什麼影響

最常見的是多個用戶同時操縱一個表的時候沖突，一個想改數據，一個想讀刪數據，當然會有沖突，這是有鎖的機制來約束並發訪問數據，就是當一個用戶對一個表的某個欄位進行操作時鎖定數據，直到操作完成鎖才接觸，然後下一個用戶來操作數據。

⑺ 資料庫發生死鎖系統會怎麼樣,系統還會運行嗎

資料庫死鎖，隻影響到資料庫的運行，系統是不受影響的。

⑻ 請問資料庫死鎖會對哪些數據類型的的數據產生影響

11.5.1 鎖的概念
鎖（Lock） 是在多用戶環境下對資源訪問的一種限制。機制當對一個數據源加鎖後，此數據源就有了一定的訪問限制。我們就稱對此數據源進行了「鎖定」。在SQL Server中，可以對以下的對象進行鎖定：

數據行（Row）：數據頁中的單行數據；
索引行（Key）：索引頁中的單行數據，即索引的鍵值；
頁（Page）：頁是SQL Server 存取數據的基本單位，其大小為8KB；
盤區（Extent）：一個盤區由8 個連續的頁組成；
表（Table）；
資料庫（Database）。
11.5.2 鎖的類別
在SQL Server 中，鎖有兩種分類方法。
（1） 從資料庫系統的角度來看
鎖分為以下三種類型：

獨占鎖（Exclusive Lock）
獨占鎖鎖定的資源只允許進行鎖定操作的程序使用，其它任何對它的操作均不會被接受。執行數據更新命令，即INSERT、 UPDATE 或DELETE 命令時，SQL Server 會自動使用獨占鎖。但當對象上有其它鎖存在時，無法對其加獨占鎖。獨占鎖一直到事務結束才能被釋放。
共享鎖（Shared Lock）
共享鎖鎖定的資源可以被其它用戶讀取，但其它用戶不能修改它。在SELECT 命令執行時，SQL Server 通常會對對象進行共享鎖鎖定。通常加共享鎖的數據頁被讀取完畢後，共享鎖就會立即被釋放。
更新鎖（Update Lock）
更新鎖是為了防止死鎖而設立的。當SQL Server 准備更新數據時，它首先對數據對象作更新鎖鎖定，這樣數據將不能被修改，但可以讀取。等到SQL Server 確定要進行更新數據操作時，它會自動將更新鎖換為獨占鎖。但當對象上有其它鎖存在時，無法對其作更新鎖鎖定。

（2）從程序員的角度看
鎖分為以下兩種類型：

樂觀鎖（Optimistic Lock）
樂觀鎖假定在處理數據時，不需要在應用程序的代碼中做任何事情就可以直接在記錄上加鎖、即完全依靠資料庫來管理鎖的工作。一般情況下，當執行事務處理時SQL Server會自動對事務處理范圍內更新到的表做鎖定。
悲觀鎖（Pessimistic Lock）
悲觀鎖對資料庫系統的自動管理不感冒，需要程序員直接管理數據或對象上的加鎖處理，並負責獲取、共享和放棄正在使用的數據上的任何鎖。
11.5.3 隔離級別
隔離（Isolation） 是計算機安全學中的一種概念，其本質上是一種封鎖機制。它是指自動數據處理系統中的用戶和資源的相關牽制關系，也就是用戶和進程彼此分開，且和操 作系統的保護控制也分開來。在SQL Server 中，隔離級（Isolation Level） 是指一個事務 和其它事務的隔離程度，即指定了資料庫如何保護（鎖定）那些當前正在被其它用戶或伺服器請求使用的數據。指定事務的隔離級與在SELECT 語句中使用鎖定選項來控制鎖定 方式具有相同的效果。
在SQL Server 中有以下四種隔離級：

READ COMMITTED
在此隔離級下，SELECT 命令不會返回尚未提交（Committed） 的數據，也不能返回臟數據。它是SQL Server 默認的隔離級。
READ UNCOMMITTED
與READ COMMITTED 隔離級相反，它允許讀取已經被其它用戶修改但尚未提交確定的數據。
REPEATABLE READ
在此隔離級下，用SELECT 命令讀取的數據在整個命令執行過程中不會被更改。此選項會影響系統的效能，非必要情況最好不用此隔離級。
SERIALIZABLE
與DELETE 語句中SERIALIZABLE 選項含義相同。
隔離級需要使用SET 命令來設定其語法如下：
SET TRANSACTION ISOLATION LEVEL
{READ COMMITTED
| READ UNCOMMITTED
| REPEATABLE READ
| SERIALIZABLE }

11.5.4 查看鎖
可以通過企業管理器或存儲過程來查看鎖。
（1） 用Enterprise Manager 查看鎖
在企業管理器中選擇目錄樹窗口中「Management」 文件夾下，「Current Activity」 中的「Locks / Process ID」 節點，則可以查看當前鎖定的進程；選擇同級的「Locks / Object」節點下的相應位元組點，則可以查看當前鎖定的對象，如圖11-1 所示。在圖11-1 中，右鍵單擊任務板窗口中的對象，從快捷菜單中選擇「屬性」選項，則會出現如圖11-2 所示的鎖的進程細節對話框。在此，可以刷新或殺死鎖的進程。

殺死進程還可以用如下Transact-SQL 命令來進行：
KILL spid
spid 是System Process ID， 即系統進程編號的縮寫，如圖11-1 中所示。

圖11-2 鎖定的進程細節

（2） 用系統存儲過程Sp_lock 查看鎖
存儲過程Sp_lock 的語法如下：
sp_lock spid
SQL Server 的進程編號spid 可以在master.dbo.sysprocesses 系統表中查到。spid 是INT類型的數據，如果不指定spid ，則顯示所有的鎖。

11.5.5 死鎖及其防止
死鎖（Deadlocking） 是在多用戶或多進程狀況下，為使用同一資源而產生的無法解決的爭用狀態，通俗地講，就是兩個用戶各佔用一個資源，兩人都想使用對方的資源，但同時又不願放棄自己的資源，就一直等待對方放棄資源，如果不進行外部干涉，就將一直耗下去。

死鎖會造成資源的大量浪費，甚至會使系統崩潰。在SQL Server 中解決死鎖的原則是「犧牲一個比兩個都死強」，即挑出一個進程作為犧牲者，將其事務回滾，並向執行此進程的程序發送編號為1205 的錯誤信息。而防止死鎖的途徑就是不能讓滿足死鎖條件的情況發生，為此，用戶需要遵循以下原則：

盡量避免並發地執行涉及到修改數據的語句；
要求每個事務一次就將所有要使用的數據全部加鎖，否則就不予執行；
預先規定一個封鎖順序所有的事務，都必須按這個順序對數據執行封鎖，例如，不同的過程在事務內部對對象的更新執行順序應盡量保持一致；
每個事務的執行時間不可太長，對程序段長的事務可考慮將其分割為幾個事務。
本章小結
本章中介紹了數據更新的方法及事務和鎖的概念。除了使用本章講述的語句更新數據外，還可以使用視圖來更新數據，有關視圖的運用請參見第13 章「游標和視圖」。

⑼ orcal資料庫表被鎖了怎麼解鎖

1、在做Oracle監聽程序測試時，發現帳戶已經被鎖定。

⑽ 資料庫被鎖定了怎麼辦急急急急急急十萬火急

開啟Windows Image Acquisition (WIA)服務就可以了

打開控制面板，打開管理工具，打開服務，找到Windows Image Acquisition (WIA)服務，在上版面點右鍵，然後權點屬性，然後把啟動類型改為自動，再按確定就可以了