怎么查看數(shù)據(jù)庫鎖表?

怎么知道數(shù)據(jù)庫表已經(jīng)鎖表了

網(wǎng)站建設(shè)哪家好，找創(chuàng)新互聯(lián)公司！專注于網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、成都微信小程序、集團企業(yè)網(wǎng)站建設(shè)等服務(wù)項目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了安仁免費建站歡迎大家使用！

先回答你的問題：

select *from v$locked_object;

可以獲得被鎖的對象的object_id及產(chǎn)生鎖的會話sid。

通過查詢結(jié)果中的object_id，可以查詢到具體被鎖的對象

再給你看看我查到的一些關(guān)于鎖的資料：

鎖有以下幾種模式:

0：none

1：null 空

2：Row-S 行共享(RS)：共享表鎖

3：Row-X 行專用(RX)：用于行的修改

4：Share 共享鎖(S)：阻止其他DML操作

5：S/Row-X 共享行專用(SRX)：阻止其他事務(wù)操作

6：exclusive 專用(X)：獨立訪問使用

數(shù)字越大鎖級別越高, 影響的操作越多。

一般的查詢語句如select ... from ... ;是小于2的鎖, 有時會在v$locked_object出現(xiàn)。

select ... from ... for update; 是2的鎖。

當對話使用for update子串打開一個游標時，

所有返回集中的數(shù)據(jù)行都將處于行級(Row-X)獨占式鎖定，

其他對象只能查詢這些數(shù)據(jù)行，不能進行update、delete或select...for update操作。

insert / update / delete ... ; 是3的鎖。

沒有mit之前插入同樣的一條記錄會沒有反應(yīng),

因為后一個3的鎖會一直等待上一個3的鎖, 我們必須釋放掉上一個才能繼續(xù)工作。

創(chuàng)建索引的時候也會產(chǎn)生3,4級別的鎖。

locked_mode為2,3,4不影響DML(insert,delete,update,select)操作,

但DDL(alter,drop等)操作會提示ora-00054錯誤。

有主外鍵約束時 update / delete ... ; 可能會產(chǎn)生4,5的鎖。

DDL語句時是6的鎖。

以DBA角色, 查看當前數(shù)據(jù)庫里鎖的情況可以用如下SQL語句：

select object_id,session_id,locked_mode from v$locked_object;

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;

如果有長期出現(xiàn)的一列，可能是沒有釋放的鎖。

我們可以用下面SQL語句殺掉長期沒有釋放非正常的鎖：

alter system kill session 'sid,serial#';

如果出現(xiàn)了鎖的問題, 某個DML操作可能等待很久沒有反應(yīng)。

當你采用的是直接連接數(shù)據(jù)庫的方式，

也不要用OS系統(tǒng)命令 $kill process_num 或者 $kill -9 process_num來終止用戶連接，

因為一個用戶進程可能產(chǎn)生一個以上的鎖, 殺OS進程并不能徹底清除鎖的問題。

記得在數(shù)據(jù)庫級別用alter system kill session 'sid,serial#';殺掉不正常的鎖。

這里還講了一些：

......

查看oracle是否鎖表

Oracle數(shù)據(jù)庫操作中，我們有時會用到鎖表查詢以及解鎖和kill進程等操作，那么這些操作是怎么實現(xiàn)的呢？本文我們主要就介紹一下這部分內(nèi)容。

(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)殺掉對應(yīng)進程

執(zhí)行命令：alter system kill session'1025,41';

其中1025為sid,41為serial#.

怎么查看 sql server 數(shù)據(jù)庫有沒有鎖表

--查看被鎖表： 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)

MYSQL數(shù)據(jù)庫怎么查看 哪些表被鎖了

用navicate工具可以輕松查看

里面lock的就是被鎖的

查詢oracle 數(shù)據(jù)庫里有哪些表鎖死

查鎖，

SELECT /*+ rule */ s.username,

decode(l.type,'TM','TABLE LOCK',

'TX','ROW LOCK',

NULL) LOCK_LEVEL,

o.owner,o.object_name,o.object_type,

s.sid,s.serial#,s.terminal,s.machine,s.program,s.osuser

FROM v$session s,v$lock l,dba_objects o

WHERE l.sid = s.sid

