• 發行項

SQL Server

有效維護資料庫的最佳秘訣

Paul S. Randal

 

綜覽：

  • 管理資料和交易記錄檔
  • 消除索引片段
  • 確保準確、最新的統計資料
  • 偵測損毀的資料庫頁面
  • 建造有效的備份策略

目錄

資料和記錄檔管理
索引片段
統計資料
損毀偵測
備份
總結

每個禮拜有好幾次我都會被要求對要如何有效維護實際執行資料庫提出建議。有時候，提出問題的是正在實作新解決方案，並且想要幫助微調維護作法，

以配合新資料庫特性的資料庫管理員 (DBA)。但更常發問的人其實是那些因故擁有和負責資料庫的非專業 DBA。我在此把這種角色稱為「非自願 DBA」。本文的重點是要為所有的非自願 DBA 提供資料庫維護最佳作法的入門。

就跟 IT 世界裡大多數的工作和程序一樣，有效維護資料庫也沒有所謂一體適用的解決方案，但有一些重點區域始終需多加注意。我的前五大重點區域為 (不分重要性)：

  • 資料和記錄檔管理
  • 索引片段
  • 統計資料
  • 損毀偵測
  • 備份

未加維護 (或維護不良) 的資料庫可能會在上述當中一或多個區域內發生問題，而終究導致應用程式效能不佳，甚或停機和資料損失。

在本文中，我將解釋這些問題的重要性，並示範一些簡單的方法來舒緩問題。我將以 SQL Server® 2005 作為論述的基礎，但是我也會點出 SQL Server 2000 與即將推出的 SQL Server 2008 的主要差異。

資料和記錄檔管理

接掌資料庫時，我向來建議檢查的第一個區域，就是與資料和 (交易) 記錄檔管理相關的設定。更具體的說，您應該確定：

  • 資料和記錄檔除了彼此區隔外，也與其他任何項目隔離
  • 自動成長的設定正確
  • 已設定立即檔案初始化
  • 未啟用自動壓縮，而且壓縮不屬於任何維護計畫的一部分

當資料和記錄檔 (理想的情況下，應該是分別位在不同的磁碟區上) 與其他建立或擴充檔案的應用程式共用磁碟區時，就可能產生檔案分散。在資料檔案中，過度的檔案分散可能是致使執行查詢不佳 (尤其是那些掃描非常大量資料的查詢) 的一小部分導因。而在記錄檔案中，它對效能所造成的衝擊可能大得多，特別是如果自動成長是設定成每次在有需要時每個檔案才增加一點點大小的話。

記錄檔的內部分成幾個稱為虛擬記錄檔 (VLF) 的區段，一個記錄檔內的片段越多 (我在這裡使用單數，因為擁有多個記錄檔並沒有好處 — 每個資料庫應該只有一個記錄檔)，VLF 就越多。一旦記錄檔包含超過 200 個 VLF，就會拖累記錄相關作業的效能，例如記錄讀取 (比方說用於交易式複寫/復原)、記錄檔備份，甚至是 SQL Server 2000 中的觸發程序 (觸發程序的實作在 SQL Server 2005 已變更為資料列版本控制架構，來取代交易記錄檔)。

關於調整資料和記錄檔大小的最佳作法，是以適當的初始大小來建立它們。對於資料檔案，初始大小應該將短期內可能另外加入資料庫中的資料列入考量。譬如，假若資料的初始大小是 50GB，但是您知道在未來六個月內會另外加入 50GB 的資料，那麼一開始將資料檔案建立為 100GB 就很合理，這樣一來，就不用為了達到這樣的大小而一連增加好幾次。

不幸的是，記錄檔就沒那麼簡單了，您還必須考慮像是交易大小 (長期執行的交易要等到完成之後才能從記錄檔清除) 和記錄備份頻率 (因為這是用來移除記錄檔中的非作用部分) 等因素。如需詳細資訊，請參閱由內人 Kimberly Tripp 在 SQLskills.com 上撰寫的熱門部落格文章：＜提高交易記錄輸送量的 8 個步驟＞。

設定好之後，應該在不同的時候監視檔案大小，並且在一天適當的時間內主動手動增加大小。為了以防萬一，應該將自動成長保持開啟狀態，這樣一來，發生異常事件時，檔案還是可以視需要成長。反對讓檔案管理交由自動成長全權處理的原因是，小量的自動成長會導致檔案分散，而且自動成長可能很耗時，會在非預期的時候拖延應用程式工作負載。

