SQL Server 體繫結構的工作原理

　摘要：本文深入探討了 SQL Server 體繫結構的工作原理。其中介紹了資料庫引擎的增強功能及其提示，並提供了相關資訊的連結。深入瞭解 SQL Server 的引擎有助於資料庫管理員（資料庫系統工程師）在設計、構建或改進資料庫系統時充分利用 SQL Server 的優勢。雖然本文主要面向資料庫專業人士，但也可用於教學或營銷目的。 

　　一. 簡介

　　本文描述 Microsoft? SQL Server? 2000 中新增的儲存引擎功能，並提供相關的提示，同時探討儲存引擎的工作原理。初步掌握儲存引擎的工作原理可使您最大限度地發揮 SQL Server 的效能。

　　當今，人們的注意力集中在應用程式的高可擴充性方面。資料庫的設計和實施周期不斷縮短，而且由於開發需求的不斷變更以及產品使用的增長，又使得資料庫在不斷地演變發展。為滿足可擴充性、可用性和便於使用等方面的要求，需要有一種具有應變能力和靈活性的資料存放區引擎。

　　SQL Server 2000 的不同版本可支援不同規模的系統，其範圍從用於 Pocket PC 的小型移動系統到運行在群集 Windows? 2000 Datacenter Server 上容量達數 TB 的高可用性交易處理或決策支援系統。所有這些系統都滿足使命關鍵的業務系統所要求的靈活性、安全性和可靠性要求。

　　由於儲存引擎操作的智能化和自動化，因而可以在各種用途和規模的項目中部署 SQL Server 2000 應用程式。高度完善的體繫結構改善了效能、可用性和延展性。

　　可用性

　　由於在與物理檔案進行互動時採用了新的演算法，可靠性和並發能力得到了增強。這些演算法減輕了日常維護工作，使您不必再運行資料庫主控台命令 (DBCC)。然而，DBCC 仍舊可以使用，並且新增的 DBCC CHECK 命令的運行不會干擾聯機處理工作。

　　可擴充性

　　儲存子系統（由物理資料庫檔案及其在磁碟上的布局組成）既支援小型資料庫，也支援超大型資料庫。SQL Server 當前可支援最高達 64 GB 實體記憶體 (RAM) 和 32 顆處理器。

　　便於使用

　　增強管理功能可協助資料庫管理員 (DBA) 實現伺服器的自動管理和集中管理。這也使得對遠程伺服器和應用程式的維護變得容易，DBA 無需訪問每個網站。由複雜演算法管理的伺服器配置可動態對伺服器使用方式情節的變化作出反應，從而使 DBA 可以將精力集中在資料庫管理和最佳化等任務上。

　　二. 儲存引擎的增強功能

　　SQL Server 2000 的關聯式資料庫伺服器包括兩個主要部分：關聯式引擎和儲存引擎。兩個引擎獨立工作，它們通過本機資料訪問組件（如 OLE DB）進行互動。關聯式引擎提供訪問儲存引擎的介面，而儲存引擎由與基本資料庫儲存群組件和功能進行互動的服務構成。

　　儲存引擎的主要任務包括： 
　　提供改善管理儲存群組件易用性的功能 
　　管理資料緩衝和對物理檔案的所有 I/O 操作 
　　控制並發、管理事務、鎖定和日誌記錄 
　　管理用於儲存資料的檔案和物理頁 
　　恢複系統故障 

　　SQL Server 2000 中的儲存引擎提供概念簡單而實際操作比較靈活的新增功能，同時減少了詳細規劃容量和最佳化效能的工作。SQL Server 2000 可以對其環境作出反應，並準確而快速地適應資料庫使用上的變化。這種技術上的突破已將資料庫管理的重點轉移到作為服務的資料簡化上。SQL Server 2000 DBA 可以將注意力集中到設計一個可對資料流和資料使用作出響應的系統上，而不再需要將時間浪費在最佳化個別參數上。 

2003-6-7 19:21:00    
 查看評語???     

 2003-6-7 19:23:01    　　SQL Server 2000 中的變化建立在體繫結構的增強上。這種增強是在 SQL Server 7.0 中引入的，其目的是為後來的改進和創新提供基礎。儲存引擎小組的主要目的是減少花在定期最佳化伺服器上的時間和精力。由於絕大多數的調優參數設定是基於資料庫使用的，所以引擎使用自適應演算法動態調整這些設定，使其適合資料庫環境。調優參數現在可以按這種方式自動調整，而在早期版本中，它們需要不斷調整和測試。您仍可以手動調整調優功能，但 SQL Server 2000 可以完成更多的工作。只有很少的 SQL Server 客戶才需要對調優參數進行調整；這種調整工作需要進行仔細的測試，並且需要經驗豐富的資料庫管理員進行監督。

　　下表總結了 SQL Server 2000 儲存引擎的主要增強功能。本文的後面將對這些內容進行詳細闡述。

