SQL Q & a：資料庫的移動、備份、效能微調與鏡像製作

發行項
08/18/2016

Paul S。 Randal

新的陣列移動日

**問：**我們目前的 RAID 填滿快速，所以我們需要其他地方移動某些 SQL Server 2005 資料庫。新的陣列已準備好，我已準備要移動資料庫。我只是發現其中一個資料庫是交易式複寫的發行者，和我知道這表示我 can’t 移動資料庫。我該怎麼做？

**答：**沒有為您的好消息 — 僅 SQL Server 2000 (或更早的) 有限制移動而不需重新初始化交易式複寫，或是直接變更各種系統資料表的發行集資料庫的限制。

SQL Server 2005] 和 [SQL Server 2008 中沒有記錄的程序，可讓您移動而不需做任何處理交易的複寫，只要維持資料庫的資料庫附加到 SQL Server 的同一個執行個體。您已經接受某些的停機時間如有 ’s 不能移動資料庫檔案，而 ’s 仍在線上。程序是，如下所示：

第一次，採用離線使用以下程式碼的資料庫。如果連接到資料庫的使用者您需要先進行此程序，才能繼續放：

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;

關閉頁面閂鎖

**問：**我時發生了解周圍效能調整概念的問題。我讀取數次必須避免「頁面閂鎖」問題。我 don’t 知道它表示「頁」或「閂鎖，」，或甚至頁面閂鎖可以為什麼會有問題。您可以解釋這所有吗？

**答：**在 SQL Server 資料庫中的所有資料都儲存在資料檔案中。內部，這些檔案會編入稱為頁面 8 KB 區塊的序列。網頁是儲存和 SQL Server 可以管理的 I/O 的基本單位。網頁通常是磁碟，在資料檔案中，並需要 SQL Server ’s (稱為 緩衝集區 ) 來處理任何查詢之前，請先讀取它們的快取。

SQL Server 會使用不同的頁面，來儲存不同類型的關聯式資料 (例如一個的資料表的非叢集索引或文字/LOB 資料資料列的資料列)。也是儲存部份所需的 SQL Server，來組織及頁儲存關聯式資料的內部資料結構的網頁。

閂鎖輕量的內部機制來同步存取快取中的網頁會使用 SQL Server 中取得。有兩種類型的頁面閂鎖需要注意 — regularpage 閂鎖 和 頁面 I/O 閂鎖 。如果 SQL Server 執行緒已經取得一個這些閂鎖等候，表示效能問題。

當 SQL Server 等候的一部份從磁碟讀取的資料檔案時，它可能會造成網頁 I/O 的閂鎖等候。如果 I/O 頁面閂鎖花時間過多的數量，這通常表示基礎的磁碟子系統的效能問題 (也就是其超載)。

當 SQL Server 中的多個執行緒嘗試存取相同的記憶體，8 KB 的資料檔案頁面，並存取網頁的競爭，這可能會造成頁面閂鎖等候。最常見的項目，這會涉及大量使用小型的暫存物件，在 tempdb 資料庫中。

更深層的說明如何監視，以及減輕頁面閂鎖等候的這個的資料行的範圍之外，但您可以找到更多的資訊，在：

SQL Server 2008 線上叢書，在「 SQL Server、等候統計資料物件」] 區段中顯示如何監視等候使用系統監視器的統計資料。
SQL Server 2008 線上叢書，在「 sys.dm_os_wait_stats 」] 區段會列出常見的 SQL Server 等待類型和及其意義，以及如何監視等候統計資料，從 SQL Server 內。
「疑難排解效能問題，在 SQL Server 2008 」白皮書提供各種疑難排解的查詢，並包括的技術等統計資料。

尋找透過資料庫快照集

**問：**我只是發現資料庫快照集。現在我考慮它們使用另一種完整的復原模型及記錄檔備份。我建立快照集每小時或所以，這樣一來，如果發生錯誤，我可以拉回損毀的資料。它們看起來就像許多較少的麻煩，並更快的方式，來還原。沒有發現任何問題做這樣的變更吗？

**答：**是的資料庫快照集並不實用或可行的替代的全面性的嚴重損壞修復策略。資料庫快照集並不會提供相同的功能，為方面完全從損壞中復原的交易記錄檔備份。資料庫快照集並不會包含資料庫中的所有頁面的複本，只有已變更，因為它是第一個建立。這表示如果資料庫以任何方式損毀，資料庫快照集是無用沒有基礎資料庫。它 ’s 只是從資料庫的不同頁面的集合和 can’t 用於復原。

