數據庫並行訪問，也就是兩個或兩以上用戶同時訪問同一數據，這也是數據庫引擎如何設計和實現適度反應所面臨的最大問題。設計優良、性能卓越的數據庫引擎可以輕松地同時為成千上萬的用戶服務。而“底氣不足”的數據庫系統隨著更多的用戶同時訪問系統將大大降低其性能。最糟糕的情況下甚至可能導致系統的崩潰。
當然，並行訪問是任何數據庫解決方案都最為重視的問題了，為了解決並行訪問方面的問題各類數據庫系統提出了各種各樣的方案。 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由於代碼中並沒有執行commit語句，所以數據變動操作實際上還沒有最終完成。接下來，在另一個窗口裡執行下列語句查詢titles數據表：
select title_id,title,price你什麼結果也得不到。窗口底部的小地球圖標會轉個不停。盡管我在先前的操作中僅僅更新了一行，但是，select語句的執行對象卻恰好包含了其數據正被修改的一行。因此，上面的操作不會返回任何數據，除非回到第1個窗口提交交易或者回滾。
SQL Server的數據鎖定方案可能會降低系統的性能和效率。數據被鎖定的時間越長，或者鎖定的數據量越大，其他數據訪問用戶就越可能不得不等待其查詢語句的執行。因此，從程序員的角度來看，對SQL Server編程的時候應該盡量地把交易代碼設計得既小又快。