功能 描述及益處 
應用程式鎖定管理器 如果需要控制對應用程式定義的資源（如表單）的並發訪問，新增的預存程序允許您使用 SQL Server 的應用程式鎖定管理器鎖定這些資源。 
資料庫主控台命令 (DBCC) DBCC CHECK 命令可以在聯機處理過程中運行，且不會中斷更新。新增的功能允許校正物理頁的一致性，以檢測硬體引起的錯誤。在 SQL Server 2000 企業版中，DBCC 可以在多個處理器上以並行方式運行。 
資料庫選項 所有的資料庫選項都可使用 ALTER DATABASE 進行修改。此功能簡化了管理工作。 
差異備份 在 SQL Server 2000 中，由於改進後的功能可以在更廣的層次上追蹤資料庫的更改，差異備份的速度更快。 
動態調優 通過使用動態自適應演算法，伺服器可以自動調整以前是靜態不變的配置設定。管理控制仍可用於管理系統範圍的資源，但以後您不必使用它們。手動設定參數可以在它們的約束邊界內動態調整。 
行內文本 在包含較小且使用頻繁的文本列的表中，較小的文本值可以與標準資料行儲存在同一頁中，而不必儲存在文本值頁中。如果表中包含這種被頻繁訪問的文本資料，此功能可減少大量磁碟 I/O 操作。 
並行建立索引 在企業版中，索引建立過程自動使用為平行處理配置的所有處理器，減少了建立索引所需的時間；例如，在一台八處理器的伺服器中，時間縮短到原來的六分之一。索引建立過程還可利用記憶體和 tempdb 中的可用資源。 
預讀索引 讀取索引的功能得到增強，提高了掃描索引的效能。 
重組索引 對 DBCC SHOWCONTIG 進行的改進提供了有關索引片段的詳細資料。新增的 DBCC 命令 INDEXDEFRAG 可聯機重組索引頁，且不會中斷資料庫服務，也不會導致資料庫一致性或故障恢複方面的問題。 
降序排列索引中的鍵列 索引中的各個鍵列可單獨指定為升序或降序。 
KILL 命令 此命令現在報告完成的進度。如果此命令正在等待另一個進程（例如復原），則可以查看命令執行的進度。改進後的命令可以用於停止 Microsoft 分散式交易協調器 (MS DTC) 事務，而這些事務並不與特定會話相關聯。 
對高記憶體量的支援 Windows 2000 中的技術改進了使用大量記憶體的企業版系統的效能。通過使用 Windows 2000 的 AWE 擴充，SQL Server 2000 可至多支援 64 GB 實體記憶體 (RAM)。 
鎖定 改進後的鎖定管理器可探測到其它資源（如線程和記憶體）的死結情況。並發能力的改善同時也降低了死結的發生，從而進一步加強了 SQL Server 2000 的可擴充性。 
邏輯日誌標記 Transact-SQL 命令可在日誌中建立書籤，使資料庫可以恢複到書籤所示的時點。此功能還可同步恢複用於同一應用程式的多個資料庫。 
聯機索引重組 對 DBCC SHOWCONTIG 進行的改進提供了有關索引片段的詳細資料。新增的 DBCC 命令 INDEXDEFRAG 可聯機重組索引頁，且不會中斷資料庫服務，也不會導致資料庫一致性或故障恢複方面的問題。 
最佳化的預讀 I/O 操作 對於掃描所涉及的每個檔案，SQL Server 2000 都會同時發出多個連續的、預讀讀取操作。為提高效能，查詢最佳化工具在掃描表和索引時使用連續的預讀 I/O 操作。 
密碼保護備份 可使用密碼保護備份媒體和單獨的備份。這樣可以防止未授權的使用者恢複備份並訪問資料庫。 
故障復原模式 通過使用故障復原模式，可以選擇資料庫的日誌記錄層級。這樣交易記錄管理更加靈活。故障復原模式可聯機更改，以適應一天當中不斷變化的資料庫使用。 
共用表掃描 在企業版中，對某個表的多次掃描可以利用其他進行中的對該表的掃描，減少了對磁碟的實際 I/O 操作。 
收縮日誌 收縮日誌命令可在更多的情況下立即運行。即使不能立即收縮日誌，SQL Server 也會提供建議性的反饋，說明在繼續或完成收縮操作之前必需完成的操作。 
快照備份 對第三方供應商提供的快照備份的支援進一步得到加強。快照備份採用儲存技術，可以在幾秒內備份或恢複整個資料庫。如今，可以將這些備份與常規交易記錄及差異備份相結合，為 OLTP 資料庫提供完整的保護。此功能對於中型或大型資料庫是非常有益的，因為在這種環境中可用性是非常重要的。 
節省空間的空表和索引 SQL Server 2000 不為空白表和索引分配磁碟頁。SQL Server 7.0 會給空表和索引分配多達三個磁碟頁。 
前 n項排序 此新功能可最佳化前 n 項值的檢索（例如，SELECT TOP 5 * FROM tablename）。 
Xlock SQL Server 2000 提供這種新的 Transact-SQL 鎖定提示。它可用於明確調用互斥的、事務層級的頁或表鎖。 

　　SQL Server 2000 中增加了許多功能，這些功能使資料互動更為有效，使管理更加靈活。以下部分將詳細介紹這些增強功能，並提供相關的提示。
三. 與資料進行互動

　　在 SQL Server 2000 中，儲存引擎的功能得到增強，在與資料進行互動時可提供更好的可擴充性及效能。瞭解這些增強功能有助於更有效地使用 SQL Server。

　　無論是通過使用者介面還是自動執行的任務，資料交換都從查詢開始。資料請求先被傳遞到關聯式引擎，然後關聯式引擎與儲存引擎進行互動以擷取資料，並將其傳遞給使用者。無論是從使用者還是 DBA 的角度來看，儲存和關聯式引擎的功能是無法區分的。

　　更有效地讀取資料

　　資料通過一系列事務在伺服器和使用者之間傳遞。應用程式或使用者啟動任務後，資料庫將其傳遞給查詢處理器進行處理，然後返回最終結果。查詢處理器通過接收、解釋和執行 SQL 語句來完成任務。

　　例如，當使用者會話發出 SELECT 語句時，將會執行以下步驟： 

　　關聯式引擎將語句進行編譯和最佳化後，將其納入執行計畫（擷取資料所需的一系列步驟）。然後，關聯式引擎運行執行計畫。執行步驟包括通過儲存引擎訪問表和索引。 

