SQL問題與解答-資料庫移動、效能最佳化、備份和鏡像

新陣列移動日

問：我們當前的 RAID 很快就填滿了，因此需要將一些 SQL Server 2005 資料庫移到其他位置。新陣列已準備就緒，並且我一直在為移動資料庫作準備。我剛剛發現其中一個資料庫是事務複製發行伺服器，我知道這表示我不能移動該資料庫。我應怎樣做？

答：對您來說有一個好訊息 － 只有 SQL Server 2000和更早版本）具有以下局限性：限制在未重新初始化事務複製或直接更改各種系統資料表的情況下移動發行集資料庫。

對於 SQL Server 2005 和 SQL Server 2008，有一個記錄下來的過程，您可以按照它移動資料庫，而不必對事務複製執行任何操作，但要求資料庫保持串連到同一 SQL Server 執行個體。移動時必須停機一段時間，因為當資料庫檔案仍處於聯機狀態時無法將其移動。過程如下：

首先，使用下面的代碼使資料庫離線。如果有使用者串連到資料庫，則需要先斷開這些使用者的串連，此過程才能成功：          

 

  
ALTER DATABASE MyDatabaseName SET OFFLINE; 
 

接著，將資料檔案複製到新位置。使用複製而不是移動，可在發生任何錯誤時進行快速復原否則，必須執行還原）。然後，使用以下代碼告知 SQL Server 每個檔案的新位置

 

  
ALTER DATABASE MyDatabaseName   
  
MODIFY FILE  
  
   (NAME = N'LogicalFileName',  
  
   FILENAME = N'pathname\filename'); 
 

物理上複製了所有檔案並更新了 SQL Server 中的檔案位置後，使用以下代碼使資料庫恢複聯機狀態：

 

  
ALTER DATABASE MyDatabaseName SET ONLINE; 
 

關閉頁鎖存

問：我在理解一些效能最佳化相關概念時存在疑問。我幾次讀到需要防止“頁鎖存”問題。我不知道“頁”或“鎖存”是什麼意思，或者說為什麼頁鎖存甚至是一個問題。您能解釋所有這些疑問嗎？

答：SQL Server 資料庫中的所有資料都儲存在資料檔案中。在內部，這些檔案組織成大小為 8 KB 的資料區塊序列，稱為頁。頁是 SQL Server 可以管理的基本存放裝置和 I/O 單位。頁通常位於磁碟上的資料檔案中，並且在處理任何查詢之前，需要 SQL Server 的緩衝稱為緩衝池）來進行讀取。

SQL Server 使用各種頁來儲存不同類型的關係資料例如，表中的行、非群集索引中的行或者文本/LOB 資料）。還有一些頁儲存 SQL Server 組織和訪問儲存關係資料的頁所需的內部資料結構部分。

鎖存 是一種輕量級內部機制，SQL Server 使用它來同步對緩衝內的某個頁的訪問。您需要注意兩種類型的頁鎖存 － 常規頁鎖存 和頁 I/O 鎖存。如果 SQL Server 線程必須等待擷取其中一個鎖存，則表示出現效能問題。

當 SQL Server 正等待從磁碟中讀取資料檔案的某部分時，則可能會導致頁 I/O 鎖存等待。如果頁 I/O 鎖存持續很長時間，則通常表明底層磁碟子系統出現效能問題即，該子系統過載）。

當 SQL Server 中的多個線程嘗試訪問記憶體中的相同 8 KB 資料檔案頁時，就存在對該頁訪問權的爭用，這可能會導致頁鎖存等待。最常見的這種情況涉及大量使用 tempdb 資料庫中的臨時小對象。

有關如何監視和減少頁鎖存等待的更深入說明不屬於本專欄文章的範圍，但您可以在以下資料中找到更多資訊：

SQL Server 2008 聯機叢書中的“SQL Server Wait Statistics 對象”部分，它說明如何使用系統監視器監視等待統計資料。

SQL Server 2008 聯機叢書中的“sys.dm_os_wait_stats”部分，它列出了常見的 SQL Server 等待類型及其含義，並說明如何從 SQL Server 內部監視等待統計資料。

白皮書《SQL Server 2008 中的效能問題故障排除》，它提供各種故障排除查詢和技術，包括等待統計資料。

通查資料庫快照集

