㈠ 資料庫中某條數據被鎖了。如何解鎖
用下面的語句檢查資料庫鎖，然後kill 掉產生鎖的進程就ok了。
查慎搭鎖：
select nvl(S.USERNAME,'Internal') username,
nvl(S.TERMINAL,'None') terminal,
L.SID||','||S.SERIAL# Kill,
U1.NAME||'.'雀尺||substr(T1.NAME,1,20) tab,
decode(L.LMODE,1,'No Lock',
2,'Row Share',
3,'Row Exclusive',
4,'Share',
5,'Share Row Exclusive',
6,'Exclusive',null) lmode,
decode(L.REQUEST,1,'No Lock'寬歲拿,
2,'Row Share',
3,'Row Exclusive',
4,'Share',
5,'Share Row Exclusive',
6,'Exclusive',null) request
from V$LOCK L,
V$SESSION S,
SYS.USER$ U1,
SYS.OBJ$ T1
where L.SID = S.SID
and T1.OBJ# = decode(L.ID2,0,L.ID1,L.ID2)
and U1.USER# = T1.OWNER#
and S.TYPE != 'BACKGROUND'
order by 1,2,5
殺鎖：
alter system kill session 'sid,#serial';
sid和#serial用前面查詢到的結果替換。
㈡ 資料庫被鎖定了怎麼辦急急急急急急十萬火急
開啟Windows Image Acquisition (WIA)服務就可以了
打開控制面板，打開管理工具，打開服務，找到Windows Image Acquisition (WIA)服務，在上面點右鍵，然後點屬性，然後把啟動類型改為自動，再按確定就可以了
㈢ 怎麼理解資料庫的鎖 一般鎖分別哪幾種
資料庫是一個多用戶使用的共享資源。當多個用戶並發地存取數據時，在資料庫中就會產生多個事務同時存取同一數據的情況。若對並發操作不加控制就可能會讀取和存儲不正確的數據，破壞資料庫的一致性。
加鎖是實現資料庫並發控制的一個非常重要的技術。當事務在對某個數據對象進行操作前，先向系統發出請求，對其加鎖。加鎖後事務就對該數據對象有了一定的控制，在該事務釋放鎖之前，其他的事務不能對此數據對象進行更新操作。
在資料庫中有兩種基本的鎖類型：排它鎖（Exclusive Locks，即X鎖）和共享鎖（Share Locks，即S鎖）。當數據對象被加上排它鎖時，其他的事務不能對它讀取和修改。加了共享鎖的數據對象可以被其他事務讀取，但不能修改。資料庫利用這兩種基本的鎖類型來對資料庫的事務進行並發控制。
(3)雲開發資料庫鎖擴展閱讀：
排它鎖和共享鎖的不同之處：
1、共享鎖（S鎖）：如果事務T對數據A加上共享鎖後，則其他事務只能對A再加共享鎖，不能加排他鎖。獲准共享鎖的事務只能讀數據，不能修改數據。
排他鎖（X鎖）：如果事務T對數據A加上排他鎖後，則其他事務不能再對A加任任何類型的封鎖。獲准排他鎖的事務既能讀數據，又能修改數據。
2、共享鎖下其它用戶可以並發讀取，查詢數據。但不能修改，增加，刪除數據，資源共享。
3、共享鎖又稱為讀鎖（Share lock,簡記為S鎖），若事務T對數據對象A加上S鎖，則其它事務只能再對A加S鎖，而不能加X鎖，直到T釋放A上的S鎖。
㈣ 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的鎖表其實還有很多其他場景，我們在實踐的過程中盡量避免鎖表情況的發生，當然這需要一定經驗的支撐。但更重要的是，如果發現鎖表我們要能夠快速的響應，快速的解決問題，避免影響正常業務，避免情況進一步惡化。所以，本文中的解決思路大家一定要收藏或記憶一下，做到有備無患，避免突然狀況下抓瞎。
㈤ orcal資料庫表被鎖了怎麼解鎖
1、在做Oracle監聽程序測試時，發現帳戶已經被鎖定。
㈥ 資料庫中某條數據被鎖了。如何解鎖
1、查看資料庫鎖,診斷鎖的來源及類型：
select object_id,session_id,locked_mode from v$locked_object;
或者用以下命令：
select b.owner,b.object_name,l.session_id,l.locked_mode
from v$locked_object l, dba_objects b
where b.object_id=l.object_id 2、找出資料庫的serial#,以備殺死：
select t2.username,t2.sid,t2.serial#,t2.logon_time
from v$locked_object t1,v$session t2
where t1.session_id=t2.sid order by t2.logon_time; 3、殺死該session
alter system kill session 'sid,serial#'
記得以上是用SYS或者SYSTEM賬戶進入，要不沒許可權。
㈦ oracle資料庫被鎖了怎麼辦
用戶被鎖了？
FAILED_LOGIN_ATTEMPTS參數默認是10，即：用戶連續輸入10次錯誤密碼，用戶會被鎖住；
可以使用其他擁有DBA許可權的用戶進行解鎖；
alter user username account unlock;
如果是資料庫內部出現死鎖或阻塞會話，可以先查出阻塞的會話，
select * from dba_waiters;
在殺掉阻塞的會話
alter system kill session 'sid,serial#';
測試環境，可以直接重啟資料庫！
㈧ 分析解決資料庫鎖Waiting for table metadata lock
參考：
https://www.cnblogs.com/digdeep/p/4892953.html
https://blog.csdn.net/u013235478/article/details/68062939/
從 information_schema.innodb_trx 表中查看當前未提交的事務
lock_wait_timeout 表示獲取metadata lock的超時（單位為秒），允許的值范圍為1到31536000（1年）。 默認值為31536000。詳缺此或見 https://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_lock_wait_timeout 。默認值為一年！！！已哭瞎！將其調整為30分鍾
1.2 查看錶是否太大
看出表非常小，不存在由於數據量大導致更新慢的問題；扒雀
1.3 查看引擎狀態
數據量太大，一屏幕都顯示不完，不看了。
既然幾個比較直接的方法都查不到原因，那隻能更深入的查伏伍下了，我打算從數據字典中查下（information_schema，performance_schema）：
1.4，查找當前等待事務：
顯示空。
查找 information_schema 中的 事件表（EVENTS ）、鎖等待表（INNODB_LOCK_WAITS），innodb 當前出現的鎖****（INNODB_LOCKS ）均沒看到異常（這里就不貼圖了）。
1.5 查找事務
既然造成該鎖的原因是事務沒有提交導致的，那我們應該去查找當前是否有事務在運行（ runing 註：由於事務一直是runing狀態，這也就是為什麼我之前查找各種鎖都找不到的原因）
不過有重大發現：一個 trx_mysql_thread_id: 275255348 是從 trx_started: 2015-12-03 14:58:45 一直處於runing狀態的。
既然我們找到了id了 那我們再回顧使用 show processlist 查找該ID就行了：
發現了嗎，該ID一直是sleep狀態。很難發現該進程打開了這個表（可以通過show open tables 查看當前打開的表）。
解決辦法： 詢問了開發這個點的腳本，操作。確認後通過後台mysql 直接kill掉這個進程，業務的alter操作瞬間完成。