　　關聯式引擎解釋執行計畫，調用儲存引擎以收集所需的資訊。 

　　關聯式引擎將儲存引擎返回的所有資料群組合到最終的結果集中，然後將結果集返回給使用者。 

　　為提高此過程的效能，進行了兩項改進。在 SQL Server 2000 中，關聯式引擎將核准查詢謂詞的工作交由儲存引擎完成，這樣在該過程中這些謂詞能儘早得到處理，因而提高了儲存和關聯式引擎之間資料交換的效率。此項改進使核准查詢的效率顯著提高。

　　增強 Top n 功能

　　另一項改進是儲存引擎處理從結果集中選擇前 n 個記錄的方式。在 SQL Server 2000 中，新的 Top n 引擎將分析類似以下語句的最佳操作路徑：
SELECT top 5 * from orders order by date_ordered desc
在本例中，如果必須搜尋整個表，則引擎會分析資料並只跟蹤快取中的前 n 項數值。這種方式將大幅提高上述 SELECT 語句的效能，因為只有前 n 項值需要排序，而非整個表。

　　共用掃描

　　在 SQL Server 2000 企業版中，兩個或多個查詢可共用進行中的表掃描，此項功能可改善大型 SQL Server 2000 資料庫的效能。例如，當查詢使用無序掃描查詢一個很大的表時，快取中的頁面將被清空，以便為流入資料騰出空間。如果另一個查詢已經開始，對同一表的第二次掃描就會使磁碟 I/O 再次檢索這些頁面。在頻繁進行表掃描的環境中，當兩個查詢搜尋相同的資料頁時，這將導致磁碟顛簸。 

圖 1：共用掃描效果

　　最佳化的進程可減少由此類資料訪問模式造成的磁碟 I/O 操作。對錶的第一個無序掃描將從磁碟中讀取資料；後續的對同一表的無序掃描不必再讀取硬碟，而只需使用已在記憶體中的資訊。參見圖 1。在對同一個表同時進行多個掃描操作時，此同步過程可將效能提高至多八倍。此項改進的效果在大型決策支援查詢中更加明顯，因為整個表的大小遠遠大於快取的大小）。 

　　當查詢沒有更有效執行計畫時，儲存引擎將使用共用掃描功能協助查詢。此功能的目的是提高頻繁讀取大型表的效能。當查詢處理器確定最佳執行計畫中包含表掃描時，將調用此功能。然而，儘管可以使用查詢或索引最佳化強制進行共用掃描時，但強制進行表掃描並不會提高效能。此時使用狀態良好的索引完成同樣的工作效果不會差，而且可能會更好。

　　並發

　　為了在多個使用者進行資料互動的同時維護事務的一致性，儲存引擎會鎖定資源以管理行、頁、鍵、鍵範圍、索引、表和資料庫的依存性。通過在更改資源時將其鎖定，引擎可防止多個使用者同時更改同一資料。SQL Server 中的鎖可在不同粒度層級上Live App，以選擇事務所需的限制最小的鎖。

　　在 SQL Server 2000 中，並發方面的改進進一步減少了死結，避免了對資源不必要的鎖定。例如，增強鎖定管理器可瞭解被競用的其它資源（如線程和記憶體）。這種新的功能可協助資料庫管理員確定更廣範圍內的設計或硬體限制。 

 
 2003-6-7 19:30:13    鎖定管理器中新增的 Transact-SQL 介面支援在編程代碼中使用自訂的鎖定邏輯。商務邏輯所需的鎖可通過在 Transact-SQL 批處理中調用 sp_getapplock 命令來建立，這將允許您指定要鎖定的應用程式定義的資源（例如鎖定表單，而非資料行）、要使用的鎖定模式、逾時值以及鎖的範圍是事務還是會話。當使用新的應用程式鎖管理器建立鎖後，它們接受 SQL Server 的常規鎖管理，如同它們是由儲存引擎建立的一樣，因此，不必擔心當調用事務終止時，應用程式建立的鎖仍處於開啟狀態。

　　在 SQL Server 2000 中，用於擷取鎖的進程將考慮頁中的資料是否都已提交。例如，若要對某個表運行 SELECT 語句，而該表中的資料在最近未發生變化（如 pubs 資料庫中的表），則該進程不會產生鎖，因為最近沒有活動事務對錶進行過更新。儲存引擎是通過將資料頁上的記錄序號與當前活動事務相比較來實現上述功能的。如果資料庫中的絕大多數資料都早於最早的活動事務，則對於這樣的資料庫，這一功能將顯著減少鎖定操作，從而使效能大幅提高。 

　　在使用鎖保護事務中資料的同時，另一個進程 latching 控制對物理頁的訪問。閂鎖是一種非常輕型的、短期同步對象，它保護事務生存期內不需要鎖定的操作。當儲存引擎掃描某頁時，它先鎖住該頁，讀取行，將行返回給關聯式引擎，然後再解除對頁面的鎖定，以使其它進程可以訪問同一資料。儲存引擎使用稱為 lazy latching 的進程最佳化對資料頁的訪問，即只在另一個活動進程請求某頁時，才釋放對該頁的鎖存。如果沒有活動進程請求同一資料頁，則在對該頁的整個操作過程中，單個閂鎖將始終有效。

　　為改進系統的並發效能，應將精力集中在資料庫系統的設計以及與其相關的代碼對象上。SQL Server 2000 支援 TB 級的資料存放區，其擴充能力可線性增長，且不受限制。資料庫管理員的任務是管理資料庫生命週期，即所有資料庫組件（從代碼到磁碟上的資料存放區）的設計和最佳化周期，以確保設計始終滿足服務級協議的要求。