自動成長應該設定為特定的值，而不是設成百分比，以限制執行自動成長所需的時間和空間 (如果真的發生的話)。比如，您可能會想要把 100GB 的資料檔案設定為固定 5GB 的自動成長大小，而不是 10%。這表示無論檔案最後變得多大，它始終只會成長 5GB，而不是在每次檔案變大時不斷增加數量 (10GB、11GB、12GB 等)。

當交易記錄增長時 (無論是手動或是透過自動成長而增加)，永遠都是以零初始化。資料檔案在 SQL Server 2000 中也有相同的預設行為，但自 SQL Server 2005 開始，您可以啟用立即檔案初始化，也就是跳過以零初始化檔案，因此實際上是立即進行成長和自動成長。與一般的認知剛好相反，這項功能在所有 SQL Server 版本內都可用。如需詳細資訊，請在 SQL Server 2005 或 SQL Server 2008 的《線上叢書》索引內輸入「立即檔案初始化 (instant file initialization)」。

最後還要特別注意，無論如何都不能啟用壓縮。壓縮可用來減少資料或記錄檔的大小，但是它是個極度干擾又耗用大量資源的程序，它會導致資料檔案中大量的邏輯掃描片段 (細節請見下文)，並且致使效能不佳。我改了 SQL Server 2005《線上叢書》記載的壓縮功能，以警告此副作用。然而，在特殊的情況下手動壓縮個別的資料和記錄檔是可接受的。

自動壓縮是再糟也不過了，因為它每 30 分鐘就會在背景啟動，試圖壓縮自動壓縮資料庫選項設為 true 的資料庫。這個程序有點難以捉摸，因為它只壓縮擁有 25% 以上可用空間的資料庫。自動壓縮會使用大量的資源，並且會導致效能低劣的分散情形，因此無論如何都是不良的計畫。您應該使用下列命令永遠關閉自動壓縮：

ALTER DATABASE MyDatabase SET AUTO_SHRINK OFF;

若定期維護計畫內包含手動資料庫壓縮命令的話，也沒有好到哪裡去。如果您發現資料庫在維護計畫壓縮它之後還是繼續成長，那是因為資料庫需要其中的空間來執行。

最佳的辦法是允許資料庫成長到穩定狀態的大小，然後全然避免執行壓縮。您可以在我舊的 MSDN® 部落格上找到關於使用壓縮的缺點的詳細資訊，還有一些關於 SQL Server 2005 中新演算法的說明，網址是 blogs.msdn.com/sqlserverstorageengine/archive/tags/Shrink/default.aspx。

索引片段

除了檔案系統層級還有記錄檔內部的片段之外，資料檔案裡面存放資料表和索引資料的結構內也可能產生片段。資料檔案可能發生的片段有兩種基本類型：

  • 個別資料和索引頁的片段 (有時候稱為內部片段)
  • 由頁面組成之索引或資料表結構內部的片段 (稱為邏輯掃描片段和範圍掃描片段)

內部片段是頁面中有很多空白空間的地方。如 [圖 1] 所示，資料庫中的每一頁大小是 8KB，而且有 96 個位元組的頁首；因此，一頁大約可以儲存 8096 個位元組的資料表或索引資料 (資料和資料列結構內部特定的資料表和索引，可在我的部落格上的「深入儲存引擎 (Inside The Storage Engine)」類別中找到，網址是 sqlskills.com/blogs/paul)。如果每個資料表或索引記錄的大小超過頁面的一半，就可能發生空白空間，因為在這種情況下，每頁只能存放一筆記錄。要修正這個問題可能相當困難，甚或不太可能，因為這需要變更資料表或索引結構描述才辦得到，譬如將索引鍵變更成像 GUID 一樣不會產生隨機插入點。

fig01.gif

[圖 1] 資料庫頁面結構 (按一下以放大影像)

內部片段比較常起源於資料修改，例如插入、更新和刪除等，這些修改都可能在頁面上留下空白空間。管理不善的填滿因數也可能導致片段；如需詳細資訊，請參閱《線上叢書》。視資料表/索引結構描述和應用程式的特性而定，空白空間一經建立後可能就完全無法重複使用，而且可能導致資料庫內無法使用的空間不斷增加。