AND l.id1 = o.object_id(+)

AND s.username is NOT NULL

殺鎖

alter system kill session '25,7357'

如何查詢mysql數(shù)據(jù)庫表是否被鎖 csdn

show OPEN TABLES where In_use 0;

如何查看mysql中表的鎖定情況

1 show processlist;

SHOW PROCESSLIST顯示哪些線程正在運行。您也可以使用mysqladmin processlist語句得到此信息。如果您有SUPER權(quán)限，您可以看到所有線程。否則，您只能看到您自己的線程（也就是，與您正在使用的MySQL賬戶相關(guān)的線程）。如果有線程在update或者insert 某個表，此時進程的status為updating 或者 sending data。

如果您得到“too many connections”錯誤信息，并且想要了解正在發(fā)生的情況，本語句是非常有用的。MySQL保留一個額外的連接，讓擁有SUPER權(quán)限的賬戶使用，以確保管理員能夠隨時連接和檢查系統(tǒng)（假設(shè)您沒有把此權(quán)限給予所有的用戶）。

Status

含義

Checking table

正在檢查數(shù)據(jù)表（這是自動的）。

Closing tables

正在將表中修改的數(shù)據(jù)刷新到磁盤中，同時正在關(guān)閉已經(jīng)用完的表。這是一個很快的操作，如果不是這樣的話，就應(yīng)該確認磁盤空間是否已經(jīng)滿了或者磁盤是否正處于重負中。

Connect Out

復制從服務(wù)器正在連接主服務(wù)器。

Copying to tmp table on disk

由于臨時結(jié)果集大于tmp_table_size，正在將臨時表從內(nèi)存存儲轉(zhuǎn)為磁盤存儲以此節(jié)省內(nèi)存。

Creating tmp table

正在創(chuàng)建臨時表以存放部分查詢結(jié)果。

deleting from main table

服務(wù)器正在執(zhí)行多表刪除中的第一部分，剛刪除第一個表。

deleting from reference tables

服務(wù)器正在執(zhí)行多表刪除中的第二部分，正在刪除其他表的記錄。

Flushing tables

正在執(zhí)行FLUSH TABLES，等待其他線程關(guān)閉數(shù)據(jù)表。

Killed

發(fā)送了一個kill請求給某線程，那么這個線程將會檢查kill標志位，同時會放棄下一個kill請求。MySQL會在每次的主循環(huán)中檢查kill標志位，不過有些情況下該線程可能會過一小段才能死掉。如果該線程程被其他線程鎖住了，那么kill請求會在鎖釋放時馬上生效。

Locked

被其他查詢鎖住了。

Sending data

正在處理SELECT查詢的記錄，同時正在把結(jié)果發(fā)送給客戶端。

Sorting for group

正在為GROUP BY做排序。

Sorting for order

正在為ORDER BY做排序。

Opening tables

這個過程應(yīng)該會很快，除非受到其他因素的干擾。例如，在執(zhí)ALTER TABLE或LOCK TABLE語句行完以前，數(shù)據(jù)表無法被其他線程打開。正嘗試打開一個表。

Removing duplicates

正在執(zhí)行一個SELECT DISTINCT方式的查詢，但是MySQL無法在前一個階段優(yōu)化掉那些重復的記錄。因此，MySQL需要再次去掉重復的記錄，然后再把結(jié)果發(fā)送給客戶端。

Reopen table

獲得了對一個表的鎖，但是必須在表結(jié)構(gòu)修改之后才能獲得這個鎖。已經(jīng)釋放鎖，關(guān)閉數(shù)據(jù)表，正嘗試重新打開數(shù)據(jù)表。

Repair by sorting

修復指令正在排序以創(chuàng)建索引。

Repair with keycache

修復指令正在利用索引緩存一個一個地創(chuàng)建新索引。它會比Repair by ......

如何查看SQL數(shù)據(jù)有沒有鎖表

后續(xù)版本的 Microsoft SQL Server 將刪除該功能。請避免在新的開發(fā)工鼎中使用該功能，并著手修改當前還在使用該功能的應(yīng)用程序。若要獲取有關(guān) SQL Server 數(shù)據(jù)庫引擎中的鎖的信息，請使用 sys.dm_tran_locks 動態(tài)管理視圖。