　　四. 表和索引

　　在物理資料結構方面也進行了改進，提高了設計和維護的靈活性。

　　隨著表或索引的增長，SQL Server 以八個為一組分配新的資料頁；這些資料頁稱為擴充。雖然 text、ntext 或 image 類型的列可儲存在不同的頁中，但一行資料不能超出一頁，所以它只能擁有 8 KB 資料。擁有叢集索引的表按鍵的順序儲存在磁碟上。堆是不帶叢集索引的表，它們是無序的。記錄按插入的順序儲存。

　　SQL Server 2000 支援索引檢視表，在其它資料庫產品中常常稱為實體視圖。在某個視圖上建立叢集索引時，該視圖將從派生對象轉為儲存在資料庫中的基本對象，並且其結構與帶有叢集索引的表相同。索引檢視表可用於儲存預先計算的值或複雜聯結的結果，但前提是維護開銷不能超過效能上的收益。在 SQL Server 2000 企業版中，只要索引檢視表可以最佳化查詢計劃，查詢處理器就會自動使用它。對於很少更改但又經常作為複雜聯結或計算查詢組成部分的資料，索引檢視表可改善查詢速度。

　　行內文本

　　行內文本可用於在首頁面中儲存小文本資料。例如，如果某個表中有一文本列，但文本值通常小到可與行中的其餘內容放在同一普通頁中，則可以在文本列中設定閾值。閾值用來確定可儲存在首頁面而非單獨的文本頁上的最大文本長度。如果大多數資料可放在首頁面上，而只有小部分資料比較大，需要建立文本頁，採取這種做法就可使效能獲得提高。

　　若要確定在何種情況下使用此新功能，則需要權衡儲存密度（或每個資料頁上儲存的行數）以及 I/O 效能的改善。例如，某個表中的文本列用於存放注釋。該列中有 20% 的文本值較長，而其它 80% 的文本值都小於 100 個位元組。對於這種情形，似乎可以採用行內文本解決方案；但是，只有在這樣的列中的資料被頻繁訪問時才應考慮使用行內文本。如果使用者頻繁訪問此表，但只在進行特殊搜尋時才查看此注釋列，則使用行內文本未必是最好的做法。由於每頁儲存的行數少，所以儲存密度會降低；並且由於表包含更多的頁，所以表掃描回應時間也會增加。所以，實現行內文本的最好情況是，存在需要頻繁訪問的文本列，並且該列的許多值都小於 8 K，可以儲存在行中。

　　新增資料類型

　　SQL Server 2000 引入了三種新的資料類型。bigint 是 8 位元組整數類型。sql_variant 可以儲存不同資料類型的資料值。第三種資料類型 table 可用於最佳化效能。Table 變數使 tempdb 的使用效率更高，並且比暫存資料表更加快速。與其它變數一樣，它們的作用範圍是聲明它們的批處理。table 變數的功能類似於暫存資料表，但其效能要高於暫存資料表或遊標，並且可更加有效地利用伺服器資源。通常，在建立與資料庫互動的代碼時，一定要考慮利用伺服器上可用資源的最佳方法。 

　　索引

　　通過使用索引，可以最佳化對資料的訪問。因為是否建立索引取決於使用方式，所以不正確的索引是造成資料庫緩慢最主要的原因。標準的索引維護工作應該包括周期性校正當前索引方案以及通過適當增刪索引使其適應當前的系統使用方式。

　　SQL Server 2000 中的幾個新增功能使索引維護更加有效，索引管理更加容易。這些增強功能減少了磁碟 I/O 操作，從而增加了索引掃描的效能。在範圍掃描可以使用輔助索引時，這一功能尤其有用。 

 
 2003-6-7 19:31:33    建立索引

　　建立索引時，儲存引擎對行進行採樣，並計算使用伺服器資源建立索引的最佳方法。通過使用選項，可以控制建立索引的方式，因而可選擇控制系統資源的分配方式。可以使用這些選項，並結合您在特定資料庫系統方面的知識，平衡對於整體系統的效能是至關重要的進程中的資源，從而使建立索引的操作對交易處理的影響最小。

資源 命令 選項 說明 
記憶體 sp_configure（進階）
index create memory
指定建立索引操作可以使用的記憶體總量。 
TempDB create index
sort_in_tempdb
從 tempdb 中分配在索引建立期間用於排序的磁碟空間。如果 tempdb 在單獨的磁碟上，此命令會產生更高的 I/O 頻寬；並且如果資料庫所在空間不是非常連續，該命令還可以使索引頁的布局在物理上更加連續。 
CPU sp_configure（進階）
最大並行程度
限制在並行操作中（伺服器範圍）可使用的處理器(CPU) 的個數。 

　　大型系統的另一個可擴充性功能是並行索引建立。SQL Server 2000 企業版具有此功能。在發出單個 CREATE INDEX 語句時，此過程將被自動調用。儲存引擎計算資料的要求，然後建立單獨的線程，每個線程建立一段索引。 

圖 2：並行索引最佳化

　　索引建立也可以使用共用表掃描，從而使這一過程進一步最佳化。

　　整理索引片段

　　SQL Server 2000 支援聯機索引重組，相比於以前的版本，這是一個非常大的進步。聯機索引重組對事務的輸送量影響非常小，並且可隨時停止並重新啟動，而不會影響其運行效果。索引重組操作按較小增量進行，並且可完全恢複。

　　隨著在表中插入、刪除和更新資訊，聚集和非叢集索引頁最終將變得零碎，從而降低對資料的範圍查詢的效率。因此，定期整理索引片段是非常有益的。可以使用 DBCC SHOWCONTIG（該命令在 SQL Server 2000 中已有所改進）分析並報告片段。