比方說，假設有個內含一億個資料列的資料表，且平均的記錄大小是 400 個位元組。經過一段時間後，應用程式的資料修改模式在每一頁留下了平均 2800 個位元組的可用空間。資料表所需的總空間大約是 59GB，計算的方式是每 8KB 的頁面可放 8096-2800 / 400 = 13 筆記錄，然後將一億除以 13，以求得頁數。如果空間沒有浪費掉，那麼每頁應該可容納 20 筆記錄，將所需的總空間減少為 38GB。這可省下不少的空間！

資料/索引頁上面浪費掉的空間，可能為此需要更多頁面來容納相同的資料量。這不僅會佔用更多磁碟空間，也表示查詢需要發出更多的 I/O 來讀取相同的資料量。而且所有這些額外的頁面在資料快取中也會花更多的空間，因而佔用更多的伺服器記憶體。

邏輯掃描片段是由一個叫做頁面分割的作業所引起。當某記錄必須插入特定的索引頁 (根據索引鍵定義)，而頁面上沒有足夠的空間來容納要插入的資料時，便會發生這種現象。頁面於是一分為二，而大約 50% 的記錄會移到新配置的頁面。在實體上這個新頁面通常不與舊頁面相鄰，因此稱為片段。範圍掃描片段在概念上與此類似。資料表/索引結構內的片段會影響 SQL Server 進行有效的掃描，無論是對整個資料表/索引，或受到查詢 WHERE 子句繫結限制 (例如 SELECT * FROM MyTable WHERE Column1 > 100 AND Column1 < 4000) 都一樣。

[圖 2] 顯示含 100% 填滿因數且無片段的新建索引頁 — 這些頁面都已滿，而且頁面的實際順序與邏輯順序相符。[圖 3] 顯示在隨機插入/更新/刪除作業後可能產生的片段。

fig02.gif

[圖 2] 不含片段的新建索引頁；頁面 100% 填滿 (按一下以放大影像)

fig03.gif

[圖 3] 在隨機插入、更新和刪除作業之後顯示內部和邏輯掃描片段的索引頁 (按一下以放大影像)

分散的情形有時候可以透過變更資料表/索引結構描述加以避免，但是我在前文有提到，這可能非常困難，甚或是不可能的。如果預防措施不可行，還是有辦法在發生片段後加以移除 — 特別是透過重建或重新組織索引。

重建索引牽涉到建立一份新的索引複本 — 經過適當壓縮，而且盡可能相鄰 — 然後丟棄分段的舊索引。當 SQL Server 在移除舊索引之前建立新索引複本之時，它在資料檔案內需要有大約與索引大小相當的可用空間。在 SQL Server 2000 中，重建索引向來是離線作業。而在 SQL Server 2005 Enterprise Edition 中，索引重建可在線上進行，不過有幾項限制。另一方面說來，重新組織則是使用就地演算法來壓縮和重組索引，它只需要 8KB 的額外空間就可執行 — 而且永遠是在線上執行。事實上，在 SQL Server 2000 中，我特別將索引重新組織程式碼寫成是替代重建索引且不佔空間的線上方案。

在 SQL Server 2005 中，要調查的命令為 ALTER INDEX … REBUILD 以重建索引，還有 ALTER INDEX … REORGANIZE 以重新組織索引。此語法分別取代了 SQL Server 2000 命令 DBCC DBREINDEX 和 DBCC INDEXDEFRAG。

這些方法之間有許多需要取捨，例如產生的交易記錄量，資料庫當中所需的可用空間量，以及處理序是否能在不損失工作的情況下中斷。您可以在 microsoft.com/technet/prodtechnol/sql/2000/maintain/ss2kidbp.mspx 找到討論這些取捨，以及其他內容的白皮書。此白皮書是以 SQL Server 2000 為基礎，但其中的概念也適用於之後的版本。

與其抓破頭想搞清楚哪些索引產生片段，還有移除片段是否有任何好處，有些人乾脆選擇每晚或每週重建或重新組織所有索引 (比如，使用維護計畫選項)。雖然這對於只想要盡可能不多花力氣安置對策的非自願 DBA 來說可能是不錯的解決方案，但要注意的是，對於大型資料庫或資源非常昂貴的系統來說，可能是下下策。

