設計優良、性能卓越的數據庫引擎可以輕松地同時為成千上萬的用戶服務。而“底氣不足”的數據庫系統隨著更多的用戶同時訪問系統將大大降低其性能。最糟糕的情況下甚至可能導致系統的崩潰。
當然，並行訪問是任何數據庫解決方案都最為重視的問題了，為了解決並行訪問方面的問題各類數據庫系統提出了各種各樣的方案。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則會把數據鎖定范圍提升到頁級別乃至鎖定整個數據表，從而不必針對每一記錄跟蹤和維護各自的數據鎖。