　　如果確定索引已變為片段，就可以使用 DBCC INDEXDEFRAG 命令對其進行重組。該命令以邏輯鍵的順序記錄頁，同時壓縮可用空間，移動已建立的擴充中的行以滿足填滿因數設定。通過提高頁面中內容的密度以減少資料掃描時讀取的頁數，從而提高讀取效能。如果索引經常得到維護並且其分布不是完全散碎的，那麼運行 DBCC INDEXDEFRAG 對聯機效能的影響要遠遠小於重建索引。

　　DBCC INDEXDEFRAG 是眾多長期啟動並執行管理操作中的一個，它們內部都使用短小的事務。這些短小的事務可最大限度提高伺服器中的並行作業，允許操作停止而不影響工作，並且這些事務被全部記錄以便在發生故障時進行恢複。
五. 日誌記錄和故障恢複 

　　交易記錄是一個記錄流，它記錄了從資料庫建立到當前時點對資料庫所做的更改。每個記錄的操作都建立一個日誌記錄。日誌記錄由事務產生，並在事務提交時寫入磁碟。相反，被事務修改的資料頁不會立即寫入磁碟，而是先保留在 SQL Server 的緩衝區快取中，稍後再寫入磁碟。延遲將資料寫入磁碟可最大限度地提高對資料頁進行多路訪問的效能，並避免中斷掃描。在提交時強制將日誌寫入磁碟是為了確保在伺服器關機時不會丟失已完成的工作。

　　故障恢複可確保在將資料庫變為聯機狀態之前保持其在事務上的一致性。如果資料庫在事務上是一致的，則所有提交的工作都已生效，而任何未提交的工作都變為無效。日誌總是定義資料庫的正確視圖。簡而言之，故障恢複就是將資料與交易記錄在某一給定時點保持一致的過程。 

　　當 SQL Server 啟動時，當資料庫被串連時，或在從備份恢複資料庫的最後一步時，故障恢複將自動執行。在 SQL Server 啟動時執行的故障恢複稱為重新啟動故障恢複或啟動故障恢複。使用備份進行故障恢複通常是由於磁碟發生故障。此類故障恢複稱為媒體故障恢複。

　　重新啟動故障恢複是自動進行的，通常可恢複到最近的時點。在使用備份進行故障恢複時，DBA 可以選擇恢複到較早的時點。這種故障恢複需要滿足一些限制條件。

　　每當啟動一個 SQL Server 執行個體時，啟動故障恢複會自動運行，它將復原上次關閉執行個體時尚未完成的所有事務。在使用備份進行故障恢複時，DBA 可以選擇恢複到較早的時點。這種故障恢複需要滿足一些限制條件。無論何種情況，故障恢複操作都基於此目標時點。 

 
 2003-6-7 19:32:58    故障恢複分為兩個階段： 

　　恢複所有更改，直到達到交易記錄中的目標時點。 

　　撤消由在恢複停止點仍處於活動狀態的事務所執行的所有操作。

　　SQL Server 使用檢查點加速重新啟動故障恢複。檢查點強制將當前緩衝區快取中所有已修改的資料頁儲存到磁碟上。這將為故障恢複的恢複階段建立一起點。由於檢查點的開銷非常大，所以 SQL Server 自動對檢查點進行管理，以保證在盡量縮短重新啟動所花時間的同時儘可能提高效能。

　　在 SQL Server 2000 中，成功完成的寫入必須可持久儲存在磁碟中。如果使用寫緩衝磁碟儲存，請與您的存放裝置供應商聯絡，確認快取是否容錯。容錯能力表示快取可不受電源故障或操作員操作的影響。如果緩衝沒有容錯能力，則應不使用。

　　邏輯日誌標記

　　在 SQL Server 7.0 中，已經可以恢複到任何指定時點。如果出現硬體故障，則恢複過程是相當簡單的。然而，對資料庫的另一種威脅可能是輸入了無效的資料，或者有效資料被使用者操作所破壞。在這種情況下，需要確定問題發生的開始時間。在 SQL Server 7.0 中，解決這種問題的唯一方法是將日誌恢複成資料庫副本，直到問題重現，然後再對產品映像執行恢複操作，直到在所發現的問題出現時刻之前的時點。

　　在 SQL Server 2000 中，可以在日誌中標記事務。之後，如果需要恢複，就可以參考執行時使用的標記，而不必使用規定的時刻。為此，請使用 BEGIN TRANSACTION 的語句和 WITH MARK [說明] 子句。標記儲存在 msdb 中。故障恢複可以包括包含標記的事務，也可以恰恰在包含標記的事務前停止。例如，如果某個進程以批處理方式運行並且更改了許多記錄，那麼可以使用此功能以確保，當進程運行在錯誤環境中時可以將資料復原到執行命令的時點。

　　標記名稱不必唯一。若要指定所需的事務，請指定 datetime 值。該操作的文法為：
RESTORE LOG WITH [ STOPBEFOREMARK|STOPAFTERMARK ] = @TaggedTransaction AFTER @datetime
也可以對分散式交易使用標記（稱為分布式標記），以支援將多個相關資料庫恢複到事務上一致的狀態。相關資料庫可以位於 SQL Server 的同一或不同執行個體上。可以定期對一組資料庫設定分布式標記（例如，每五分鐘一次）。如果其中某個資料庫的交易記錄被損壞，則必須將這組資料庫恢複到更早的時點。分布式標記可提供這一時點。使用分布式標記，就可以在對多個相關資料庫進行備份時不用費心地確定備份的時刻。

　　收縮交易記錄