比較聰明的方法是使用 DMV sys.dm_db_index_physical_stats (或是 SQL Server 2000 中的 DBCC SHOWCONTIG) 定期判斷有哪些索引產生片段，然後決定是否以及如何在這些索引上操作。白皮書也討論到使用這些目標更明確的抉擇。除此之外，您可以參考一些進行此篩選動作的範例程式碼，如果是 SQL Server 2005 中的 DMV sys.dm_db_index_physical_stats，請參閱《線上叢書》的範例 D (msdn.microsoft.com/library/ms188917)，如果是 SQL Server 2000 及之後版本，請參閱《線上叢書》的範例 E (msdn.microsoft.com/library/aa258803)。

無論您採用哪種方法，都強烈建議您定期調查和修正分散情形。

查詢處理器是 SQL Server 中描述查詢應該如何執行的部分 — 特別是要使用哪些資料表和索引，以及在上面要執行哪些作業以取得結果，這就稱為查詢計畫。影響此決策程序最重要的一些資訊，是描述資料值在資料表或索引內的各資料行的散佈情況的統計資料。很顯然地，統計資料必須要準確且是最新的，對查詢處理器才有用，否則可能會選擇成效不彰的查詢計畫。

統計資料是藉由讀取資料表/索引資料，然後判斷相關資料行的資料散佈情形而產生的。統計資料除了可以透過掃描特定資料行的所有資料值 (完整掃描) 來建置之外，也可以根據使用者指定的資料百分比 (取樣掃描) 來建置。若資料行內的值散佈的非常平均的話，那麼取樣掃描就綽綽有餘了，而且這也會使建立和更新統計資料的速度比完整掃描快。

請注意，您可以透過開啟 AUTO_CREATE_STATISTICS 和 AUTO_UPDATE_STATISTICS 資料庫選項來自動建立及維護統計資料，如 [圖 4] 所示。這些選項預設會開啟，但要是您才剛剛繼承資料庫，應該再確認一下。統計資料有時候可能會過期，在這種情況下，可在特定統計資料集上使用 UPDATE STATISTICS 作業來手動更新它們。或者，也可以使用 sp_updatestats 預存程序，這會更新所有過期的統計資料 (在 SQL Server 2000 中，無論使用期限為何，sp_updatestats 都會更新所有統計資料)。

fig04.gif

[圖 4] 透過 SQL Server Management Studio 變更資料庫設定 (按一下以放大影像)

如果您想要把更新統計資料的工作當作定期維護計畫的一部分，有一點應該要注意。那就是，UPDATE STATISTICS 和 sp_updatestats 預設都會使用之前指定的取樣等級 (若有指定的話) — 而這可能低於完整掃描。索引重建作業會以完整掃描自動更新統計資料。如果您在索引重建之後手動更新統計資料的話，最後可能會得到比較不準確的統計資料！如果透過手動更新進行的取樣掃描覆寫索引重建產生的完整掃描的話，就可能發生這種情況。另一方面，重新組織索引則完全不會更新統計資料。

同樣地，很多人的維護計畫都會在重建所有索引前後的某段時間內更新全部的統計資料 — 最後也可能得到比較不準確的統計資料而完全不知情。如果您真的決定不時重建所有索引，這也會一併處理統計資料。若是您決定採取較複雜的途徑來移除片段的話，也應當依照相同的方式來維護統計資料。以下是我的建議：

  • 分析索引，並判斷要在哪些索引上操作，以及如何移除片段。
  • 對於所有未重建的索引，更新統計資料。
  • 針對所有未編列索引的資料行更新統計資料。

如需有關統計資料的詳細資訊，請參閱白皮書《Microsoft® SQL Server 2005 中查詢最佳化工具所使用的統計資料》(英文) (microsoft.com/technet/prodtechnol/sql/2005/qrystats.mspx)。

損毀偵測

討論過效能相關的維護工作之後，我想換一下話題，探討損毀偵測和緩和措施。

要說您管理的資料庫包含的全是乏人問津的無用資訊幾乎是不可能的 — 所以您要怎麼在發生嚴重損壞的情況下，確保資料仍舊未遭損毀而且可以復原呢？籌措完整的嚴重損壞修復和高可用性策略的細節，已超過本文的討論範圍，但是有幾件簡單的事您可以開始著手進行。

大部分難以制止的損毀都是因「硬體」而起。為什麼要特別強調是「硬體」呢？這裡所謂的硬體其實是指「在 SQL Server 之下 I/O 子系統內的某個東西」。I/O 子系統是由各種元素組成，例如作業系統、檔案系統磁碟機、裝置驅動程式、RAID 控制器、纜線、網路，以及實際的磁碟機本身。看來，可能 (還有真的) 發生問題的地方還真不少。