問：我剛剛發現了資料庫快照集。現在，我考慮將它們用作完全復原模式和記錄備份的替代方法。我將大約每小時建立一次快照，這樣當出現錯誤時，我可以拉回損壞的資料。這似乎是一種更省事且更快的還原方法。您認為進行這種更改會產生任何問題嗎？

答：會產生問題，資料庫快照集不是全面的災難恢複策略的實用或可行替代方法。在從災難完全恢複方面，資料庫快照集不具備與交易記錄備份相同的功能。資料庫快照集不包含資料庫中所有頁的副本，它只包含自第一次建立資料庫後更改過的頁的副本。這意味著，如果資料庫有任何損壞，則沒有底層資料庫的資料庫快照集將沒有任何用處。它只是資料庫中不同頁的集合，不能用於恢複。

您可以通過資料庫快照集拉回不小心從資料庫中刪除的資料，但前提是資料庫本身仍可用。例如，如果從資料庫中刪除的表仍存在於快照中，則可以使用快照重新建立該表。

也就是因為潛在的效能問題，建立太多資料庫快照集作為每一個半小時的交易記錄備份的替代方法）不是一個好主意。在可以交換資料庫頁之前請參閱“關閉頁鎖存”部分中的答案說明），必須先將頁同步地複製到尚未包含該頁版本的所有現有資料庫快照集中。隨著建立的資料庫快照集越來越多，要產生的頁副本也越來越多，從而導致效能下降。

不要建立太多資料庫快照集的另一個原因是每個資料庫快照集將包含資料庫頁更改前的副本。每個副本將隨著資料庫中更改的內容增多而增大。這可能會導致磁碟空間問題和效能問題。

資料庫快照集不是為了替代頻繁記錄備份而設計的。您可以在白皮書 Database Snapshot Performance Considerations Under I/O-Intensive Workloads 中閱讀關於資料庫快照集的效能影響的更深入研究。

此外，如果您要使用完全復原模式和交易記錄備份，則很明顯您對最多能夠恢複到災痛點和/或使用時間點還原感興趣。有關恢複到災痛點和還原時間點的說明，請分別參閱我於 2009 年 7 月和 2009 年 11 月發布的文章“瞭解 SQL Server 備份”和“SQL Server：利用備份進行災難恢複”。）

鏡像，鏡像

問：我被要求為資料庫設定資料庫鏡像，但我擔心資料庫鏡像不能協助解決我們的問題。我們的 SAN 存在一些損壞問題，因此打算通過資料庫鏡像防止我們受到損壞。損壞不會自動發送到鏡像嗎？資料庫鏡像如何協助我們解決此問題？

答：這是一個會引起大量混淆的問題。任何提供冗餘資料庫副本的技術看起來似乎都容易受到從主體傳播到鏡像資料庫以使用資料庫鏡像術語）的損壞的影響，但實際上這種情況不會發生。

問題的關鍵在於理解鏡像資料庫的維護方式。如果底層同步機制將完整資料庫頁從主體複製到鏡像資料庫，則損壞肯定會傳播到鏡像。然後，主體中損壞的頁將被放置在鏡像中。

但是，資料庫鏡像專門避免了這種情況，因為它不將一個資料庫中的資料庫頁複製到另一個資料庫。資料庫鏡像過程是將交易記錄記錄從主體資料庫複製到鏡像來完成的。交易記錄記錄說明對資料庫頁所做的物理更改，它們不包含實際頁本身。有關交易記錄記錄、日誌記錄和恢複的完整說明，請參閱我於 2009 年 2 月發布的文章：“瞭解 SQL Server 中的日誌記錄和恢複功能。”）

即使資料庫頁被主體資料庫的底層 I/O 子系統損壞，該損壞也不可能直接傳播到鏡像資料庫。可能出現的最壞情況是如果 SQL Server 未檢測到頁面損壞由於未啟用頁面校正和），將使用已損壞的列值來計算儲存在資料庫中的值。產生的不正確結果將傳播到鏡像資料庫，從而產生二級損壞效果。如前所述，如果啟用了頁面校正和，則從磁碟中讀取頁面時，這種損壞仍將檢測不到，從而不會出現二級損壞。

此行為還說明了為什麼對主體資料庫運行一致性檢查不會產生關於鏡像資料庫的一致性狀態的任何資訊，反之亦然。它們是通過傳送對資料庫而不是實際資料庫頁的物理更改的說明來保持同步的兩個不同資料庫。

原文地址

本文來源：微軟TechNet中文站