查看資料庫鎖
查看sql server資料庫被鎖表可以用用如下語句：
拓展資料：
SQL Server 是Microsoft 公司推出的關系型資料庫管理系統。具有使用方便可伸縮性好與相關軟體集成程度高等優點，可跨越從運行Microsoft Windows 98 的膝上型電腦到運行Microsoft Windows 2012 的大型多處理器的伺服器等多種平台使用。
Microsoft SQL Server 是一個全面的資料庫平台，使用集成的商業智能 (BI)工具提供了企業級的數據管理。Microsoft SQL Server 資料庫引擎為關系型數據和結構化數據提供了更安全可靠的存儲功能，使您可以構建和管理用於業務的高可用和高性能的數據應用程序。
⑵ mysql 查看資料庫中有沒有鎖
第一步，查看行鎖使用情況，命令：
show statue like 'innodb_row_lock%';
如下圖所示：
第二步，創建資料庫表monitor_amount，如下圖所示：
第三步，查看innodb的狀態，命令：
show innodb status \G;
如下圖所示：
第四步，向資料庫表monitor_amount插入四條記錄，如下圖所示：
第五步，再次查看innodb狀態，如下圖所示：
第六步，可以利用刪除表命令來停止查看，如下圖所示：
⑶ MYSQL資料庫怎麼查看 哪些表被鎖了
以下五種方法可以快速定位全局鎖的位置，僅供參考。
方法1：利用 metadata_locks 視圖
此方法僅適用於 MySQL 5.7 以上版本，該版本 performance_schema 新增了 metadata_locks，如果上鎖前啟用了元數據鎖的探針（默認是未啟用的），可以比較容易的定位全局鎖會話。
方法2：利用 events_statements_history 視圖此方法適用於 MySQL 5.6 以上版本，啟用 performance_schema.eventsstatements_history（5.6 默認未啟用，5.7 默認啟用），該表會 SQL 歷史記錄執行，如果請求太多，會自動清理早期的信息，有可能將上鎖會話的信息清理掉。
方法3：利用 gdb 工具如果上述兩種都用不了或者沒來得及啟用，可以嘗試第三種方法。利用 gdb 找到所有線程信息，查看每個線程中持有全局鎖對象，輸出對應的會話 ID，為了便於快速定位，我寫成了腳本形式。也可以使用 gdb 交互模式，但 attach mysql 進程後 mysql 會完全 hang 住，讀請求也會受到影響，不建議使用交互模式。
方法4：show processlist
如果備份程序使用的特定用戶執行備份，如果是 root 用戶備份，那 time 值越大的是持鎖會話的概率越大，如果業務也用 root 訪問，重點是 state 和 info 為空的，這里有個小技巧可以快速篩選，篩選後嘗試 kill 對應 ID，再觀察是否還有 wait global read lock 狀態的會話。
方法5：重啟試試！
⑷ orcal資料庫表被鎖了怎麼解鎖
1、在做Oracle監聽程序測試時，發現帳戶已經被鎖定。
⑸ MySQL資料庫中查詢表是否被鎖以及解鎖
1.查看錶被鎖狀態
2.查看造成死鎖的sql語句
3.查詢進程
4.解鎖(刪除進程)
5.查看正在鎖的事物 (8.0以下版本)
6.查看等待鎖的事物 (8.0以下版本)
⑹ 如何查看oracle資料庫用戶是否被鎖
這個要dba許可權的用戶才能查看，具體的查看方法是 select * from dba_users 。用戶狀態一般是open（正常） locked（鎖定）expire（過期失效）幾種。
⑺ 分析解決資料庫鎖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操作瞬間完成。
⑻ 怎麼知道資料庫表已經鎖表了
可直接在mysql命令行執行：show engine innodb statusG;
查看造成死鎖的sql語句，分析索引情況，然後優化sql然後show processlist;
show status like 『%lock%』
show OPEN TABLES where In_use > 0; 這個語句記錄當前鎖表狀態
另外可以打開慢查詢日誌，linux下打開需在my.cnf的[mysqld]裡面加上以下內容：
slow_query_log=TRUE(有些mysql版本是ON)
slow_query_log_file=/usr/local/mysql/slow_query_log.txt
long_query_time=3
select *from v$locked_object：可以獲得被鎖的對象的object_id及產生鎖的會話sid。通過查詢結果中的object_id，可以查詢到具體被鎖的對象。
(8)查看資料庫鎖擴展閱讀：
注意事項
也可以直接把這幾個視圖和表關聯起來，在查詢結果中直接得到「alter system kill session 'sid, serial#'」這樣的方便的kill sessoin命令。
如果執行kill session命令後，鎖並沒有除掉，session依然存在。這種情況，通過select spid from v$process where addr in(select paddr from v$session where sid = &sid)查詢到oracle會話在伺服器上的pid，然後登陸到伺服器上，執行kill -9 pid這樣就能殺掉進程解鎖了。
⑼ 如何查看MySQL資料庫的死鎖信息
查看MySQL資料庫的死鎖日誌
1. 使用終端或命令提示符登錄到MySQL，輸入命令：mysql -h xxxx.xxx.xxx -P 3306 -u username -p解釋：xxxx.xxx.xxx是資料庫IP地址，username是資料庫用戶名，輸入命令後，會讓你輸入username對應的密碼，就可以登錄了
4. 如何分析日誌，定位死鎖原因看3裡面的圖，紫色劃線部分分析：事務1，等待RECORD LOCKS space id 553 page no 376 n bits 368 index `index_user_id` of table `tbj`.`score_user`，這個位置的X鎖事務2，持有RECORD LOCKS space id 553 page no 376 n bits 368 index `index_user_id` of table `tbj`.`score_user`這個地方的S鎖事務2，等待這個地方的X鎖理論上這個事務2是可以提交的不會，死鎖，但是這個事務日誌只列印最後一部分死鎖，信息，這裡面隱含的條件是，事務1也持有RECORD LOCKS space id 553 page no 376 n bits 368 index `index_user_id` of table `tbj`.`score_user`這個地方的S鎖，這樣，事務2不能加X鎖，同時事務1也不能加X鎖，產生死鎖。