資料庫縮容
Ⅰ PL/sql中記錄被另一個用戶鎖住的原因及處理方法
PL/SQL中記錄被另一個用戶鎖住的原因:另一個用戶正在修改或刪除該記錄。此時其它用戶只能做查詢,不能進行刪改操作。如果要解鎖,正在刪改操作的用戶退出刪改狀態即可。
因死機或掛起不能退出刪改狀態時,找到該用戶的進程,kill該進程就可以了。實在不行的話重新啟動資料庫也可以。
處理方法:
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#'
(1)資料庫縮容擴展閱讀
SQL Server中的鎖類型及用法:
從資料庫系統的角度來看:分為獨占鎖(即排它鎖), 共享鎖和更新鎖。MS-SQL Server使用以下資源鎖模式。
鎖模式描述:
共享(S)用於不更改或不更新數據的操作(只讀操作),如SELECT語句。
更新(U)用於可更新的資源中。防止當多個會話在讀取、鎖定以及隨後可能進行的資源更新時發生常見形式的死鎖。
排它(X)用於數據修改操作,例如.INSERT、UPDATE 或DELETE。確保不會同時同一資源進行多重更新。
意向鎖用於建立鎖的層次結構。意向鎖的類型為:意向共享(IS)、意向排它(IX)以及與意向排它共享(SIX)。
架構鎖在執行依賴於表架構的操作時使用。架構鎖的類型為:架構修改(Sch-M)和架構穩定性(Sch-S)。
大容量更新(BU)向表中大容量復制數據並指定了TABLOCK提示時使用。
Ⅱ mysql資料庫的行級鎖有幾種
有兩種模式的行鎖:
1)共享鎖:允許一個事務去讀一行,阻止其他事務獲得相同數據集的排他鎖。
( Select * from table_name where ......lock in share mode)
2)排他鎖:允許獲得排他鎖的事務更新數據,阻止其他事務取得相同數據集的共享讀鎖和 排他寫鎖。(select * from table_name where.....for update)
Ⅲ 資料庫,這題B D 有啥區別X所不是和X鎖以及S鎖都不相容么
基本的封鎖類型有兩種:排它鎖(X鎖)和共享鎖(S鎖).所謂X鎖,是事務T對數據A加上X鎖時,只允許事務T讀取和修改數據A,...所謂S鎖,是事務T對數據A加上S鎖時,其他事務只能再對數據A加S鎖,而不能加X鎖,直到T釋放A上的S鎖
若事務T對數據對象A加了S鎖,則T就可以對A進行讀取,但不能進行更新(S鎖因此又稱為讀鎖),在T釋放A上的S鎖以前,其他事務可以再對A加S鎖,但不能加X鎖,從而可以讀取A,但不能更新A.
Ⅳ 在資料庫中,什麼是鎖的相容性
鎖兼容性控制多個事務能否同時獲取同一資源上的鎖。如果資源已被另一事務鎖定,則僅當請求鎖的模式與現有鎖的模式相兼容時,才會授予新的鎖請求。如果請求鎖的模式與現有鎖的模式不兼容,則請求新鎖的事務將等待釋放現有鎖或等待鎖超時間隔過期。例如,沒有與排他鎖兼容的鎖模式。如果具有排他鎖(X 鎖),則在釋放排他鎖(X 鎖)之前,其他事務均無法獲取該資源的任何類型(共享、更新或排他)的鎖。另一種情況是,如果共享鎖(S 鎖)已應用到資源,則即使第一個事務尚未完成,其他事務也可以獲取該項的共享鎖或更新鎖(U 鎖)。但是,在釋放共享鎖之前,其他事務無法獲取排他鎖。
Ⅳ 網站的資料庫被鎖定,如何打開才能修改資料庫的內容
怎麼鎖的?
只是沒有許可權罷了。
你把EveryOne組加入資料庫,然後給他完全控制許可權。
OK 了!
如果是加密,你找到密碼,然後撤銷密碼。就OK 了!
Ⅵ 用sql語句,怎麼解決mysql資料庫死鎖
MySQL死鎖問題的相關知識是本文我們主要要介紹的內容,接下來我們就來一一介紹這部分內容,希望能夠對您有所幫助。
1、MySQL常用存儲引擎的鎖機制
MyISAM和MEMORY採用表級鎖(table-level locking)
BDB採用頁面鎖(page-level locking)或表級鎖,默認為頁面鎖
InnoDB支持行級鎖(row-level locking)和表級鎖,默認為行級鎖
2、各種鎖特點
表級鎖:開銷小,加鎖快;不會出現死鎖;鎖定粒度大,發生鎖沖突的概率最高,並發度最低
行級鎖:開銷大,加鎖慢;會出現死鎖;鎖定粒度最小,發生鎖沖突的概率最低,並發度也最高
頁面鎖:開銷和加鎖時間界於表鎖和行鎖之間;會出現死鎖;鎖定粒度界於表鎖和行鎖之間,並發度一般
3、各種鎖的適用場景
表級鎖更適合於以查詢為主,只有少量按索引條件更新數據的應用,如Web應用
行級鎖則更適合於有大量按索引條件並發更新數據,同時又有並發查詢的應用,如一些在線事務處理系統
4、死鎖
是指兩個或兩個以上的進程在執行過程中,因爭奪資源而造成的一種互相等待的現象,若無外力作用,它們都將無法推進下去。
表級鎖不會產生死鎖。所以解決死鎖主要還是針對於最常用的InnoDB。
5、死鎖舉例分析
在MySQL中,行級鎖並不是直接鎖記錄,而是鎖索引。索引分為主鍵索引和非主鍵索引兩種,如果一條sql語句操作了主鍵索引,MySQL就會鎖定這條主鍵索引;如果一條語句操作了非主鍵索引,MySQL會先鎖定該非主鍵索引,再鎖定相關的主鍵索引。
在UPDATE、DELETE操作時,MySQL不僅鎖定WHERE條件掃描過的所有索引記錄,而且會鎖定相鄰的鍵值,即所謂的next-key locking。
例如,一個表db。tab_test,結構如下:
id:主鍵;
state:狀態;
time:時間;
索引:idx_1(state,time)
出現死鎖日誌如下:
?***(1) TRANSACTION:
?TRANSACTION 0 677833455, ACTIVE 0 sec, process no 11393, OSthread id 278546 starting index read
?mysql tables in use 1, locked 1
?LOCK WAIT 3 lock struct(s), heap size 320
?MySQL thread id 83, query id 162348740 dcnet03 dcnet Searching rows for update
?update tab_test set state=1064,time=now() where state=1061 and time < date_sub(now(), INTERVAL 30 minute) (任務1的sql語句)
?***(1) WAITING FOR THIS LOCK TO BE GRANTED: (任務1等待的索引記錄)
?RECORD LOCKS space id 0 page no 849384 n bits 208 index `PRIMARY` of table `db/tab_test` trx id 0 677833455 _mode X locks rec but not gap waiting
?Record lock, heap no 92 PHYSICAL RECORD: n_fields 11; compact format; info bits 0
?0: len 8; hex 800000000097629c; asc b ;; 1: len 6; hex 00002866eaee; asc (f ;; 2: len 7; hex 00000d40040110; asc @ ;; 3: len 8; hex 80000000000050b2; asc P ;; 4: len 8; hex 800000000000502a; asc P*;; 5: len 8; hex 8000000000005426; asc T&;; 6: len 8; hex 800012412c66d29c; asc A,f ;; 7: len 23; hex 8616e642e706870; asc xxx.com/;; 8: len 8; hex 800000000000042b; asc +;; 9: len 4; hex 474bfa2b; asc GK +;; 10: len 8; hex 8000000000004e24; asc N$;;
?*** (2) TRANSACTION:
?TRANSACTION 0 677833454, ACTIVE 0 sec, process no 11397, OS thread id 344086 updating or deleting, thread declared inside InnoDB 499
?mysql tables in use 1, locked 1
?3 lock struct(s), heap size 320, undo log entries 1
?MySQL thread id 84, query id 162348739 dcnet03 dcnet Updating update tab_test set state=1067,time=now () where id in (9921180) (任務2的sql語句)
?*** (2) HOLDS THE LOCK(S): (任務2已獲得的鎖)
?RECORD LOCKS space id 0 page no 849384 n bits 208 index `PRIMARY` of table `db/tab_test` trx id 0 677833454 lock_mode X locks rec but not gap
?Record lock, heap no 92 PHYSICAL RECORD: n_fields 11; compact format; info bits 0
?0: len 8; hex 800000000097629c; asc b ;; 1: len 6; hex 00002866eaee; asc (f ;; 2: len 7; hex 00000d40040110; asc @ ;; 3: len 8; hex 80000000000050b2; asc P ;; 4: len 8; hex 800000000000502a; asc P*;; 5: len 8; hex 8000000000005426; asc T&;; 6: len 8; hex 800012412c66d29c; asc A,f ;; 7: len 23; hex 8616e642e706870; asc uploadfire.com/hand.php;; 8: len 8; hex 800000000000042b; asc +;; 9: len 4; hex 474bfa2b; asc GK +;; 10: len 8; hex 8000000000004e24; asc N$;;
?*** (2) WAITING FOR THIS LOCK TO BE GRANTED: (任務2等待的鎖)
?RECORD LOCKS space id 0 page no 843102 n bits 600 index `idx_1` of table `db/tab_test` trx id 0 677833454 lock_mode X locks rec but not gap waiting
?Record lock, heap no 395 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
?0: len 8; hex 8000000000000425; asc %;; 1: len 8; hex 800012412c66d29c; asc A,f ;; 2: len 8; hex 800000000097629c; asc b ;;
?*** WE ROLL BACK TRANSACTION (1)
?(回滾了任務1,以解除死鎖)
原因分析:
當「update tab_test set state=1064,time=now() where state=1061 and time < date_sub(now(), INTERVAL 30 minute)」執行時,MySQL會使用idx_1索引,因此首先鎖定相關的索引記錄,因為idx_1是非主鍵索引,為執行該語句,MySQL還會鎖定主鍵索引。
假設「update tab_test set state=1067,time=now () where id in (9921180)」幾乎同時執行時,本語句首先鎖定主鍵索引,由於需要更新state的值,所以還需要鎖定idx_1的某些索引記錄。
這樣第一條語句鎖定了idx_1的記錄,等待主鍵索引,而第二條語句則鎖定了主鍵索引記錄,而等待idx_1的記錄,這樣死鎖就產生了。
6、解決辦法
拆分第一條sql,先查出符合條件的主鍵值,再按照主鍵更新記錄:
?select id from tab_test where state=1061 and time < date_sub(now(), INTERVAL 30 minute);
?update tab_test state=1064,time=now() where id in(......);
Ⅶ 怎麼知道資料庫表已經鎖表了
可直接在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,可以查詢到具體被鎖的對象。
(7)資料庫縮容擴展閱讀:
注意事項
也可以直接把這幾個視圖和表關聯起來,在查詢結果中直接得到「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這樣就能殺掉進程解鎖了。
Ⅷ 資料庫中意向排他鎖IX和IX是否相容 為什麼 請說明
一. 為什麼要引入鎖
多個用戶同時對資料庫的並發操作時會帶來以下數據不一致的問題:
丟失更新
A,B兩個用戶讀同一數據並進行修改,其中一個用戶的修改結果破壞了另一個修改的結果,比如訂票系統
臟讀
A用戶修改了數據,隨後B用戶又讀出該數據,但A用戶因為某些原因取消了對數據的修改,數據恢復原值,此時B得到的數據就與資料庫內的數據產生了不一致
不可重復讀
A用戶讀取數據,隨後B用戶讀出該數據並修改,此時A用戶再讀取數據時發現前後兩次的值不一致
並發控制的主要方法是封鎖,鎖就是在一段時間內禁止用戶做某些操作以避免產生數據不一致
二 鎖的分類
鎖的類別有兩種分法:
1. 從資料庫系統的角度來看:分為獨占鎖(即排它鎖),共享鎖和更新鎖
MS-SQL Server 使用以下資源鎖模式。
Ⅸ 怎麼理解資料庫的鎖 一般鎖分別哪幾種
資料庫是一個多用戶使用的共享資源。當多個用戶並發地存取數據時,在資料庫中就會產生多個事務同時存取同一數據的情況。若對並發操作不加控制就可能會讀取和存儲不正確的數據,破壞資料庫的一致性。
加鎖是實現資料庫並發控制的一個非常重要的技術。當事務在對某個數據對象進行操作前,先向系統發出請求,對其加鎖。加鎖後事務就對該數據對象有了一定的控制,在該事務釋放鎖之前,其他的事務不能對此數據對象進行更新操作。
在資料庫中有兩種基本的鎖類型:排它鎖(Exclusive Locks,即X鎖)和共享鎖(Share Locks,即S鎖)。當數據對象被加上排它鎖時,其他的事務不能對它讀取和修改。加了共享鎖的數據對象可以被其他事務讀取,但不能修改。資料庫利用這兩種基本的鎖類型來對資料庫的事務進行並發控制。
(9)資料庫縮容擴展閱讀:
排它鎖和共享鎖的不同之處:
1、共享鎖(S鎖):如果事務T對數據A加上共享鎖後,則其他事務只能對A再加共享鎖,不能加排他鎖。獲准共享鎖的事務只能讀數據,不能修改數據。
排他鎖(X鎖):如果事務T對數據A加上排他鎖後,則其他事務不能再對A加任任何類型的封鎖。獲准排他鎖的事務既能讀數據,又能修改數據。
2、共享鎖下其它用戶可以並發讀取,查詢數據。但不能修改,增加,刪除數據,資源共享。
3、共享鎖又稱為讀鎖(Share lock,簡記為S鎖),若事務T對數據對象A加上S鎖,則其它事務只能再對A加S鎖,而不能加X鎖,直到T釋放A上的S鎖。