USE master;

GO

EXEC sp_lock 53;

GO

查看Oracle中是否有鎖表的sql

查鎖，

SELECT /*+ rule */ s.username,

decode(l.type,'TM','TABLE LOCK',

'TX','ROW LOCK',

NULL) LOCK_LEVEL,

o.owner,o.object_name,o.object_type,

s.sid,s.serial#,s.terminal,s.machine,s.program,s.osuser

FROM v$session s,v$lock l,dba_objects o

WHERE l.sid = s.sid

AND l.id1 = o.object_id(+)

AND s.username is NOT NULL

殺鎖

alter system kill session '25,7357'

如何查詢mysql中是否表被鎖

show OPEN TABLES where In_use 0;

show global status like 'table_locks%';

mysql查看是否鎖表并解除鎖

一：檢查是否鎖表, 查詢進程并殺死進程

1) 查詢是否鎖表

show open tables where in_use 0;

2) 查詢進程（如果您有SUPER權(quán)限，您可以看到所有線程。否則，您只能看到您自己的線程）

show processlist;

二：查看在鎖事務(wù),殺死事務(wù)對應(yīng)的線程ID

1) 查看正在鎖的事務(wù)

select * from information_schema.INNODB_LOCKS;

2) 殺死進程id（就是[select * from information_schema.INNODB_LOCKS; ]命令的trx_mysql_thread_id列）

kill 線程ID

3) 查看等待鎖的事務(wù)

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;

其它：

1) 查看服務(wù)器狀態(tài)

show status like '%lock%';

2) 查看超時時間：

show variables like '%timeout%';

怎么查看mysql表是否被鎖定

當你開始執(zhí)行一個 ALTER ，而你遇到了可怕的“元數(shù)據(jù)鎖定等待”，我敢肯定你一定遇見過。我最近遇到了一個案例，其中被更改的表要執(zhí)行一個很小范圍的更新（100行）。ALTER 在負載測試期間一直等待了幾個小時。在停止負載測試后，ALTER 按預期在不到一秒的時間內(nèi)就完成了。那么這里發(fā)生了什么？

檢查外鍵

每當有奇數(shù)次鎖定時，我的第一直覺就是檢查外鍵。當然這張表有一些外鍵引用了一個更繁忙的表。但是這種行為似乎仍然很奇怪。對表運行 ALTER 時，會針對子表請求一個 SHARED_UPGRADEABLE 元數(shù)據(jù)鎖。還有針對父級的 SHARED_READ_ONLY 元數(shù)據(jù)鎖。

我們來看看如何根據(jù)文檔獲取元數(shù)據(jù)鎖定[1]：

如果給定鎖定有多個服務(wù)器，則首先滿足最高優(yōu)先級鎖定請求，并且與 max_write_lock_count系統(tǒng)變量有關(guān)。寫鎖定請求的優(yōu)先級高于讀取鎖定請求。

[1]：

請務(wù)必注意鎖定順序是序列化的：語句逐個獲取元數(shù)據(jù)鎖，而不是同時獲取，并在此過程中執(zhí)行死鎖檢測。

通常在考慮隊列時考慮先進先出。如果我發(fā)出以下三個語句（按此順序），它們將按以下順序完成：

1. INSERT INTO parent2. ALTER TABLE child3. INSERT INTO parent

但是當子 ALTER 語句請求對父進行讀取鎖定時，盡管排序，但兩個插入將在 ALTER 之前完成。以下是可以演示此示例的示例場景：

數(shù)據(jù)初始化：

CREATE TABLE `parent` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`val` varchar(10) DEFAULT NULL,

PRIMARY KEY (`id`)

) ENGINE=InnoDB;

CREATE TABLE `child` (

`id` int(11) NOT NULL AUTO_INCREMENT,

`parent_id` int(11) DEFAULT NULL,

`val` varchar(10) DEFAULT NULL,

PRIMARY KEY (`id`),

KEY `idx_parent` (`parent_id`),

CONSTRAINT `fk_parent` FOREIGN KEY (`parent_id`) REFERENCES `parent` (`id`) ON DELETE CASCADE ON UPDATE NO ACTION

) ENGINE=InnoDB;

INSERT INTO `parent` VALUES (1, "one"), (2, "two"), (3, "three"), (4, "four");