　　SQL Server 7.0 中不能立即執行日誌收縮操作。該操作被延遲到下一次備份或刪節交易記錄。這種方式使許多 SQL Server 7.0 客戶非常煩惱。SQL Server 2000 可以立即收縮日誌，並且可在記錄備份後指出是否可以進行進一步收縮。這時，可以在記錄備份完成後再次運行收縮命令。

　　日誌大小取決於當前故障復原模式以及應用程式設計。如果發現需要定期收縮日誌，請查明造成問題的原因。應該進一步調查日誌添滿的原因，而不要只是一味地使用收縮命令維護日誌。

　　故障復原模式

　　使用 SQL Server 2000 中增加的故障復原模式可以方便到實施資料保護計劃。這些模式都在效能、日誌空間要求和媒體（磁碟）故障保護之間進行了取捨。共有三種模式，它們是：簡單故障恢複、完全故障恢複和大容量記錄。

　　選擇故障復原模式時，應考慮資料庫的使用方式和可用性要求，同時選擇的模式應有助於確定適當的備份和恢複過程。這些故障復原模式只適用於媒體故障恢複，即使用備份進行故障恢複。重新啟動故障恢複所有提交的工作。

　　故障復原模式間的轉換非常容易。例如，在大型資料庫中，既可使用完全模式，也可以使用大容量記錄模式，或同時使用這兩種模式。可以在白天使用完全模式，而在夜晚或在包含大容量插入以及重建索引的資料裝載過程中使用大容量記錄模式。也可以在運行資料裝載時切換到大容量記錄模式，然後再切換回完全模式，運行交易記錄備份，而且能夠恢複到模式切換時點，而不必運行完全Database Backup。此功能可更有效地進行大容量處理操作；而所要做的只是將以前的交易記錄進行備份。

　　要更改故障復原模式，請使用以下文法：
　　ALTER DATABASE SET RECOVERY RecoveryModel

　　簡單故障復原模式

　　簡單故障復原模式通常需要很少的日誌空間，但如果資料或記錄檔被損壞，則它造成的潛在工作損失是最大的。因為在這種模式下只記錄基本故障恢複所需的事件。使用簡單故障復原模式時，只能進行完全Database Backup和差異Database Backup。在出現故障時，必須重新完成自從上次備份後所有提交的工作。此模式對管理員是最簡單的，但並不適用於關鍵性任務的應用程式，因為這種程式通常不允許丟失已提交的工作。

　　此模式類似於 SQL Server 7.0 及以前版本中的 truncate log on checkpoint 選項。 

 
 2003-6-7 19:34:47    完全故障復原模式

　　在完全故障復原模式中，所有一切都被記錄。完全故障復原模式提供了全面的保護，以防止損壞的資料檔案對工作造成損失。如果交易記錄被損壞，則從最近一次記錄備份後提交的工作都將丟失，並且必須重新手動完成。

　　即使使用完全故障復原模式，也最好使用容錯磁碟儲存交易記錄，以防止資料丟失。完全故障復原模式還允許恢複到指定的時點。

　　大容量記錄故障復原模式

　　大容量記錄故障復原模式為大容量操作提供了最高的效能。而且，這些操作在該模式下佔用的日誌空間要小於在完全故障復原模式下佔用的空間。例如，新頁的分配將被記錄，而插入頁中的資料則不被記錄。在 SQL Server 2000 中，大容量操作由大容量裝載（BCP 和 BULK INSERT，包括當他們在 DTS 包中運行時）、SELECT INTO、CREATE INDEX、WRITETEXT 和 UPDATETEXT 組成。

　　與完全故障復原模式相比，大容量記錄故障復原模式減少了對大容量操作的日誌記錄。請記住，在需要進行故障恢複時，如果日誌被損壞或在最近一次記錄備份後又進行了大容量操作，則在最後一次記錄備份後對資料庫進行的更改將會丟失。

　　此模式不支援恢複到指定的時點，但它允許恢複到包含大容量更改的交易記錄備份的末尾。使用大容量記錄故障復原模式進行的交易記錄備份包含由大容量操作修改的擴充。此功能改善了對記錄傳送的支援，因為不用擔心備份在大容量操作後會變為無效。SQL Server 維護映射以跟蹤修改的資料擴充，這樣做，可最佳化 SQL Server 用於標識更改的進程。

　　改善的備份功能

　　除引入故障復原模式以簡化常規資料保護外，SQL Server 2000 還改善了管理特性：快照技術、差異備份和安全性都已得到加強。 

　　交易記錄備份鏈永遠不會斷開。在 SQL Server 7.0 中，某些操作（如向資料庫中添加檔案）會中斷日誌鏈，並且要求以後進行完全Database Backup。 

　　備份操作不會與應用程式或其他管理操作發生衝突。例如，備份可與大容量操作（如建立索引和批處理裝載）同時進行。 

　　日誌和檔案備份可以同時進行。 

　　無論系統進行中何種活動，SQL Server 2000 都對無人值守備份操作實現良好的支援。

　　SQL Server 支援與獨立硬體和軟體供應商共同完成的快照備份和恢複技術。快照備份使得在進行備份時佔用的系統資源最少，甚至可以不佔用資源。這種技術對於中型或大型資料庫尤其有益，因為在這種環境中可用性是非常重要的。這種技術的主要優勢在於： 

　　可在非常短的時間（通常可以秒計）內建立備份，基本上不會對伺服器造成任何影響。 

　　可以使用磁碟備份非常快地恢複資料庫。 

　　另一台主機可建立備份，且不會對生產系統造成影響。 

　　可以立即建立生產資料庫的副本，以用於報告或測試目的。 