最常見的問題之一，是當電源發生中斷而磁碟機正寫出資料庫頁面的時候。如果磁碟機無法在電源中斷之前完成寫入 (或是寫入作業已經快取，但沒有足夠的電池電源可以清除磁碟機的快取)，結果可能會在磁碟上產生不完整的頁面映像。會發生這種情況是因為 8KB 資料庫頁面實際上是由 16 個連續的 512 位元組磁碟磁區所構成。不完整的寫入作業可能寫入了新頁面的部分磁區，卻留下前一頁面映像的一些磁區。這種情況就稱為損毀頁。當發生這種情況時，您要如何偵測出來呢？

SQL Server 有個機制可以偵測這種狀況。它會從頁面的每個磁區儲存幾個位元，然後在它們的位置內寫入特定的模式 (這是發生在頁面寫入磁碟之前)。如果當讀回頁面時發現模式不同，SQL Server 就知道頁面已「損毀」，並且會產生錯誤。

SQL Server 2005 及之後的版本提供一個較為完善的機制，稱為頁總合檢查碼，它可偵測頁面上的任何損毀。動作包括在寫出頁面之前於頁面上寫入全頁總合檢查碼，然後在讀回頁面時進行測試，就跟偵測損毀頁一樣。啟用頁總合檢查碼之後，必須將頁面讀入緩衝區集區，經過某種方式的變更，然後再次寫出磁碟後以頁總合檢查碼保護。

因此，最佳的作法是對 SQL Server 2005 之前的版本啟用頁總合檢查碼，並對 SQL Server 2000 啟用損毀頁偵測。若要啟用頁總合檢查碼，請使用：

ALTER DATABASE MyDatabase SET PAGE_VERIFY CHECKSUM;

若要對 SQL Server 2000 啟用損毀頁偵測，請使用此命令：

ALTER DATABASE MyDatabase SET TORN_PAGE_DETECTION ON;

這些機制可讓您偵測出頁面上發生的損毀，但只有在讀取頁面時才偵測得出。要如何輕鬆地強制讀取所有配置的頁面呢？這麼做 (還有找出其他損毀類型) 的最佳方法是使用 DBCC CHECKDB 命令。無論指定何種選項，這個命令始終會讀取資料庫中的所有頁面，藉此確認任何頁總合檢查碼或損毀頁偵測。您也應該設定警示，如此一來，當使用者在執行查詢時碰到損毀問題時，您就可以獲知。使用嚴重性 24 錯誤的警示，您就可以收到上述所有問題的通知 ([圖 5])。

fig05.gif

[圖 5] 設定所有嚴重性 24 錯誤的警示 (按一下以放大影像)

所以，另外一個最佳作法是在資料庫上定期執行 DBCC CHECKDB，以查驗它們的完整性。這個命令有許多種變形，執行的頻率也有許多疑問。不幸的是，目前並沒有任何白皮書討論此主題。不過，因為 DBCC CHECKDB 是我為 SQL Server 2005 所寫的主要程式碼，所以我在部落格上也寫了很多與其相關的內容。請參閱我的部落格中「從各種角度看 CHECKDB (CHECKDB From Every Angle)」類別 (sqlskills.com/blogs/paul)，即可找到許多關於一致性檢查、最佳作法和 How-to 建議的深度文章。給非自願 DBA 的基本原則是，以進行完整資料庫備份的頻率來執行 DBCC CHECKDB (下文有詳細說明)。我建議您執行下列命令：

DBCC CHECKDB ('MyDatabase') WITH NO_INFOMSGS, 
  ALL_ERRORMSGS;

如果此命令有任何輸出的話，表示 DBCC 在資料庫中找到了一些損毀。因此，現在的問題是，當 DBCC CHECKDB 找到損毀時該怎麼辦。這正是備份派上用場的地方。

發生損毀或其他嚴重損壞時，最有效的復原方法是從備份還原資料庫。這是假設您原本就有備份，而且備份本身並未損毀。但人們往往想知道如果沒有備份的話，該怎麼讓嚴重損毀的資料庫恢復執行狀態。答案很簡單，您沒有辦法這麼做，一定會有某種形式的資料損失，而這些資料損失可能會破壞您的商務邏輯和相關的資料完整性。