資料庫快照集可讓您拉回已從的資料庫不小心刪除的資料，只要資料庫本身是否可以使用。如果在快照集仍存在已卸除的資料表在資料庫中，就例如您可以使用它來重新建立該已卸除的資料表。

所要說它 ’s 不好建立太多的 (做為替代的每 one-half-小時交易記錄檔備份) 的資料庫的快照集，因為潛在的效能問題。您可以交換資料庫頁面之前 (請參閱中將「關閉頁面閂鎖區段」答案中說明)，您必須先以同步方式複製頁面到所有現有的「資料庫」快照，已經不包含該網頁的版本。您在建立多個資料庫快照集以上的頁面複製您需要進行和效能降低。

不建立太多的資料庫快照集其他原因之一是每一個會包含 pre-change 複本的資料庫分頁。每個將增加更多的資料庫變更。這可能會導致磁碟空間的問題，以及效能問題。

資料庫快照集不被設計為替代的經常性的記錄檔備份。您可以閱讀的「的資料庫快照集效能考量，我/O-高工作負載在」白皮書中的資料庫快照集的效能影響更深入的研究。

而且，如果您使用完整復原模式和交易記錄檔備份，然後您 ’re 顯然興趣能夠修復嚴重損壞及 (或) 產生的點使用的時間點還原。 (如需這些項目的說明，請參閱我 7 月 2009年和 11 月 2009年的文章「的瞭解 SQL Server 備份」和「 SQL Server：修復嚴重損壞使用備份」分別)。

鏡像的鏡像

**問：**我被要求設定為我們的資料庫的資料庫鏡像，但我 ’m 擔心資料庫鏡像 isn’t 將幫助我們的問題。我們與我們的 SAN，有一些損毀的問題，讓計劃，就是讓保護我們從損毀的資料庫鏡像。 won’t 任何損毀自動透過傳送到鏡像嗎? 資料庫鏡像到這幫助的方式？

**答：**這是會造成混淆的很多的問題。它會看起來提供冗餘的複本資料庫的任何技術可能會受到損毀從主體傳播到鏡像資料庫來使用資料庫鏡像術語) — 但實際上不會發生。

問題的關鍵在於瞭解鏡像資料庫維護的方式而定。損毀就肯定會傳送到鏡像如果基礎的同步處理機制從主體複製完整的資料庫頁面到鏡像資料庫。從主體的損毀頁會被置於鏡像。

但是，資料庫鏡像特別避免這因為它 doesn’t 將資料庫分頁從一個資料庫複製到其他。資料庫鏡像的運作方式是從主體資料庫的交易記錄檔記錄複製到鏡像。交易記錄檔記錄描述實體資料庫的頁面所做的變更，並不包含實際的網頁本身。 (如交易記錄檔資料錄的完整說明，記錄及修復看到我從 2 月 2009年的文件：“了解記錄和 SQL Server 中修復.”)

即使由基礎 I/O 子系統的主體資料庫的資料庫頁面已損毀，有 ’s 沒有該損毀，直接將傳播到鏡像資料庫的方法。可能會發生最壞的打算，是如果 SQL Server doesn’t 偵測頁面損毀 (因為頁總和檢查碼不會啟用)，和損毀的資料行值用來計算資料庫中所儲存的值。產生不正確的結果會傳播到鏡像資料庫 — 秒順序損毀的效果。前面提，如果啟用頁總合檢查碼，頁面讀取磁碟，和第二個順序損毀，就不會發生時，還是會維持未偵測到這種損毀。

這個行為也會說明為什麼執行上主體資料庫的一致性檢查 doesn’t 產生任何資訊的一致性狀態的鏡像資料庫，反之亦然。它們是兩個不同的資料庫，資料庫 [不實際的資料庫頁面保持同步所傳送的實體變更的描述。

編者小記：感謝至 Kimberly L。 Tripp 的 SQLskills.com 提供技術檢閱這個月 ’s 資料行。

Paul S。 Randal SQLskills.com ，Microsoft 地區的指導和 SQL Server MVP 的管理的指導。他曾在 SQL Server 儲存引擎小組在 Microsoft 從 1999年 2007。他的 SQL Server 2005 中撰寫 DBCC CHECKDB/修復和 SQL Server 2008 開發期間是負責核心儲存引擎。 Randal 是在嚴重損壞修復、高可用性和資料庫的維護上的專家，定期在世界各地的會議主持人。他的部落格，在 SQLskills.com/blogs/paul 和您] 可以找到他在 Twitter.com/PaulRandal Twitter 上。

共用方式為