以下的文章主要是對Oracle事務(wù)管理的相關(guān)問題的研討，由于其中包括Oracle是如何對相關(guān)的sql語句進(jìn)行執(zhí)行，Oracle事務(wù)管理的并發(fā)與恢復(fù)控制的？以下就是正文的主要內(nèi)容的介紹，希望你會有所收獲。

1.Oracle對一條sql語句的執(zhí)行是怎么Oracle事務(wù)管理并發(fā)和恢復(fù)控制的？

一條符合語法的sql語句，定義了對數(shù)據(jù)庫的操作。此操作執(zhí)行的時刻，對應(yīng)了數(shù)據(jù)庫的一個數(shù)據(jù)狀態(tài)。可以這樣理解這個狀態(tài)：到此執(zhí)行時刻為止，沒有任何數(shù)據(jù)庫語句級操作正在并發(fā)執(zhí)行;就是說實際上正在并發(fā)執(zhí)行的多個語句級操作可以假定在此語句操作之后執(zhí)行。

這里強(qiáng)調(diào)語句級操作，是指如果一個事務(wù)包含多個操作語句，在此時刻實際已經(jīng)執(zhí)行了其中幾個，此時刻也正在執(zhí)行某一個語句，那么不能簡單地認(rèn)為前面幾個執(zhí)行的操作語句也還沒發(fā)生，這是要看事務(wù)的隔離級別的，但是不管事務(wù)隔離級別是幾級，語句級別上可以認(rèn)為是序列執(zhí)行的。

該sql語句的操作過程中認(rèn)為此數(shù)據(jù)狀態(tài)是保持不變的。當(dāng)此操作執(zhí)行結(jié)束時刻，才產(chǎn)生語句級數(shù)據(jù)狀態(tài)影響。

就是說，可能該語句同時更新了兩行，但都用了同一個主鍵，則此時會導(dǎo)致違反唯一性約定而消除整個語句的影響，如果成功執(zhí)行，但未必就在事務(wù)級別上影響數(shù)據(jù)狀態(tài)，就是說如果所在事務(wù)回滾，此影響仍然被消除，不過正如前面所說，一個語句成功執(zhí)行后，就可能影響其他語句所面對的數(shù)據(jù)狀態(tài)。

2.PL/SQL的執(zhí)行是怎么管理并發(fā)和恢復(fù)控制的？

PL/SQL是在一個PL/SQL引擎中執(zhí)行的。該引擎可以認(rèn)為是Oracle之外的單位。該引擎會解析PL/SQL，并不斷發(fā)送SQL語句給Oracle。所以和用JAVA程序通過JDBC在一個會話連接中發(fā)送多個SQL語句沒有本質(zhì)差別。也因此并發(fā)和恢復(fù)Oracle事務(wù)管理沒有不同。

3.Oracle死鎖是怎么樣產(chǎn)生的？

Oracle控制并發(fā)是使用的鎖機(jī)制，也因此即會產(chǎn)生死鎖問題。Oracle在執(zhí)行一個語句時，會根據(jù)語句的含義，同時根據(jù)所處的事務(wù)隔離級別，解析出需要加什么樣的鎖，什么時候釋放。而隔離級別越高，對鎖資源占用越大。

現(xiàn)在考慮這樣的情形，Oracle同時處理兩個事務(wù)A,B。A發(fā)過來幾條語句，導(dǎo)致Oracle加了幾把鎖沒有釋放，B發(fā)過來幾條語句，導(dǎo)致Oracle加了另外幾把鎖沒有釋放，現(xiàn)在，A又發(fā)過來一個語句，此語句要求Oracle加的一些鎖中，有幾個鎖已經(jīng)被B事務(wù)占用，那么A等待，而B又發(fā)過來一條語句，此語句要求Oracle加的鎖，在A手中。

于是死鎖出現(xiàn)。而隔離級別越高，死鎖的可能性越大。可以分析出來，死鎖的根本原因在于，事務(wù)包含的語句是分條發(fā)給Oracle的，Oracle不能夠在事務(wù)開始時刻就解析出全部執(zhí)行過程需要什么鎖，什么時候釋放，無法統(tǒng)一安排。

死鎖問題歸咎由誰呢？我這么理解：如果沒有事務(wù)概念，Oracle在語句級上控制并發(fā)，完全不會出現(xiàn)死鎖問題。因為在解析語句時，Oracle已經(jīng)知道要加多少把鎖，它會看目前這些鎖如果能全部獲得就執(zhí)行，否則就等待。

可是實際應(yīng)用怎么能沒有事務(wù)的概念呢？我同意完全可以出現(xiàn)新的sql語法，可以把原來的多條sql語句的含義在一個語句中定義完畢，長短不是問題，犧牲一定的語法簡潔度也不是問題;然而最關(guān)鍵的是往往我們是在一個業(yè)務(wù)處理邏輯中，多個數(shù)據(jù)庫操作之間摻雜了其他非數(shù)據(jù)庫操作，而又想獲取這些數(shù)據(jù)庫操作作為一個整體的ACID。

因此事務(wù)概念必須存在。既然如此，或許我們真得可以把一個事務(wù)可能包含的語句在事務(wù)開始時就交給Oracle，盡管這樣一來，有可能就包含了實際通過業(yè)務(wù)邏輯判斷不會執(zhí)行的語句，導(dǎo)致Oracle浪費鎖，降低并發(fā)處理能力。

我之前的文章曾經(jīng)介紹過用JAVA實現(xiàn)同步控制，降低Oracle隔離級別，只利用Oracle的原子性支持。這樣做的原因就在上文中基本提到了。我們在編寫JAVA業(yè)務(wù)邏輯時，是知道我們需要在一串業(yè)務(wù)邏輯中操作多少次數(shù)據(jù)庫的，也因此，能夠在業(yè)務(wù)邏輯開始時就控制得到所有的鎖再執(zhí)行。

這樣做確實能夠降低Oracle壓力，并消除死鎖問題，然而這樣做會導(dǎo)致同步壓力集中到JAVA應(yīng)用端，而且對研發(fā)人員要求也會提高。盡管如此，在JAVA應(yīng)用端使用同步要靈活很多，而不必限制在表鎖行鎖，你甚至可以建一個森林結(jié)構(gòu)的信號量數(shù)據(jù)來控制同步。

呵呵，反過來也可以理解Oracle事務(wù)管理隔離級別的問題，為什么要存在允許幻像讀的隔離級別呢？隔離級別的存在是一種權(quán)衡，如果應(yīng)用既不想自己控制并發(fā)，又想提高并發(fā)能力，則需要好好權(quán)衡一下吧！

文章出自: http://www.programbbs.com/doc/3298.htm

【編輯推薦】

1. 對Oracle 性能工具的關(guān)注
2. LTO歸檔解決方案容量、性能和功能介紹
3. Oracle數(shù)據(jù)庫的“狂大”的緣由
4. Oracle密碼忘記的解決方法
5. Oracle EM管理 MySQL的實操方案