因此定期製作備份非常重要。使用備份和還原的複雜細節已超出本文討論範圍，但且讓我提供如何建立備份策略的快速入門。

首先，您應該定期製作完整的資料庫備份。這提供您一個時間點以便稍後還原。您可以使用 BACKUP DATABASE 命令製作完整的資料庫備份。相關範例請查看《線上叢書》。若要多添一層保護，您可以使用 WITH CHECKSUM 選項，它會驗證要讀取之頁面的頁總合檢查碼 (如果有的話)，並計算整個備份的總合檢查碼。您選擇的頻率應該反映您的業務能夠承受損失的資料或工作多寡。比方說，每天製作一份完整資料庫備份表示您在發生嚴重損壞的情況下，可能損失最多一天的資料。如果您只使用完整資料庫備份，就應該處於 SIMPLE 復原模式 (通常稱為復原模式)，以避免與交易記錄成長管理相關的複雜性。

其次，始終將備份多保留幾天的時間，以防備份損毀 — 幾天前的備份總比完全沒有備份好。您也應該使用 RESTORE WITH VERIFYONLY 命令 (請同樣參閱《線上叢書》) 來查驗備份的完整性。如果您在建立備份時使用 WITH CHECKSUM 選項，執行驗證命令將檢查備份總合檢查碼是否仍舊有效，另外也會重新檢查備份當中各頁面的所有頁總合檢查碼。

第三，如果每日完整資料庫備份不符合業務所能承受的最大資料/工作損失，您應該考慮採用差異資料庫備份。差異資料庫備份是以完整資料庫備份為基礎，並且包含自前次完整資料庫備份以來的所有變更記錄 (常有人誤以為差異備份會遞增 — 其實不然)。每天製作完整資料庫備份，然後每四個小時製作差異資料庫備份，是可行的策略之一。差異備份提供了額外的時間點復原選項。如果您只使用完整資料庫和差異資料庫備份，還是應該繼續使用 SIMPLE 復原模型。

最後，最終的復原能力來自使用記錄備份。這只能在 FULL (或 BULK_LOGGED) 復原模型下使用，並且提供了自上次記錄備份以來產生的所有記錄備份。透過定期的完整資料庫 (或許加上差異資料庫) 備份來維護一組記錄備份，便有無限量的時間點可供復原 — 包括最新狀態的復原。唯一要權衡的是，除非製作記錄備份來「釋放」交易記錄，否則它會不斷增長。此處的理想策略是每天進行完整資料庫備份，每四個小時進行差異資料庫備份，然後每半個小時進行記錄備份。

決定和履行備份策略，可能是項複雜的工作。您至少應該有定期的完整資料庫備份，以確定您至少有一個時間點可以從中復原。

如您所見，要確保資料庫保持健全與可用，有幾項「必做」的工作。以下是我為接掌資料庫的非自願 DBA 所提供的最終檢查清單：

  • 移除過多的交易記錄檔案片段。
  • 正確設定自動成長。
  • 關閉任何已排定的壓縮作業。
  • 開啟立即檔案初始化。
  • 設立標準程序來偵測和移除索引片段。
  • 開啟 AUTO_CREATE_STATISTICS 和 AUTO_UPDATE_STATISTICS，另外設定一個標準程序來更新統計資料。
  • 開啟頁總合檢查碼 (或至少在 SQL Server 2000 上開啟毀損頁偵測)。
  • 採用標準程序來執行 DBCC CHECKDB。
  • 設立標準程序製作完整資料庫備份，另外進行差異和記錄備份以利時間點復原。

我在本文中已提供 T-SQL 命令，但您也可以從 Management Studio 進行很多動作。希望我為您提供了一些實用的指標來進行有效的資料庫維護。如果您有任何意見或疑問，請寄信到 paul@sqlskills.com。

Paul S. Randal 是 SQLskills.com 的常務董事，同時也是 SQL Server MVP。他在 1999 年 2007 年間服務於 Microsoft 的 SQL Server 儲存引擎 (SQL Server Storage Engine) 小組。Paul 是嚴重損壞修復、高可用性和資料庫維護方面的專家。他的部落格位於 SQLskills.com/blogs/paul。

© 2008 Microsoft Corporation and CMP Media, LLC.著作權所有，並保留一切權利。未經許可，不得部分或全部重製。