SQL Server 2005 體系結構 1. SQL Server 引擎概述SQL Server有四大組件：協議（Protocol）、關系引擎（Relational Engine）（又稱查詢處理器（Query Processor））、存儲引擎（Storage Engine）和SQLOS。任何客戶端應用程序提交給SQL Server執行的每一個批處理（Batch）都必須與這四個組件進行交互。
1.1 協議組件：負責接收請求並把它們轉換成關系引擎能夠識別的形式。它還能夠獲取任意查詢、狀態信息、錯誤信息的最終結果，然後把這些結果轉換成客戶端能夠理解的形式，最後再把它們返回到客戶端。
1.2 關系引擎組件：負責接受SQL批處理然後決定如何處理它們。對T-SQL查詢和編程結構，關系引擎層可以解析、編譯和優化請求並檢查批處理的執行過程。如果批處理被執行時需要數據，它會發送一個數據請求到存儲引擎。
1.3 存儲引擎組件：負責管理所有的數據訪問，包括基於事務的命令（Transaction-based command）和大批量操作（Bulk Operation）。這些操作包括備份、批量插入和某些數據庫一致性檢查（Database Consistency Checker，DBCC）命令。
1.4 SQLOS組件：負責處理一些通常被認為是操作系統職責的活動，例如線程管理（調度），同步單元（Synchronization Primitive），死鎖檢測和包括緩沖池(Buffer Pool)的內存管理。
圖-1 SQL Server數據庫引擎的主要組件
1.5 如何觀測數據庫引擎行為: SQL Server 2005引入了一套新的系統對象。它們使開發人員和數據庫管理員能夠觀測到以前所無法觀測到的很多SQL Server的內部信息。這些元數據被稱為動態管理視圖(DMV)和動態管理函數（DMF）。DMV和DMF不是基於真實存在於數據庫文件中的表，而是基於SQL Server的一些內部結構，它們都存在於系統架構(sys schema)中，其名字都以dm_開頭，後面跟著標明該對象功能類別的代碼。下面列出一些常用類別：
■ dm_exec_* 包含與用戶代碼執行和相關數據庫連接直接或間接相關的信息。
■ dm_os_* 包含如存儲、鎖和調度等系統底層信息。
■ dm_tran_* 包含當前事務的細節信息。
■ dm_io_* 跟蹤網絡和磁盤上的輸入輸出活動。
■ dm_db_* 包含數據庫和數據庫對象例如索引的細節信息。
2. SQL Server 引擎概述 2.1 協議組件概述當一個應用程序與SQL Server數據庫引擎通訊時，協議層提供的應用程序編程接口利用微軟定義的表格格式數據流（Tabular Data Stream ，TDS) 信息包來規范通訊格式。在服務器和客戶端上都有可供使用的網絡庫（Net-LibrarIEs），它可以用來把TDS信息包封裝為標准的通信協議（例如TCP/IP和命名管道）信息包。在通信的服務器端，網絡庫是數據庫引擎的一部分，該協議層在圖1中有所描述。在通信的客戶端，網絡庫是SQL Native ClIEnt協議的一部分。客戶端和SQL Server實例的配置決定了實際使用哪一種協議。可用的協議有以下幾種：
■ 共享內存 這是最簡單的協議，無須配置。
■ 命名管道 為局域網(LAN)而開發的協議。
■ TCP/IP 因特網上使用最為廣泛的協議。
■ 虛擬接口適配器 (VIA) 它是一種與VIA硬件一起使用的專門化的協議。
2.2 關系引擎組件概述關系引擎又稱為查詢處理器。它包括用來確定某個查詢所需要做的操作以及進行這些操作最佳方式的SQL Server組件。關系引擎也負責當其向存儲引擎請求數據時查詢的執行，並處理返回的結果。關系引擎和存儲引擎之間的通訊一般以OLE DB行集的形式進行。（行集是OLE DB術語，等同於結果集。
$False$
）關系引擎包含有以下子組件：
2.2.1 命令解析器
命令解析器處理發送給SQL Server的T-SQL語言事件。它可以檢查T-SQL語法的正確性並把其翻譯為可以執行的內部格式。這種內部格式稱為查詢樹。
2.2.2 查詢優化器
查詢優化器從命令解析器獲得查詢樹，並為它的實際執行作准備。不能優化的語句例如控制流和DDL命令將會被編譯成一種內部格式。可優化的語句會被標記並隨後傳送給優化器。查詢優化器主要關注DML語句，包括：SELECT, INSERT,UPDATE和DELETE。這些語句可以有多種處理方式，由查詢優化器來判斷哪種處理方式是最佳的。查詢優化器將編譯整個批命令，優化可以優化的查詢並檢查安全性。查詢優化和編譯的結果就是一個執行計劃。
2.2.3 SQL 管理器
SQL 管理器負責管理與存貯過程及其執行計劃有關的一切事務。它會判斷什麼時候一個執行計劃需要重新編譯，並管理存儲過程的緩沖區以便其它進程能夠重用這些緩沖區。SQL管理器也負責管理查詢的自動參數化。在SQL Server 2005中，某些定制的查詢會被視為參數化的存儲過程，SQL Server會為這些查詢生成並保存執行計劃。但是在一些情況下復用保存的執行計劃也許並不合時宜，從而需要重新編譯該執行計劃。
2.2.4 數據庫管理器
數據庫管理器管理查詢編譯和查詢優化所需的對元數據的訪問，這使我們可以看清其實所有這些單獨的模塊都不能完全脫離其它模塊來運行。元數據被作為數據存儲並由存儲引擎來進行管理，但是某些元數據要素例如各數據列的數據類型和一張表上可用的索引必須在實際的查詢執行開始之前就能夠訪問。
2.2.5 查詢執行器
查詢執行器運行查詢優化器生成的執行計劃，它就像一個調度員負責調度執行計劃中的所有命令。該模塊逐步地運行執行計劃中的每一個命令直到該批命令結束。其中大多數命令都需要與存儲引擎進行交互來修改或取回數據以及管理事務和鎖。
2.3存儲引擎組件概述
傳統上認為SQL Server 存儲引擎包括了與處理數據庫中數據有關的所有組件。SQL Server 2005從全部這些組件中抽出一些組成一個稱為SQLOS的模塊。實際上，微軟SQL Server存儲引擎團隊的工作可以分為三個領域：存取方法，事務管理和SQLOS。
2.3.1存取方法
當SQL Server需要定位數據時，它會調用存取方法代碼。存取方法代碼創建和請求對數據頁面和索引頁面進行掃描，並且准備好OLE DB數據行集來返回給關系引擎。類似地當插入數據時，存取方法代碼可以從客戶端取回一個OLE DB數據行集。存取方法代碼包含有用來打開一張表，取回合格的數據和更新數據的所有組件。存取方法代碼並不真正取回數據頁面。它向緩沖區管理器發出請求，緩沖區管理器負責最終從緩沖區中提供數據或者從磁盤上把數據讀到緩沖區中。當掃描開始後，有一種預查機制會檢查一個數據頁上的數據行和索引項是否合格。取出符合指定標准的數據的過程稱為“有效取出”。存取方法代碼不僅被用於查詢（select）操作，還被用於有效的更新和刪除操作（例如，含有WHERE子句的UPDATE語句）以及需要對索引項進行修改的任何數據修改操作。
2.3.2事務服務
SQL Serve的一個核心特性就是它能夠保證事務的原子性—那就是一個事務要麼全部做完，要麼干脆不做。另外，事務必須是持久的，也就是說如果一個事務已經被提交了，SQL Server必須做到不論在什麼情況下（即使是整個系統在該事務提交生效之後1毫秒就出故障了）也能夠恢復該事務。實際上一個事務要同時具備四種我們稱之為ACID的屬性：原子性、持續性、隔離性和持久性。
2.3.2 SQLOS
SQL Server 2005之前的SQL Server版本在存儲引擎和實際的操作系統之間有一層很薄的接口層，SQL Server通過該接口層向操作系統申請分配內存，調度資源，管理進程和線程以及同步對象。但是訪問該層所需要的服務可以分布在SQL Server引擎的任意部分中。現在SQL Server2005對內存管理，調度器和對象同步等的需求已經變得更加復雜了。SQL Server沒有對其引擎中所有涉及訪問操作系統的部分分別進行增強來支持功能的增長，而是選擇了將所有需要訪問操作系統的服務歸為一組並納入單個功能單元，該單元我們稱之為SQLOS。總的來講SQLOS就像SQL Server內部的操作系統。
它提供了內存管理，工作調度，IO管理，鎖和事務管理的框架，死鎖探測，還有包括副本制作，例外處理等各種通用功能。
3 調度器調度器是SQLOS的一個重要組成部分。在SQL Server 7.0之前，調度完全依賴於底層的Windows操作系統。雖然這意味著SQL Server能夠利用Windows工程師辛勤工作的成果來增強產品的可擴展性和CPU的利用率，但它也有一些局限。因為Windows調度程序對關系數據庫系統的需求一無所知，因此它如同對待任何其它運行在系統上的進程一樣對待SQL Server工作線程。不過像SQL Server這樣對性能有很高要求的系統只有當調度程序能夠滿足其特殊需要的情況下才會有最佳表現。在SQL Server 7.0和SQL Server 2000中，由於調度器主要是運行在用戶模態而非核心模態，所以被稱為用戶模式調度器（UMS）。SQL Server 2005的調度器稱為SOS調度器，它相對UMS有很多的改進。
SQL Server調度器不論是UMS還是SOS，和Windows調度器最主要的區別是SQL Server調度器是作為一個協作的而非先入為主的調度器。這意味著依賴於工作線程或纖程自發生成的調度器常常已經足夠使用，所以一個SQL Server進程或纖程不會像Windows進程那樣有時會獨占系統資源。
3.1 SQL Server 工作程 可以認為SQL Server調度器是SQL Server工作程使用的一個邏輯CPU。該工作程可以是一個線程也可以是一個綁定到邏輯調度器的的纖程。如果設置了關聯掩碼選項，每個調度器都與某個CPU相關聯。因此，每個工作程也都會與單個CPU相關聯，每個調度器被指派的工作程數目極限取決於所設置的最大工作線程（Max Worker Threads）和調度器的數量，每個調度器跟據需要負責創建和銷毀工作程。一個工作程不能從一個調度器轉移到另一個調度器，但是通過創建和銷毀工作程，可以使得工作程看起來能夠在調度器之間遷移。調度器收到請求（執行某個任務）並且沒有空閒工作程存在時會創建新的工作程。一個工作程如果空閒時間超過15分鐘或者SQL Server內存緊張，就可能被銷毀。每個工作程在32位系統中至少可以使用0.5MB內存，在64位操作系統中至少可以使用2MB內存。所以銷毀多個工作程並釋放它們所占用的內存在內存緊張的系統上可以收到立桿見影的性能改善。
<BR>
3.2 SQL Server調度器 在SQL Server 2005中，每個CPU(不論是超線程還是物理CPU)都會在SQL Server啟動時創建一個線程。即使是在關聯掩碼選項的設置是SQL Server 不能使用全部的可用CPU時，該啟動線程也會被創建。在SQL Server 2005中，每個調度器的狀態或者是聯機或者是離線，具體設置取決於關聯掩碼的設置。在缺省情況下，所有的調度器都是聯機的。通過設置關聯掩碼我們可以改變調度器的狀態為離線，並且該設置不需要重啟SQL Server即可生效。
3.3 SQL Server 任務 SQL Server工作程的單位是請求或者說是任務，我們可以將其視為與從客戶端到服務器的單個批處理等價。一旦SQL Server收到一個請求，該請求會被綁定到一個工作程，這個工作程會在處理其它別的請求之前處理整個請求。即使出於某種原因，比如等待I/O完成和鎖資源該請求被阻塞也是這樣。這個特殊的工作程不會處理任何別的新請求，但是會等待直到阻塞條件消除和請求完成。需要注意的是SPID(會話ID)並不與任務相同。一個SPID是一個連接或者通道，通過它請求可以被送出，但是並不是任意某個SPID都有活動的請求。
在SQL Server 2000中，創建連接後每個SPID都分配有一個調度器，並且所有通過同樣的SPID送出的請求由同一個調度器來負責調度。是否分配一個SPID給一個調度器取決於已經分配給該調度器的SPID的數量，新的SPID會被分配給當前用戶最少的調度器。雖然這提供了初步的負載均衡形式，但它卻未考慮那些完全不活動和那些有著巨大工作量（如數據裝載）的SPID。在SQL Server 2005中，一個SPID並不會綁定到一個特定的調度器。每個SPID有一個優先調度器，該調度器就是該SPID最新請求服務過的調度器。開始時SPID會被分配給負載最輕的調度器（可以通過查看在DMV dm_os_scheduler的load_factor列來了解每個調度器的負載狀況）。然而，當該SPID發出後續的請求時，如果另一個調度器的負載系數小於所有調度器負載系數均值的一定百分比，新任務會被分配給有著最小負載系數的調度器。
3.4 線程與纖程 就像前面提到的那樣，用戶模態調度器的設計用途是與運行在線程或纖程上的工作程一起工作。Windows纖程相關的開銷比線程要小，多個纖程可以運行在單個線程上。
可以通過設置Lightweight Pooling 選項的值為1來使SQL Server運行在纖程模式。但是當SQL Server運行在纖程模式時，SQL Server的某些組件不能工作或不能工作的很好。這些組件包括SQLMail和SQLXML。其它組件如異構查詢和CLR查詢在纖程模式下根本不被支持，因為它們需要Windows提供的某些線程專有的功能。雖然SQL Server可以切換到線程模式來處理需要該模式的請求，但是引起的開銷有可能比使用純線程模式的開銷還要大。纖程模式實際上是為了某些特殊場合和情況而設計的，在這些場合裡由於花費太多的時間聯機程上下文和用戶模態與核心模態之間進行切換，SQL Server的可擴展性達到極限。在大多數環境裡，使用纖程對性能的提升與對其它方面進行調優所帶來的性能改善相比相當有限。即使能夠確定我們所遇到的境況需要使用纖程，也還是需要在生產服務器上設置該選項之前對它進行徹底地測試。
3.5 動態關聯在SQL Server 2005中（除了SQLExpress之外的所有版本），可以動態地控制處理器關聯。當SQL Server啟動時，所有的調度器任務都開始執行，所以每個CPU都有一個調度器。如果已經設置了關聯掩碼，其中一些調度器會被標示為離線，也不會有任務分配給它們。當改變關聯掩碼來包括額外的CPU時，新的CPU會上線。調度器監視器隨後會注意到負載的不均衡並開始將工作程遷移到新的CPU。當通過改變關聯掩碼來使一個CPU下線，那個CPU的調度器會繼續運行活動的工作程，但調度器自身會遷移到其它仍然聯機的CPU上。不會有新的工作程被分配給這個已經離線的調度器，當所有活動的工作程都完成後，調度器就會停止。
3.6綁定調度器到CPU 需要記住正常情況下調度器並不是按照嚴格的一比一的關系綁定到CPU上，即使調度器的數量同CPU的數量一樣多。調度器只有在設置了關聯掩碼後才會綁定到CPU。對一個八處理器的計算機，關聯掩碼的值為3（比特串為00000011）意味著只會使用CPU 0和1，並且將會有兩個調度器綁定到這兩個CPU上。如果設置關聯掩碼的值為255(比特串為11111111)，那麼就像缺省情況那樣所有的CPU都會被用到。然而一旦關聯掩碼被設置，這8個CPU將會被綁定到8個調度器上。
3.7 觀察調度器內幕 SQL Server 2005有數個動態管理對象可以提供關於調度器、工作和任務的信息。這些對象主要是為微軟客戶支持服務而准備的。不過我們也可以使用它們來獲得更多超值的SQL Server跟蹤信息。需要注意的是所有這些對象都需要SQL Server 2005具有稱為“觀察服務器狀態”的權限。缺省情況下，只有管理員才具有該權限，但該權限也可以被賦予他人。下面列出幾個主要的相關動態管理對象：
sys.dm_os_schedulers 這個視圖為SQL Server中的每個調度器返回一行。每個調度器都與SQL Server中的單個的CPU相對應。我們可以使用這個視圖來監視一個調度器的狀態，從而識別失控的任務。
sys.dm_os_workers 該視圖為系統中的每個工作程返回一行。
sys.dm_os_tasks 該視圖為SQL Server實例上每一個活動的任務返回一行。
sys.dm_os_waiting_tasks 這個視圖返回正在等待資源的任務隊列的信息。
4. 內存管理內存管理是一個很大的話題，本文將主要討論兩部分內容：第一部分將提供關於SQL Server如何使用內存資源的足夠信息，利用這些信息我們可以判斷某個系統上的SQL Server的內存管理是否良好；第二部分將描述用戶內存管理的各個方面，這可以幫助我們了解在何時進行何種控制。缺省情況下，SQL Server 2005幾乎是完全動態地管理它的內存的。在分配內存時，SQL Server必須持續地與操作系統通信，這是SQL Server引擎中SQLOS層如此重要的原因之一。
4.1緩沖池和高速數據緩沖區SQL Server主要的內存組件是緩沖池。所有不被其它內存組件使用的存儲器都保留在緩沖池裡以便用做從磁盤上的數據庫文件讀取數據頁的高速數據緩沖區。緩沖管理器管理磁盤I/O功能，將數據頁和索引頁放在數據高速緩沖區中以便多個用戶可以共享數據。
當其它組件需要內存時，它們能夠從緩沖池中申請一塊緩沖區。一塊緩沖區就是內存中的一個數據頁，其大小與數據頁和索引頁相同。我們可以認為它就是一個可以容納來自數據庫頁面的頁框架。取自緩沖池為其它存儲器組件使用的緩沖塊使用其它種類的高速緩沖區，其中最大的主要用來作為存儲過程和查詢計劃的高速緩沖區，通常稱為“過程高速緩沖區”。
SQL Server 偶爾需要申請大於8KB的連續內存塊 ，緩沖池卻只能提供8KB的內存塊。這時只能從緩沖池外分配內存。因為一般情況下系統會控制盡量少地使用大內存塊，所以直接通過操作系統分配的內存只占SQL Server內存使用的很少一部分。
4.2訪問內存中的數據頁訪問數據高速緩沖區中的頁面必須非常迅速。當擁有數以GB計的數據時，即使是在真實內存中，以掃描整個高速緩沖區來尋找一個數據頁的方法也是非常荒謬而低效的。因此高速緩沖區中的數據都經過哈希處理以支持高速數據訪問。哈希方法是一種統一地利用經過一組哈希漏斗的哈希函數來映射一個鍵值的方法。一個哈希表是內存中的一個結構，它包含有一組指針（作為鏈接列表）指向緩沖區頁面。如果一個哈希頁面無法容納指向緩沖頁面的所有指針，那麼鏈接列表會指向下一個哈希頁面。
4.3管理數據高速緩沖區中的頁面 只有當數據頁和索引頁存在於內存中時我們才能夠讀取它。因此數據高速緩沖區必須有可用緩沖區塊來容納讀入的頁面。保證供即時使用的緩沖區塊供給充足是一種重要的性能優化手段。如果沒有可供即時使用的緩沖區塊，SQL Server將不得不搜索大量的內存頁來尋找一個可以釋放並可作為工作空間使用的緩沖區塊。在SQL Server 2005中有一種機制既負責將改動過的頁面寫入磁盤，又負責將很久不被引用的頁面標為自由頁面。SQL Server維護有一個由自由頁面地址組成的鏈接列表，需要一個緩沖區頁的工作線程可以使用該列表所指向的第一個頁面。
4.4檢查點檢查點過程也會周期性地掃描高速緩存並且將特定數據庫中的髒數據頁寫入磁盤。檢查點過程和惰性寫入器（或者說是工作線程的頁面管理）的不同在於檢查點過程從不會把緩存塊加入自由列表。檢查點過程的目的只是為了保證在某個特定時間之前寫入的頁面被寫入磁盤，從而使內存中的髒數據頁的數量保持在最小，這可以保證SQL Server在發生故障之後恢復一個數據庫所需要的時間保持為最小。在某些情況下，如果大多數的髒數據頁都被工作過程或兩個檢查點之間的惰性寫入器寫入磁盤，那麼檢查點會發現可寫入磁盤的髒數據頁非常之少。
當一個檢查點發生時，SQL Server會將該檢查點的記錄寫入事務日志，事務日志中含有所有活動事務的記錄。這使得恢復過程能夠建立一個包含所有可能是髒數據頁的頁面列表。檢查點能夠按照規律間隔自動地發生，也可以人為地請求其發生。
檢查點在如下幾種情況下會被觸發：
n 數據庫所有者明確地發出檢查點指令在數據庫中執行檢查點操作。
n 日志快要被充滿時（已達到其容量的70%）並且數據庫是在SIMPLE恢復模式。
n 估計出的恢復時間非常之長。當預測的恢復時間比配置選項中的恢復間隔還要長時，一個檢查點就會被觸發。
n SQL Server收到正常的沒有附加NOWAIT選項的關閉請求之後，將會有一個檢查點操作在SQL Server實例的每一個數據庫上執行。
檢查點過程會遍歷整個緩存池，以非線性的順序掃描數據頁，並且當它發現一個髒數據頁時，它會查看是否有成片髒的而且物理上連續的頁面以便整塊寫入磁盤。但是這意味著（舉例來說）：當發現緩存塊14是髒頁時，它也許會將緩存塊14、200、260和1000寫入磁盤。（即使那些頁面在緩沖池中相距，它們仍可能會有連續的物理位置。在這個例子中，這些緩沖池中並不連續的頁面能夠作為單個操作寫入磁盤，這種操作我們稱之為聚集寫入。）該檢查點過程會繼續掃描緩存池直到到達頁面1000。在某些情況下，一個已經寫入的頁面可能會再度變髒，並且需要第二次寫入磁盤。>當談到SQL Server內存時，實際上並不僅僅是在討論緩存池。SQL Server內存實際上是由三部分組織起來的，緩存池通常是最大和使用最為頻繁的。因為緩存池是作為一組8-KB的緩存塊使用的，所以大於8KB的大內存快需求是被單獨管理的。名為sys.dm_os_memory_clerks的動態管理視圖有一個稱為multi_pages_kb的列來顯示一個內存組件使用了多少緩存池之外的空間：
SELECT type, sum(multi_pages_kb)
FROM sys.dm_os_memory_clerks
WHERE multi_pages_kb != 0
GROUP BY type
如果SQL Server實例被配置為使用地址窗口化擴展（AWE）內存，該部分內存可以認為是第三種內存區域。AWE是一種允許32位應用程序訪問32位地址限制之外物理內存的應用程序接口。因為只有數據高速緩存頁面才能夠使用AWE內存，所以雖然AWE內存是作為緩沖池的一部分來分派的，但是必須對其進行單獨跟蹤。
4.6調節緩存池大小當SQL Server啟動時，它會計算SQL Server進程的虛擬地址空間（VAS）的大小。每個運行在Windows上的進程都有自己的VAS。所有可供進程使用的虛擬地址的集合構成了VAS的大小。VAS的大小取決於體系結構和操作系統。VAS只是所有可能地址的集合；它可以比計算機上的物理內存大上很多。
一個32位的計算機只能夠直接尋址4GB內存，並且缺省情況下Windows自身會將2GB的地址空間留作己用，這樣一來只剩下僅僅2GB作為所有應用程序（例如SQL Server）的最大虛擬地址空間。我們可以通過啟用操作系統的Boot.ini文件中/3GB選項來允許應用程序擁有一個高達3GB的虛擬地址空間。如果系統有多於3GB的RAM內存，使32位計算機能夠使用這些內存的唯一方法就是啟用AWE選項。
4.6.1觀察內存內幕SQL Server 2005包含了一些提供有關內存和各種高速緩存信息的動態管理對象。比如包含調度器有關信息的動態管理對象，這些對象主要是為客戶支持服務工程師查看SQL Server當前正在做什麼而准備的，其實我們自己也可以利用這些對象做這些事情。 要查詢這些對象，需要具備觀察服務器狀態（VIEw Server State）權限。
sys.dm_os_memory_clerks為SQL Server實例上的每個內存書記返回一行。
sys.dm_os_memory_cache_counters 為用戶存儲倉庫和高速緩沖倉庫類型的每個高速緩沖返回一份關於其健康情況的快照。
sys.dm_os_memory_cache_hash_tables 為SQL Server實例中的每個活動的高速緩存返回一行。
sys.dm_os_memory_cache_clock_hands通過cache_address列可與其它高速緩沖動態管理視圖進行連接操作。
觀察內存使用的另一種工具是命令DBCC MEMORYSTATUS<
/span>，該命令在SQL Server 2005中得到了極大的增強。
4.6.2 預讀
SQL Server支持一種稱為預讀的機制，我們可以憑此預期對數據和索引頁面的需求，並且可以在頁面被實際需要前將它們讀入緩沖池。這種性能優化可以使我們能夠有效地處理大數據量的數據。預讀完全是系統內部管理的，不需要對其進行任何的配置和調整。
5．結束語
在本文中，我們概括了SQL Server引擎的體系結構，包括組成引擎的關鍵模塊和功能區域。同時還考察了SQL Serve與操作系統的交互。為了節約篇幅，許多地方都作了大量簡化，不過本文提供的信息應該能夠幫助讀者理解SQL Server各主要組件的角色和職責，以及這些組件之間的相互關系。有興趣的讀者可參考《Microsoft SQL Server 2005技術內幕：存儲引擎》(2007年10月，電子工業出版社)。該書對SQL Server的工作原理和內部實現進行了深入研究。
