數(shù)據(jù)庫并行訪問，也就是兩個或兩以上用戶同時訪問同一數(shù)據(jù)，這也是數(shù)據(jù)庫引擎如何設(shè)計和實現(xiàn)適度反應(yīng)所面臨的最大問題。設(shè)計優(yōu)良、性能卓越的數(shù)據(jù)庫引擎可以輕松地同時為成千上萬的用戶服務(wù)。而“底氣不足”的數(shù)據(jù)庫系統(tǒng)隨著更多的用戶同時訪問系統(tǒng)將大大降低其性能。最糟糕的情況下甚至可能導(dǎo)致系統(tǒng)的崩潰。 當然，并行訪問是任何數(shù)據(jù)庫解決方案都最為重視的問題了，為了解決并行訪問方面的問題各類數(shù)據(jù)庫系統(tǒng)提出了各種各樣的方案。 SQL Server和Oracle兩大DBMS也分別采用了不同的并行處理方法。它們之間的實質(zhì)差別在哪里呢？ 并行訪問的問題 并行訪問出現(xiàn)問題存在若干種情況。在最簡單的情形下，數(shù)量超過一個的用戶可能同時查詢同一數(shù)據(jù)。就這種情況而言數(shù)據(jù)庫的操作目標很簡單：盡可能地為用戶們提供快速的數(shù)據(jù)訪問。 這對我們現(xiàn)在常見的數(shù)據(jù)庫來說不成問題：SQL Server和 Oracle 都采用了多線程機制，它們當然能夠一次處理多個請求。 不過，在用戶修改數(shù)據(jù)的情況下并行訪問問題就變得復(fù)雜起來了。顯然，數(shù)據(jù)庫通常只答應(yīng)唯一用戶一次修改特定的數(shù)據(jù)。當某一用戶開始修改某塊數(shù)據(jù)時， SQL Server和 Oracle 都能很快地鎖定數(shù)據(jù)，阻止其他用戶對這塊數(shù)據(jù)進行更新，直到修改該數(shù)據(jù)的第1位用戶完成其操作并提交交易（commit transaction）。但是，當某一位用戶正在修改某塊數(shù)據(jù)時假設(shè)另一位用戶又正想查詢該數(shù)據(jù)的信息時會發(fā)生什么情況呢？在這種情況下數(shù)據(jù)庫治理系統(tǒng)又該如何動作呢？Oracle 和 SQL Server針對這一問題采取了不同的解決方案。 SQL Server方法 現(xiàn)在不妨假設(shè)有人開始修改SQL Server上存儲的數(shù)據(jù)，于是這塊數(shù)據(jù)立即被數(shù)據(jù)庫鎖定。數(shù)據(jù)鎖定操作阻塞其他任何訪問該數(shù)據(jù)的連接——連查詢操作都不會放過。于是，這塊被鎖定的數(shù)據(jù)只有在交易被提交或者回滾之后才能接受其他訪問操作。 下面用SQL Server隨帶的pubs示例數(shù)據(jù)庫做一個簡單示范。在Query Analyzer內(nèi)打開兩個窗口。在第1個窗口中執(zhí)行下列SQL操作語句，更新pubs數(shù)據(jù)庫中某一圖書的價格： use pubs go begin tran update titles set price = price * 1.05 where title_id = 'BU2075' 由于代碼中并沒有執(zhí)行commit語句，所以數(shù)據(jù)變動操作實際上還沒有最終完成。接下來，在另一個窗口里執(zhí)行下列語句查詢titles數(shù)據(jù)表： select title_id,title,price from titles order by title_id.你什么結(jié)果也得不到。窗口底部的小地球圖標會轉(zhuǎn)個不停。盡管我在先前的操作中僅僅更新了一行，但是，select語句的執(zhí)行對象卻恰好包含了其數(shù)據(jù)正被修改的一行。因此，上面的操作不會返回任何數(shù)據(jù)，除非回到第1個窗口提交交易或者回滾。 SQL Server的數(shù)據(jù)鎖定方案可能會降低系統(tǒng)的性能和效率。數(shù)據(jù)被鎖定的時間越長，或者鎖定的數(shù)據(jù)量越大，其他數(shù)據(jù)訪問用戶就越可能不得不等待其查詢語句的執(zhí)行。因此，從程序員的角度來看，對SQL Server編程的時候應(yīng)該盡量地把交易代碼設(shè)計得既小又快。 在SQL Server的最近版本中，微軟對SQL Server進行了某些修改，使其一次鎖定的數(shù)據(jù)量大大減少，這是數(shù)據(jù)庫設(shè)計中的一大重要改進。在6.5版及以前版本中，最少的數(shù)據(jù)鎖定量是一頁。哪怕你只在修改一行數(shù)據(jù)，而該行數(shù)據(jù)位于包含10行數(shù)據(jù)的一頁上，則整頁10行數(shù)據(jù)都會被鎖定。顯然，這么大的數(shù)據(jù)鎖定量增加了其他數(shù)據(jù)訪問連接不得不等待數(shù)據(jù)修正完成的概率。在SQL Server 7中，微軟引入了行鎖定技術(shù)，這樣，目前的SQL Server只鎖定實際正被改變的數(shù)據(jù)行。 SQL Server的解決方案聽起來很簡單，但實際上其幕后為提供足夠的系統(tǒng)高性能而采取了很多措施。例如，假如你在同時修改多行數(shù)據(jù)，SQL Server則會把數(shù)據(jù)鎖定范圍提升到頁級別乃至鎖定整個數(shù)據(jù)表，從而不必針對每一記錄跟蹤和維護各自的數(shù)據(jù)鎖。 Oracle方法 下面我們再看看Oracle數(shù)據(jù)庫是如何實施類似操作的。首先，我打開一個SQLPlus實例執(zhí)行下列查詢語句（這個例子可以在Oracle 9i中示例中找到）。這個實例稱做查詢實例： select first_name, last_name, salary from hr.employees where department_id = 20; 代碼返回兩行數(shù)據(jù)，然后，再打開另一個SQLPlus實例——更新實例來執(zhí)行以下命令： SQL> update hr.employees 2 set salary = salary * 1.05 3 where 4 department_id = 20 5 / 代碼執(zhí)行后回復(fù)消息稱兩行數(shù)據(jù)已被更新。 注重，以上代碼中并每有像在SQL Server示例那樣鍵入“begin tran”字樣的代碼。Oracle 的SQLPlus隱含啟用交易（你還可以模擬SQL Server的行為，設(shè)置“autocommit to on”自動地提交交易）。接下來我們在SQLPlus更新實例中再執(zhí)行同查詢實例一樣的select語句。 結(jié)果清楚地表明：Michael和Pat的薪水都增加了，然而這個時候我還沒有提交數(shù)據(jù)變更交易。Oracle不需要用戶等待數(shù)據(jù)更新實例中操作被提交，它徑直返回Michael和Pat的查詢信息，但實際上返回的是數(shù)據(jù)更新開始之前的數(shù)據(jù)視圖！ 這時候，熟悉SQL Server的人可能會說了，在查詢中設(shè)置（NOLOCK）不也能達到同樣的效果嗎？可是，對SQL Server而言，在數(shù)據(jù)映像之前是不能獲取數(shù)據(jù)的。指定（NOLOCK）實際上只是得到了沒有提交的數(shù)據(jù)。Oracle的方法則提供了數(shù)據(jù)的一致視圖，所有的信息都是針對交易的、基于存儲數(shù)據(jù)快照的。 假如在SQLPlus的更新實例中提交更新交易在查詢實例中就能看到薪水數(shù)據(jù)發(fā)生變化。假如在查詢實例中重新運行先前的查詢語句，那么Oracle將返回新的薪水數(shù)值。 存儲數(shù)據(jù)快照 說了半天，在給用戶顯示先前版本的數(shù)據(jù)同時，Oracle是如何答應(yīng)其他用戶修改數(shù)據(jù)的呢？其實，只要某一用戶啟動了一宗修改數(shù)據(jù)的交易，之前的數(shù)據(jù)映像就會被寫到一個非凡的存儲區(qū)域。這種“前映像”用來向任何查詢數(shù)據(jù)的用戶提供一致的數(shù)據(jù)庫視圖。這樣，當其他用戶在修改數(shù)據(jù)的時候，在以上的測試中我們就能看到尚未發(fā)生變更的薪金數(shù)據(jù)。 這個非凡的存儲區(qū)域在哪里呢？這個問題的答案就跟你正在使用的Oracle版本有關(guān)了。在 Oracle 8i及其以前版本中會為這一目的創(chuàng)建非凡的回滾段。然而，這種舉措會給數(shù)據(jù)庫治理員（DBA）帶來治理和調(diào)整數(shù)據(jù)段的工作負擔。例如，DBA必須確定為此需要的數(shù)據(jù)段的數(shù)量以及大小等。假如回滾段沒有正確配置，那么對交易而言它們就可能不得不排隊等待回滾段中出現(xiàn)必要的數(shù)據(jù)空間。 Oracle 9i就不同了，這是Oracle的最新版本，Oracle實現(xiàn)了一種新特性，這就是所謂的undo表空間，它有效地消除了以上的治理復(fù)雜性。雖然回滾段仍然可以繼續(xù)使用，但是，DBA現(xiàn)在可以選擇創(chuàng)建undo表空間的方式令Oracle自己治理“前映像”的復(fù)雜空間分配。 Oracle的這種方法對程序員具有重要意義。因為回滾空間不是無限的，所以，更新交易的數(shù)據(jù)快照會取代先前交易的映像。因此，假如必要的回滾段被其他交易的映像覆蓋的話。運行時間較長的查詢操作就可能產(chǎn)生“ snapshot too old”錯誤。 下面舉個可能發(fā)生的案例。假設(shè)在上午11:59的時候某位職員開始更新John Doe帳務(wù)的交易。這宗交易在下午12:01被提交。同時，下午12:00某財務(wù)經(jīng)理開始查詢所有的客戶帳務(wù)報表和當月收費總計。因為客戶很多，所以這一查詢操作很費了點時間，但是不論這次操作到底執(zhí)行了多久，反正它檢索出的結(jié)果就是下午12:00數(shù)據(jù)庫中存在的數(shù)據(jù)。假如包含John Doe帳務(wù)前映像的回滾空間在查詢執(zhí)行到該客戶名字的時候被覆蓋則查詢返回錯誤消息。 Oracle的解決方案當然更為合理，在抽象意義上提供了相比SQL Server更佳的數(shù)據(jù)一致性。在執(zhí)行Oracle查詢的時候無須擔心較長的查詢操作會鎖定重要的交易。但是，在兩種數(shù)據(jù)庫同時支持海量用戶的情況下也很難證實Oracle是否就能真正實現(xiàn)具體條件下的數(shù)據(jù)一致性。