Session 1:

start transaction;update parent set val = "four-new" where id = 4;

Session 2:

alter table child add index `idx_new` (val);

Session 3:

start transaction;update parent set val = "three-new" where id = 3;

此時，會話 1 具有打開的事務(wù)，并且處于休眠狀態(tài)，并在父級上授予寫入元數(shù)據(jù)鎖定。 會話 2 具有在子級上授予的可升級（寫入）鎖定，并且正在等待父級的讀取鎖定。最后會話 3 具有針對父級的授權(quán)寫入鎖定：

mysql select * from performance_schema.metadata_locks;+-------------+-------------+-------------------+---------------+-------------+| OBJECT_TYPE | OBJECT_NAME | LOCK_TYPE ? ? ? ? | LOCK_DURATION | LOCK_STATUS |+-------------+-------------+-------------------+---------------+-------------+| TABLE ? ? ? | child ? ? ? | SHARED_UPGRADABLE | TRANSACTION ? | GRANTED ? ? | - ALTER (S2)| TABLE ? ? ? | parent ? ? ?| SHARED_WRITE ? ? ?| TRANSACTION ? | GRANTED ? ? | - UPDATE (S1)| TABLE ? ? ? | parent ? ? ?| SHARED_WRITE ? ? ?| TRANSACTION ? | GRANTED ? ? | - UPDATE (S3)| TABLE ? ? ? | parent ? ? ?| SHARED_READ_ONLY ?| STATEMENT ? ? | PENDING ? ? | - ALTER (S2)+-------------+-------------+-------------------+---------------+-------------+

請注意，具有掛起鎖定狀態(tài)的唯一會話是會話 2（ALTER）。會話 1 和會話 3 （分別在 ALTER 之前和之后發(fā)布）都被授予了寫鎖。排序失敗的地方是在會話 1 上發(fā)生提交的時候。在考慮有序隊列時，人們會期望會話 2 獲得鎖定，事情就會繼續(xù)進行。但是，由于元數(shù)據(jù)鎖定系統(tǒng)的優(yōu)先級性質(zhì)，會話 3 具有鎖定，會話 2 仍然等待。

如果另一個寫入會話進入并啟動新事務(wù)并獲取針對父表的寫鎖定，則即使會話 3 完成，ALTER 仍將被阻止。

只要我保持一個對父表打開元數(shù)據(jù)鎖定的活動事務(wù)，子表上的 ALTER 將永遠不會完成。更糟糕的是，由于子表上的寫鎖定成功（但是完整語句正在等待獲取父讀鎖定），所以針對子表的所有傳入讀取請求都將被阻止！

另外，請考慮一下您通常如何對無法完成的語句進行故障排除。您查看已經(jīng)打開較長時間的事務(wù)（在進程列表和 InnoDB 狀態(tài)中）。但由于阻塞線程現(xiàn)在比 ALTER 線程更年輕，因此您將看到的最舊的事務(wù)/線程是 ALTER 。

這正是這種情況下發(fā)生的情況。在準備發(fā)布時，我們的客戶端正在運行 ALTER 語句并結(jié)合負載測試（一種非常好的做法！）以確保順利發(fā)布。問題是負載測試保持對父表打開一個活動的寫事務(wù)。這并不是說它只是一直在寫，而是有多個線程，一個總是活躍的。 這阻止了 ALTER 完成并阻止對相對靜態(tài)的子表的隨后的讀請求。

幸運的是，這個問題有一個解決方案（除了從設(shè)計模式中驅(qū)逐外鍵）。變量?max_write_lock_count[2]?可用于允許在寫入鎖定之后在讀取鎖定之前授予讀取鎖定連續(xù)寫鎖。默認情況下，此變量設(shè)置為 18446744073709551615，如果你對該表發(fā)出 10,000 次寫入/秒，那么你的讀將被鎖定 5800 萬年……

MySQL數(shù)據(jù)庫中查詢表是否被鎖以及解鎖

1.查看表被鎖狀態(tài)

2.查看造成死鎖的sql語句

3.查詢進程

4.解鎖(刪除進程)

5.查看正在鎖的事物? (8.0以下版本)

6.查看等待鎖的事物?(8.0以下版本)