SQL Server和Oracle資料鎖定比較

資料庫並行訪問，也就是兩個或兩以上使用者同時訪問同一資料，這也是資料庫引擎如何設計和實現適度反應所面臨的最大問題。設計優良、效能卓越的資料庫引擎可以輕鬆地同時為成千上萬的使用者服務。而“底氣不足”的資料庫系統隨著更多的使用者同時訪問系統將大大降低其效能。最糟糕的情況下甚至可能導致系統的崩潰。

當然，並行訪問是任何資料庫解決方案都最為重視的問題了，為瞭解決並行訪問方面的問題各類資料庫系統提出了各種各樣的方案。 SQL Server和Oracle兩大DBMS也分別採用了不同的平行處理方法。它們之間的實質差別在哪裡呢？

並行訪問的問題

並行訪問出現問題存在若干種情況。在最簡單的情形下，數量超過一個的使用者可能同時查詢同一資料。就這種情況而言資料庫的操作目標很簡單：儘可能地為使用者們提供快速的資料訪問。 這對我們現在常見的資料庫來說不成問題：SQL Server和 Oracle 都採用了多線程機制，它們當然能夠一次處理多個請求。

不過，在使用者修改資料的情況下並行訪問問題就變得複雜起來了。顯然，資料庫通常只允許唯一使用者一次修改特定的資料。當某一使用者開始修改某塊資料時， SQL Server和 Oracle 都能很快地鎖定資料，阻止其他使用者對這塊資料進行更新，直到修改該資料的第1位使用者完成其操作並提交交易（commit transaction）。但是，當某一位使用者正在修改某塊資料時假設另一位使用者又正想查詢該資料的資訊時會發生什麼情況呢？在這種情況下資料庫管理系統又該如何動作呢？Oracle 和 SQL Server針對這一問題採取了不同的解決方案。

SQL Server方法

現在不妨假設有人開始修改SQL Server上儲存的資料，於是這塊資料立即被資料庫鎖定。資料鎖定操作阻塞其他任何訪問該資料的串連——連查詢操作都不會放過。於是，這塊被鎖定的資料只有在交易被提交或者復原之後才能接受其他訪問操作。

下面用SQL Server隨帶的pubs樣本資料庫做一個簡單示範。在Query Analyzer內開啟兩個視窗。在第1個視窗中執行下列SQL動作陳述式，更新pubs資料庫中某一圖書的價格：use pubs
go
begin tran
update titles
set price = price * 1.05
where
title_id = 'BU2075'

由於代碼中並沒有執行commit語句，所以資料變動操作實際上還沒有最終完成。接下來，在另一個視窗裡執行下列語句查詢titles資料表：

select title_id,title,price
from titles
order by title_id.

 

你什麼結果也得不到。視窗底部的小地球表徵圖會轉個不停。儘管我在先前的操作中僅僅更新了一行，但是，select語句的執行對象卻恰好包含了其資料正被修改的一行。因此，上面的操作不會返回任何資料，除非回到第1個視窗提交交易或者復原。

SQL Server的資料鎖定方案可能會降低系統的效能和效率。資料被鎖定的時間越長，或者鎖定的資料量越大，其他資料訪問使用者就越可能不得不等待其查詢語句的執行。因此，從程式員的角度來看，對SQL Server編程的時候應該盡量地把交易代碼設計得既小又快。

在SQL Server的最近版本中，微軟對SQL Server進行了某些修改，使其一次鎖定的資料量大大減少，這是資料庫設計中的一大重要改進。在6.5版及以前版本中，最少的資料鎖定量是一頁。哪怕你只在修改一行資料，而該行資料位元於包含10行資料的一頁上，則整頁10行資料都會被鎖定。顯然，這麼大的資料鎖定量增加了其他資料訪問串連不得不等待資料修正完成的機率。在SQL Server 7中，微軟引入了行鎖定技術，這樣，目前的SQL Server只鎖定實際正被改變的資料行。

SQL Server的解決方案聽起來很簡單，但實際上其幕後為提供足夠的系統高效能而採取了很多措施。例如，如果你在同時修改多行資料，SQL Server則會把資料鎖定範圍提升到頁層級乃至鎖定整個資料表，從而不必針對每一記錄跟蹤和維護各自的資料鎖。