　　快照備份和恢複技術是與第三方硬體和/或軟體供應商協作共同完成的，這些供應商使用了 SQL Server 2000 為實現該技術而提供的特定功能。備份技術通常使用拆分磁碟鏡像集的方法，建立要備份的資料的即時副本。在恢複時，原有資料就可立即投入使用。基本磁碟的同步是在後台進行的，因此幾乎可以實現即時恢複。

　　差異Database Backup的已耗用時間與上次完全備份後資料更改的總量成正比。資料更改越少，備份越快。SQL Server 2000 使用映射跟蹤自最近一次資料庫或檔案備份後發生更改的資料擴充，以確保可更有效地定位這些擴充。此外，SQL Server 2000 支援檔案差異備份。

　　備份仍會收集自最近一次完全備份後對資料庫進行的更改，運作方式與故障恢複相同。然而，這種備份是非常快的，因為它們只記錄少部分更改過的資訊，尤其是當資料庫非常大而更改的資料又非常少時。

　　為確保安全，可以使用密碼保護備份媒體和備份組。這樣就可防止未授權的使用者在備份中添加資料或恢複資料庫。

　　六. 增強管理功能

　　在 SQL Server 2000 中，儲存引擎的若干管理功能得到了加強。

　　資料庫驗證

　　DBCC 提供了各種管理能力，包括驗證資料庫一致性的 CHECK 命令。

　　使用 SQL Server 7.0 和 SQL Server 2000 的經驗表明，資料庫的不一致性是由硬體問題引起的，但是資料庫引擎或應用程式在正常操作中不一定能檢測到這種問題。這種情況更可能出現在不經常訪問的資料上。為解決這種問題，SQL Server 2000 引入一種檢查模式 Physical_Only，可以探測到絕大部分由硬體引發的問題。探測過程非常快，速度與磁碟掃描速度相當，並且其對資源的消耗也很小。

　　由於 SQL Server 儲存引擎在基礎結構架構上的改進（從 SQL Server 7.0 開始），已不必在常規維護時進行資料庫驗證。然而，Microsoft 仍然將資料庫驗證工具作為管理工作關鍵資料的重要組成部分。Microsoft 建議： 

　　根據對基本硬體（特別是磁碟子系統）的信心，不定期運行 Physical_Only 檢查。 

 
 2003-6-7 19:36:16    在關鍵時刻，如在硬體或軟體升級時，或懷疑出現任何問題時，進行完整資料庫檢查。 

　　Microsoft 不推薦在進行常規維護時執行完整資料庫檢查。

　　SQL Server 2000 還在資料庫驗證方面作出了如下重大改進： 

　　預設情況下，檢查可以在聯機狀態下完成。聯機檢查對事務工作負載的影響很小。這種影響的大小取決於系統負載、硬體設定和 tempdb 的速度。Microsoft 的實驗結果表明，對於中等 OLTP 工作負載（50% 的 CPU 使用率），這種影響為 15% 到 20%。提供的 TABLOCK 選項會強制檢查索取共用表鎖，這可以使檢查的運行速度更快，但會妨礙更新。 

　　檢查操作在對稱的多處理器 (SMP) 電腦中是以並行方式完成的，它受限於在該 SQL Server 執行個體中設定的最大並行程度。 

　　SQL Server 2000 檢查命令繼續支援 SQL Server 7.0 中引入的修複功能。在某些情形，離線修複可以替代備份恢複。

　　資料庫狀態控制

　　SQL Server 2000 對 ALTER DATABASE 語句進行了改進，改進後的語句允許通過 Transact-SQL 對資料庫狀態實現更多的控制。現在，所有資料庫選項都可通過 ALTER DATABASE 命令進行靈活修改；在以後的版本中，將不再更新 sp_dboption 和 databaseproperty()。Transact-SQL 命令 sp_helpdb 和 DatabasePropertyEx() 提供有關資料庫狀態的更多資訊。

　　下表列出了資料庫狀態選項。

選項類型 可用設定 
使用者權限 SINGLE_USERRESTRICTED_USERMULTI_USER 
可用性 ONLINEOFFLINE 
更新能力 READ_ONLYREAD_WRITE 

　　SQL Server 還根據資料庫中的條件設定以下狀態：複原 (restoring)、恢複 (recovering) 和待定 (suspect)。資料庫選項可通過以下方式進行設定：ALTER DATABASE 語句的 SET 子句、sp_dboption 系統預存程序或 SQL Server Enterprise Manager（在某些情況下）。

　　在資料庫狀態發生變化後，更改資料庫狀態的會話仍然保持串連，而與新狀態不一致的會話可被終止，並且其事務將被復原。會話終止選項如下： 

　　立即終止 

　　在指定時間後終止 

　　允許活動進程正常完成 

　　檢查活動，如果發現活動使用者會話，則忽略狀態更改 

　　如下為文法的兩個樣本：

　　alter database accting set read_only with rollback immediate
　　alter database accting set single_user with rollback after 60 seconds

　　系統進程 ID 和工作單元

　　管理方面的另一個改進是 KILL 命令，該命令在停止進程時使用。改進後的 KILL 命令具有狀態反饋。所以，如果要瞭解 KILL 命令的狀態，請運行以下命令：

　　KILL SPID WITH STATUSONLY

　　在試圖停止已由其它 KILL 命令停止的系統進程 ID (SPID) 時，系統將返回相同的狀態資訊。

　　在 SQL Server 2000 中，MS DTC 事務可以在沒有相關串連或 SPID 的情況下 存在。因此，在等待事務或工作單元完成之前，串連可由其他進程使用。當 MS DTC 交易管理員發送訊息聲明任務已完成時，您可以提交事務，也可以復原事務。這就叫做一個工作單元 (UOW)，它是 MS DTC 用於事務的事務標識符。UOW 沒有 SPID。 

 
 2003-6-7 19:37:22    動態調優

