數據庫是一個多用戶使用的共享資源。當多個用戶併發地存取數據時,在數據庫中就會產生多個事務同時存取同一數據的狀況。若對併發操做不加控制就可能會讀取和存儲不正確的數據,破壞數據庫的一致性。 html
加鎖是實現數據庫併發控制的一個很是重要的技術。當事務在對某個數據對象進行操做前,先向系統發出請求,對其加鎖。加鎖後事務就對該數據對象有了必定的控制,在該事務釋放鎖以前,其餘的事務不能對此數據對象進行更新操做。 sql
在數據庫中有兩種基本的鎖類型:排它鎖(Exclusive Locks,即X鎖)和共享鎖(Share Locks,即S鎖)。當數據對象被加上排它鎖時,其餘的事務不能對它讀取和修改。加了共享鎖的數據對象能夠被其餘事務讀取,但不能修改。數據庫利用這兩種基本的鎖類型來對數據庫的事務進行併發控制。 數據庫
Oracle數據庫的鎖類型 安全
根據保護的對象不一樣,Oracle數據庫鎖能夠分爲如下幾大類:DML鎖(data locks,數據鎖),用於保護數據的完整性;DDL鎖(dictionary locks,字典鎖),用於保護數據庫對象的結構,如表、索引等的結構定義;內部鎖和閂(internal locks and latches),保護 數據庫的內部結構。 session
DML鎖的目的在於保證併發狀況下的數據完整性,。在Oracle數據庫中,DML鎖主要包括TM鎖和TX鎖,其中TM鎖稱爲表級鎖,TX鎖稱爲事務鎖或行級鎖。 併發
當Oracle執行DML語句時,系統自動在所要操做的表上申請TM類型的鎖。當TM鎖得到後,系統再自動申請TX類型的鎖,並將實際鎖定的數據行的鎖標誌位進行置位。這樣在事務加鎖前檢查TX鎖相容性時就不用再逐行檢查鎖標誌,而只需檢查TM鎖模式的相容性便可,大大提升了系統的效率。TM鎖包括了SS、SX、S、X 等多種模式,在數據庫中用0-6來表示。不一樣的SQL操做產生不一樣類型的TM鎖。 oracle
在數據行上只有X鎖(排他鎖)。在Oracle數據庫中,當一個事務首次發起一個DML語句時就得到一個TX鎖,該鎖保持到事務被提交或回滾。當兩個或多個會話在表的同一條記錄上執行 DML語句時,第一個會話在該條記錄上加鎖,其餘的會話處於等待狀態。當第一個會話提交後,TX鎖被釋放,其餘會話才能夠加鎖。 app
當Oracle數據庫發生TX鎖等待時,若是不及時處理經常會引發Oracle數據庫掛起,或致使死鎖的發生,產生ORA-60的錯誤。這些現象都會對實際應用產生極大的危害,如長時間未響應,大量事務失敗等。 ui
悲觀封鎖和樂觀封鎖
1、悲觀封鎖
鎖在用戶修改以前就發揮做用:
Select ..for update(nowait)
Select * from tab1 for update
用戶發出這條命令以後,oracle將會對返回集中的數據創建行級封鎖,以防止其餘用戶的修改。
若是此時其餘用戶對上面返回結果集的數據進行dml或ddl操做都會返回一個錯誤信息或發生阻塞。
1:對返回結果集進行update或delete操做會發生阻塞。
2:對該表進行ddl操做將會報:Ora-00054:resource busy and acquire with nowait specified. 設計
緣由分析
此時Oracle已經對返回的結果集上加了排它的行級鎖,全部其餘對這些數據進行的修改或刪除操做都必須等待這個鎖的釋放,產生的外在現象就是其餘的操做將發生阻塞,這個這個操做commit或rollback.
一樣這個查詢的事務將會對該表加表級鎖,不容許對該表的任何ddl操做,不然將會報出ora-00054錯誤::resource busy and acquire with nowait specified.
2、樂觀封鎖
樂觀的認爲數據在select出來到update進取並提交的這段時間數據不會被更改。這裏面有一種潛在的危險就是因爲被選出的結果集並無被鎖定,是存在一種可能被其餘用戶更改的可能。所以Oracle仍然建議是用悲觀封鎖,由於這樣會更安全。
阻塞
定義:
當一個會話保持另外一個會話正在請求的資源上的鎖定時,就會發生阻塞。被阻塞的會話將一直掛起,直到持有鎖的會話放棄鎖定的資源爲止。4個常見的dml語句會產生阻塞
INSERT
UPDATE
DELETE
SELECT…FOR UPDATE
INSERT
Insert發生阻塞的惟一狀況就是用戶擁有一個建有主鍵約束的表。當2個的會話同時試圖向表中插入相同的數據時,其中的一個會話將被阻塞,直到另一個會話提交或會滾。一個會話提交時,另外一個會話將收到主鍵重複的錯誤。回滾時,被阻塞的會話將繼續執行。
UPDATE 和DELETE當執行Update和delete操做的數據行已經被另外的會話鎖定時,將會發生阻塞,直到另外一個會話提交或會滾。
Select …for update
當一個用戶發出select..for update的錯做準備對返回的結果集進行修改時,若是結果集已經被另外一個會話鎖定,就是發生阻塞。須要等另外一個會話結束以後纔可繼續執行。能夠經過發出 select… for update nowait的語句來避免發生阻塞,若是資源已經被另外一個會話鎖定,則會返回如下錯誤:Ora-00054:resource busy and acquire with nowait specified.
死鎖-deadlock
定義:當兩個用戶但願持有對方的資源時就會發生死鎖.
即兩個用戶互相等待對方釋放資源時,oracle認定爲產生了死鎖,在這種狀況下,將以犧牲一個用戶做爲代價,另外一個用戶繼續執行,犧牲的用戶的事務將回滾.
例子:
1:用戶1對A表進行Update,沒有提交。
2:用戶2對B表進行Update,沒有提交。
此時雙反不存在資源共享的問題。
3:若是用戶2此時對A表做update,則會發生阻塞,須要等到用戶一的事物結束。
4:若是此時用戶1又對B表做update,則產生死鎖。此時Oracle會選擇其中一個用戶進行會滾,使另外一個用戶繼續執行操做。
原由:
Oracle的死鎖問題實際上不多見,若是發生,基本上都是不正確的程序設計形成的,通過調整後,基本上都會避免死鎖的發生。
DML鎖分類表
表1Oracle的TM鎖類型
鎖模式 鎖描述 解釋 SQL操做
0 none
1 NULL 空 Select
2 SS(Row-S) 行級共享鎖,其餘對象
只能查詢這些數據行 Select for update、Lock for
update、Lock row share
3 SX(Row-X) 行級排它鎖,
在提交前不容許作DML操做 Insert、Update、
Delete、Lock row share
4 S(Share) 共享鎖 Create index、Lock share
5 SSX(S/Row-X) 共享行級排它鎖 Lock share row exclusive
6 X(Exclusive) 排它鎖 Alter table、Drop able、Drop index、Truncate table 、Lock exclusive
oracle 鎖問題的解決
能夠用Spotlight軟件對數據庫的運行狀態進行監控。
當出現session鎖時,咱們要及時進行處理.
1. 查看哪些session鎖:
SQL語句:select 'alter system kill session '''||sid||','||serial#||''';' from v$session where sid in (select sid from v$lock where block = 1);
SQL> select 'alter system kill session '''||sid||','||serial#||''';' from v$session where sid in (select sid from v$lock where block = 1);
'ALTERSYSTEMKILLSESSION'''||SID||','||SERIAL#||''';'
--------------------------------------------------------------------------------
alter system kill session '132,731';
alter system kill session '275,15205';
alter system kill session '308,206';
alter system kill session '407,3510';
2. 查看session鎖.
sql語句:select s.sid, q.sql_text from v$sqltext q, v$session s
where q.address = s.sql_address
and s.sid = &sid
order by piece;
SQL> select s.sid,q.sql_text from v$sqltext q, v$session s where q.address = s.sql_address and s.sid in (select sid from v$lock where block = 1) order by piece;
SID SQL_TEXT
---------- ----------------------------------------------------------------
77 UPDATE PROFILE_USER SET ID=1,COMPANY_ID=2,CUSTOMER_ID=3,NAMED
77 _INSURED_ID=4,LOGIN=5,ROLE_ID=6,PASSWORD=7,EMAIL=8,TIME_ZON
77 E=9 WHERE PROFILE_USER.ID=:34
3 rows selected.
3. kill鎖的進程.
SQL語句:alter system kill session '77,22198';
SQL> alter system kill session '391,48398';
System altered.
4. 查看誰鎖了誰。
select s1.username || [email='@']'@'[/email] || s1.machine
|| ' ( SID=' || s1.sid || ' ) is blocking '
|| s2.username || [email='@']'@'[/email] || s2.machine || ' ( SID=' || s2.sid || ' ) ' AS blocking_status
from v$lock l1, v$session s1, v$lock l2, v$session s2
where s1.sid=l1.sid and s2.sid=l2.sid
and l1.BLOCK=1 and l2.request > 0
and l1.id1 = l2.id1
and l2.id2 = l2.id2 ;
注:
> : 重定向輸出,將文件的標準輸出從新定向輸出到文件,或將數據文件做爲另外一程序的標準輸入內容。
| :UNIX管道:將一文件的輸出做爲另外一文件的輸入.
在執行SQL語句試:alter system kill session '391,48398'(sid爲391); 應當注意對於sid在100如下的應當謹慎,可能該進程對應某個application,如對應某個事務,能夠kill.