• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            posts - 9, comments - 4, trackbacks - 0, articles - 9

            摘 要:本文討論了Oracle和SQL Server的在事務處理上的區(qū)別,并分析了其實現(xiàn)機制的差異。

            關鍵詞:Oracle;SQL Server;事務;事務隔離級別;DDL。


            事務處理是所有大型數(shù)據(jù)庫產品的一個關鍵問題,各數(shù)據(jù)庫廠商都在這個方面花費了很大精力,不同的事務處理方式會導致數(shù)據(jù)庫性能和功能上的巨大差異。

            事務處理也是數(shù)據(jù)庫管理員與數(shù)據(jù)庫應用程序開發(fā)人員必須深刻理解的一個問題,對這個問題的疏忽可能會導致應用程序邏輯錯誤以及效率低下。

            下面我們針對Oracle及SQL Server這兩種當前廣泛使用的大型數(shù)據(jù)庫產品,探討一下它們在事務處理方面的一些差異。如沒有特殊說明,本文內容適用的數(shù)據(jù)庫產品版本為Oracle9i及SQL Server 2000,其中的示例SQL語句,對于Oracle是在SQL*Plus中執(zhí)行,而對于SQL Server 2000是在osql中執(zhí)行。
            一.事務的概念

            事務可以看作是由對數(shù)據(jù)庫的若干操作組成的一個單元,這些操作要么都完成,要么都取消,從而保證數(shù)據(jù)滿足一致性的要求。事務的一個典型例子是銀行中的轉帳操作,帳戶A把一定數(shù)量的款項轉到帳戶B上,這個操作包括兩個步驟,一個是從帳戶A上把存款減去一定數(shù)量,二是在帳戶B上把存款加上相同的數(shù)量。這兩個步驟顯然要么都完成,要么都取消,否則銀行就會受損失。顯然,這個轉帳操作中的兩個步驟就構成一個事務。

            數(shù)據(jù)庫中的事務還有如下ACID特征。

            ACID分別是四個英文單詞的首寫字母,這四個英文單詞是Atomicity、Consistency、Isolation、Durability,分別翻譯為原子性、一致性、隔離性、持久性。

            原子性:指事務中的操作,或者都完成,或者都取消。

            一致性:指事務中的操作保證數(shù)據(jù)庫中的數(shù)據(jù)不會出現(xiàn)邏輯上不一致的情況,一致性一般會隱含的包括在其他屬性之中。

            隔離性:指當前的事務與其他未完成的事務是隔離的。在不同的隔離級別下,事務的讀取操作,可以得到的結果是不同的。

            持久性:指對事務發(fā)出COMMIT命令后,即使這時發(fā)生系統(tǒng)故障,事務的效果也被持久化了。與此相反的是,當在事務執(zhí)行過程中,系統(tǒng)發(fā)生故障,則事務的操作都被回滾,即數(shù)據(jù)庫回到事務開始之前的狀態(tài)。

            對數(shù)據(jù)庫中的數(shù)據(jù)修改都是在內存中完成的,這些修改的結果可能已經寫到硬盤也可能沒有寫到硬盤,如果在操作過程中,發(fā)生斷電或系統(tǒng)錯誤等故障,數(shù)據(jù)庫可以保證未結束的事務對數(shù)據(jù)庫的數(shù)據(jù)修改結果即使已經寫入磁盤,在下次數(shù)據(jù)庫啟動后也會被全部撤銷;而對于結束的事務,即使其修改的結果還未寫入磁盤,在數(shù)據(jù)庫下次啟動后會通過事務日志中的記錄進行“重做”,即把丟失的數(shù)據(jù)修改結果重新生成,并寫入磁盤,從而保證結束事務對數(shù)據(jù)修改的永久化。這樣也保證了事務中的操作要么全部完成,要么全部撤銷。

            二.事務設置及類型的區(qū)別

            在SQL Server中有三種事務類型,分別是:隱式事務、顯式事務、自動提交事務,缺省為自動提交。

            自動提交,是指對于用戶發(fā)出的每條SQL語句,SQL Server都會自動開始一個事務,并且在執(zhí)行后自動進行提交操作來完成這個事務,也可以說在這種事務模式下,一個SQL語句就是一個事務。

            顯式事務,是指在自動提交模式下以Begin Transaction開始一個事務,以Commit或Rollback結束一個事務,以Commit結束事務是把事務中的修改永久化,即使這時發(fā)生斷電這樣的故障。例如下面是SQL Server中的一個顯式事務的例子。

            Begin Tran

            Update emp Set ename=’Smith’ Where empno=7369

            Insert Into dept Values(60,’HR’,’GZh’)

            Commit

            隱式事務,是指在當前會話中用Set Implicit_Transactions On命令設置的事務類型,這時任何DML語句(Delete、Update、Insert)都會開始一個事務,而事務的結束也是用Commit或Rollback。

            在Oracle中沒有SQL Server的這些事務類型,缺省情況下任何一個DML語句都會開始一個事務,直到用戶發(fā)出Commit或Rollback操作,這個事務才會結束,這與SQL Server的隱式事務模式相似。

            三.事務隔離級別

            在SQL92標準中,事務隔離級別分為四種,分別為:Read Uncommitted、Read Committed、Read Repeatable、Serializable,其中Read Uncommitted與Read Committed為語句級別的,而Read Repeatable與Serializable是針對事務級別的。

            在Oracle和SQL Server中設置事務隔離級別的語句是相同的,都使用SQL92標準語法,即:

            Set Transaction Isolation Level Read Committed

            上面示例中的Read Committed可以被替換為其他三種隔離級別中的任意一種。

            1.SQL Server中的隔離級別及實現(xiàn)機制

            在SQL Server中提供了所有這四種隔離級別。

            下面我們討論在SQL Server中,這幾種隔離級別的含義及其實現(xiàn)方式。

            Read Uncommitted:一個會話可以讀取其他事務未提交的更新結果,如果這個事務最后以回滾結束,這時的讀取結果就可能是錯誤的,所以多數(shù)的數(shù)據(jù)庫應用都不會使用這種隔離級別。

            Read Committed:這是SQL Server的缺省隔離級別,設置為這種隔離級別的事務只能讀取其他事務已經提交的更新結果,否則,發(fā)生等待,但是其他會話可以修改這個事務中被讀取的記錄,而不必等待事務結束,顯然,在這種隔離級別下,一個事務中的兩個相同的讀取操作,其結果可能不同。

            Read Repeatable:在一個事務中,如果在兩次相同條件的讀取操作之間沒有添加記錄的操作,也沒有其他更新操作導致在這個查詢條件下記錄數(shù)增多,則兩次讀取結果相同。換句話說,就是在一個事務中第一次讀取的記錄保證不會在這個事務期間發(fā)生改變。SQL Server是通過在整個事務期間給讀取的記錄加鎖實現(xiàn)這種隔離級別的,這樣,在這個事務結束前,其他會話不能修改事務中讀取的記錄,而只能等待事務結束,但是SQL Server不會阻礙其他會話向表中添加記錄,也不阻礙其他會話修改其他記錄。

            Serializable:在一個事務中,讀取操作的結果是在這個事務開始之前其他事務就已經提交的記錄,SQL Server通過在整個事務期間給表加鎖實現(xiàn)這種隔離級別。在這種隔離級別下,對這個表的所有DML操作都是不允許的,即要等待事務結束,這樣就保證了在一個事務中的兩次讀取操作的結果肯定是相同的。

            2.Oracle中的隔離級別及實現(xiàn)機制

            在Oracle中,沒有Read Uncommitted及Repeatable Read隔離級別,這樣在Oracle中不允許一個會話讀取其他事務未提交的數(shù)據(jù)修改結果,從而避免了由于事務回滾發(fā)生的讀取錯誤。Oracle中的Read Committed和Serializable級別,其含義與SQL Server類似,但是實現(xiàn)方式卻大不一樣。

            在Oracle中,存在所謂的回滾段(Oracle9i之前版本)或撤銷段(Oracle9i版本),Oracle在修改數(shù)據(jù)記錄時,會把這些記錄被修改之前的結果存入回滾段或撤銷段中,就是因為這種機制,Oracle對于事務隔離級別的實現(xiàn)與SQL Server截然不同。在Oracle中,讀取操作不會阻礙更新操作,更新操作也不會阻礙讀取操作,這樣在Oracle中的各種隔離級別下,讀取操作都不會等待更新事務結束,更新操作也不會因為另一個事務中的讀取操作而發(fā)生等待,這也是Oracle事務處理的一個優(yōu)勢所在。

            Oracle缺省的設置是Read Committed隔離級別(也稱為語句級別的隔離),在這種隔離級別下,如果一個事務正在對某個表進行DML操作,而這時另外一個會話對這個表的記錄進行讀取操作,則Oracle會去讀取回滾段或撤銷段中存放的更新之前的記錄,而不會象SQL Server一樣等待更新事務的結束。

            在Serializable隔離級別(也稱為事務級別的隔離),事務中的讀取操作只能讀取這個事務開始之前已經提交的數(shù)據(jù)結果。如果在讀取時,其他事務正在對記錄進行修改,則Oracle就會在回滾段或撤銷段中去尋找對應的原來未經更改的記錄(而且是在讀取操作所在的事務開始之前存放于回滾段或撤銷段的記錄),這時讀取操作也不會因為相應記錄被更新而等待。

            四.DDL語句對事務的影響

            1.Oracle中DDL語句對事務的影響

            在Oracle中,執(zhí)行DDL語句(如Create Table、Create View等)時,會在執(zhí)行之前自動發(fā)出一個Commit命令,并在隨后發(fā)出一個Commit或者Rollback命令,也就是說,DDL會象如下偽碼一樣執(zhí)行:

            Commit;

            DDL_Statement;

            If (Error) then

            Rollback;

            Else

            Commit;

            End if;

            我們通過分析下面例子來看Oracle中,DDL語句對事務的影響:

            Insert into some_table values(‘Before’);

            Creaate table T(x int);

            Insert into some_table values(‘After’);

            Rollback;

            由于在Oracle執(zhí)行Create table語句之前進行了提交,而在Create table執(zhí)行后也會自動發(fā)出Commit命令,所以只有插入After的行被回滾,而插入Before的行不會被回滾,Create table命令的結果也不會被回滾,即使Create table語句失敗,所進行的Before插入也會被提交。如果最后發(fā)出Commit命令,因為插入Before及Create table的操作結果已經在之前提交,所以Commit命令影響的只有插入After的操作。

            2.SQL Server中DDL語句對事務的影響

            在SQL Server中,DDL語句對事務的影響與其他DML語句相同,也就是說,在DML語句發(fā)出之前或之后,都不會自動發(fā)出Commit命令。

            在SQL Server 2000中,對于與上面Oracle同樣的例子,最后發(fā)出Rollback后,數(shù)據(jù)庫會回滾到插入Before之前的狀態(tài),即插入Before和After的行都會被回滾,數(shù)據(jù)表T也不會被創(chuàng)建。

            如果最后發(fā)出Commit操作,則會把三個操作的結果全部提交。

            五.用戶斷開數(shù)據(jù)庫連接對事務的影響

            另外,對應于Oracle的管理客戶端工具SQL*Plus,在SQL Server 2000中是osql,兩種管理工具都是命令行工具,使用方式及作用也類似,但是在SQL*Plus中,用戶退出連接時,會自動先發(fā)出Commit命令,然后再退出,而在osql中,如果用戶退出連接,會自動發(fā)出Rollback命令,這對于SQL Server的自動提交模式沒有什么影響,但如果處于隱式事務模式,其影響是顯而易見的。對于兩種數(shù)據(jù)庫產品的其他客戶端管理工具也有類似的不同之處。

            国内精品久久久久久久久| 狠狠色丁香久久婷婷综合| 2020久久精品国产免费| 国产精品99久久久久久人| 久久青草国产精品一区| 国产精品久久久天天影视香蕉 | 亚洲伊人久久精品影院| 97精品依人久久久大香线蕉97| 久久国产色AV免费观看| 久久国产成人亚洲精品影院| 成人综合久久精品色婷婷| 久久久久久综合一区中文字幕| 久久久久亚洲AV无码去区首| 久久亚洲精品成人av无码网站| 久久99精品国产99久久6| 亚洲精品乱码久久久久久| 色综合久久天天综线观看| 久久精品一区二区| 精品久久久无码人妻中文字幕| 青青青国产成人久久111网站| 久久精品亚洲AV久久久无码| 色综合久久中文色婷婷| 亚洲va久久久噜噜噜久久男同 | 久久久久久久97| 久久精品无码av| 久久免费美女视频| 久久精品国产亚洲精品2020| 中文字幕日本人妻久久久免费| 久久久精品无码专区不卡| 青青草国产成人久久91网| 久久国产精品久久久| 久久精品无码一区二区三区| 国产精品久久久久久搜索| 精品少妇人妻av无码久久| 国产精品一区二区久久不卡| 色综合久久久久无码专区| 漂亮人妻被黑人久久精品| 97超级碰碰碰久久久久| www.久久热| 韩国三级中文字幕hd久久精品| 99久久99久久精品国产|