　　在 SQL Server 2000 中，基於使用的效能最佳化是動態管理的，無需手動調整。靜態參數已被去除，但仍然保留了對某些資源的管理控制（例如，設定 SQL Server 可以使用的最大記憶體數）。相對於根據平均值和估計值進行手工計算的系統，這種方法更加精確，反應更加快捷。這樣，您可以將注意力集中在資料庫管理的設計方面。傳統的資料庫系統需要大量的手工管理和調優工作。例如，為了根據使用方式來最佳化系統，DBA 必須監視系統，不斷記錄大量的統計資料，以便選擇可提供最佳系統效能的靜態設定。然後，DBA 要重新評估系統以確定新設定的效果，接著又從頭開始調優過程。

　　SQL Server 2000 在儲存引擎中引入了動態演算法，它可主動監視伺服器的使用方式，並在內部調整設定。SQL Server 2000 中的動態反饋和分析可將設定保持在絕對最佳化值的 10% 以內（參見圖 3），從而使系統的效能更優，適應性更強。
七. 資料存放區組件

　　SQL Server 2000 協同 Windows 2000 作業系統平衡所有可用 CPU 的工作量。如果正在運行一個特定的 SQL Server 執行個體，並且其他應用程式未佔用相同的資源，請將處理器相關設定保持為預設值，以便使全部的處理器得到充分利用。SQL Server 可利用多個處理器上的平行處理能力執行查詢、索引建立、DBCC 和其他動作。SQL Server 2000 標準版最多可支援四個處理器和 2 GB 實體記憶體 (RAM)。企業版提高到新的水平，支援多達 32 個處理器和 64 GB 實體記憶體 (RAM)。

　　SQL Server 執行個體的主記憶體源稱為它的記憶體池。在 SQL Server 執行個體中幾乎所有使用記憶體的資料結構都是從記憶體池分配的。從記憶體池分配的對象樣本包括緩衝區快取（其中儲存最近讀取的資料）和過程快取（其中儲存最近的執行計畫）。 

　　記憶體池中的分配是高度動態。為最佳化效能，SQL Server 不斷調整分配給不同地區的記憶體池大小。例如，當儲存的執行計畫的數量很少時，會通過將更多可用記憶體分配給資料快取來調整記憶體池，從而最佳化資源的使用。

　　SQL Server 2000 儘可能使用記憶體以減少磁碟 I/O。為此，SQL Server 在實體記憶體 (RAM) 中使用緩衝區快取裝載最近引用的資料，這樣，這些資料可被重複使用。減少磁碟 I/O 和提供資料庫系統速度的潛在方法是增加 SQL Server 可用的實體記憶體 (RAM)。

　　通常，記憶體設定不需要任何調整。然而，在某些情況下可以對它們進行控制。例如，當在同一伺服器上運行 SQL Server 的多個執行個體時，特別是在使用容錯移轉叢集時，需要特別關注記憶體。如果在運行 SQL Server 的伺服器上運行其他應用程式，也需要監視記憶體的使用方式。 

 
 2003-6-7 19:38:17    　　SQL Server 2000 利用 Windows 2000 的新功能，可定址超過 3GB 的實體記憶體 (RAM) 。參見圖 4。SQL Server 2000 企業版可以使用 Windows 2000 Advanced Server 或 Windows 2000 Datacenter Server 所允許的記憶體量。

　　檔案、檔案組和磁碟

　　SQL Server 在磁碟檔案中儲存資料和日誌。在基本安裝中，預設情況下，建立的資料和記錄檔儲存在伺服器配置中指定的預設位置。然而，為了獲得最優的效能和管理能力，可以應用以下幾條基本原則： 
儘可能將資料分布到多個磁碟、通道和控制器中。 

　　通常，磁碟越多（無論其單個容量），訪問磁碟（控制器和通道）的速度以及儲存引擎讀寫資料的速度也就越快。系統使用量越大，資料檔案與記錄檔的分離程度（將它們儲存在不同的物理磁碟機上）也就越重要。此外，由於 tempdb 的使用已發生變化，所以應該將 tempdb 儲存在大磁碟集上；例如，與資料檔案存放在一起或一組磁碟上。 

　　使用檔案組，使企業資料庫更易於管理。 

　　每個資料庫都以一個預設的檔案組開始。由於 SQL Server 2000 可在不附加檔案組的情況下生產力，因此許多系統都無需添加使用者定義的檔案組。然而，隨著系統的增長，使用附加的檔案組可提供更高的管理能力，當然這要求由稱職的 DBA 實施和維護。

　　在 SQL Server 2000 中，如果將資料庫上的特定檔案組設定為唯讀，則該檔案組中的資料不能更改，但仍可以管理諸如許可權等目錄資訊。

　　注意：在 SQL Server 2000 中，資料庫引擎中的非同步 I/O 運算元實現了動態管理，並且不受使用的檔案或檔案組個數的影響，這一點與 SQL Server 7.0 相同。

　　實施或最佳化資料庫設計時，資料庫管理員（資料庫系統工程師）需要考慮資料庫儲存群組件的配置，尤其是物理和邏輯磁碟的布局、資料庫檔案在磁碟中的排列。

　　八. 總結

　　靈活性的增強和效能控制的提高，使資料庫管理員可以在掌握資料庫技術的提示和豐富資料庫的使用經驗時，將精力集中在管理資料庫代碼、設計和儲存群組件等方面，並以此作為資料庫系統管理的最佳途徑。SQL Server 2000 資料庫引擎為各種資料庫實現提供了通用的可擴充性和靈活性。