分布式事務、性能計數器和SQL備份
問題：我們使用了大量分布式事務，正研究數據庫鏡像以使我們的關鍵數據庫之一具備高可用性。在測試過程中我們發現，在嘗試對鏡像數據庫進行故障轉移后，分布式事務有時會失敗。能否說明這是為什么？
解答：這實際上是記錄在案的使用分布式事務的限制。在使用數據庫鏡像或日志傳送時會存在該限制，基本上對于在執行故障轉移后 Windows 服務器名稱會有所不同的任何技術，都存在該限制。
在使用 Microsoft 分布式事務處理協調器 (MSDTC) 事務時，本地事務處理協調器具有資源 ID，用于標識運行該協調器的服務器。在進行鏡像故障轉移時，主體數據庫會承載于另一個服務器上（鏡像伙伴），因此事務處理協調器的資源 ID 會有所不同。
如果某個分布式事務處于活動狀態，鏡像伙伴上的事務處理協調器會嘗試識別該事務的狀態，但是無法識別，因為它具有錯誤的資源 ID；MSDTC 無法識別該 ID，因為它最初未包含在該分布式事務中。在這種情況下，必須終止該分布式事務，這便是您所看到的行為。
跨數據庫事務（涉及多個數據庫中的更新的簡單事務）也存在類似問題。如果所涉及的一個數據庫進行了鏡像，另外一個沒有鏡像，則跨數據庫事務可以在這兩個數據庫中提交。如果進行強制鏡像故障轉移（當主體與鏡像未同步，且執行允許丟失數據的手動故障轉移時），在鏡像數據庫中提交的事務可能會丟失，這會破壞跨數據庫事務的完整性。
這可能會在鏡像數據庫未同步時發生（有關詳細信息，請參閱我發表的 2009 年 6 月專欄），因此提交的跨數據庫事務的日志記錄尚未發送到鏡像。在強制故障轉移后，新主體數據庫中不存在該事務，因此會破壞跨數據庫事務的完整性。
問題：最近我對某些性能計數器進行監視，以解決一個數據庫存儲方面的問題。在這個過程中，我注意到了一些非常奇怪的現象：盡管數據庫中未進行任何操作，數據庫文件仍然存在寫入活動。數據和日志文件都存在這種情況。甚至在我確保未連接到 SQL Server 的情況下，這種情況仍在繼續。既然沒有連接，怎么會存在 I/O 活動呢？
解答：SQL Server 有很多需要運行的內部操作；這些操作稱為后臺任務。系統中會執行一個或多個后臺任務，從而導致 I/O 活動。下面簡單列出了可能的原因：
虛影清理：刪除操作僅將記錄標記為已刪除，以優化取消操作時的性能；該操作實際上不對空間清零。一旦提交了刪除操作，便必須執行某種操作，以從數據庫中實際移除被刪除的記錄。這是由虛影清理任務完成的。有關詳細信息，請參閱我的博客文章，這篇文章還說明了如何檢查虛影清理任務是否正在運行。
自動縮減：啟用此任務可以自動移除數據庫中的空空間。此任務的工作方式是，將數據文件末尾的頁面移動至開頭，合并末尾的可用空間，然后截斷文件。您當然可以啟用此任務，但絕對不應這樣做，因為這樣會導致索引碎片問題（從而降低性能）并會占用大量資源。通常，還會為數據庫啟用自動增長，因此可能會陷入縮減-增長-縮減-增長的循環，這就做了大量無用功。您可以使用下面的查詢檢查所有數據庫的狀態：
- SELECT name, is_auto_shrink_on FROM sys.databases;
延遲丟棄：此任務負責執行丟棄或截斷表和索引所需的工作（進行索引重新生成操作可能引起索引丟棄，即生成新索引，然后丟棄舊索引）。對于小型表和索引，會立即執行取消分配。對于較大的表和索性，會通過后臺任務成批執行取消分配。這是為了確保獲取所有必需的鎖，而不致耗盡內存。您可以按照此處的聯機叢書中所述，使用各種延遲丟棄性能計數器監視此任務。
延遲寫入：此任務負責從內存中緩存（稱為緩沖池）移除舊頁面。當服務器內存不足時，即使對頁面進行了更改，也可能必須將其移除。在這種情況下，更改過的頁面必須先寫入磁盤，之后才能從內存中移除。您可以按照此處的聯機叢書中所述，使用“Lazy writes/sec”性能計數器監視此任務。
以上所有這些任務都可能對數據庫進行更改。它們全都使用事務進行更改，只要提交事務，事務所生成的事務日志記錄就必須寫入磁盤上的數據庫日志部分。因為會時常對數據庫進行更改，所以還必須存在檢查點，以將更改的數據文件頁面刷新到磁盤。有關詳細信息，請參閱我為 TechNet 雜志 2009 年 2 月刊撰寫的文章了解 SQL Server 中的日志記錄和恢復功能。
可以看到，不存在活動的 SQL Server 連接，不一定意味著進程處于靜止狀態，它可能正忙于執行一個或多個后臺任務。如果所有數據庫活動都完成很久后，I/O 活動仍在進行，可能還需要檢查是否在運行計劃作業。
問題：我是非自愿 DBA，正在嘗試不同的任務以盡快熟悉工作。前任 DBA 設置作業將備份寫入一個文件，但是我不知道如何還原這些備份。是否可以查看文件中的備份內容？我該如何正確地還原這些備份？
解答：盡管可以將備份附加到同一個文件，但是大多數人將每個備份放在名稱有意義的（通常還帶日期/時間戳組合）的獨立文件中。這樣有助于避免您所面臨的問題，也便于執行其他任務：
每個備份都位于自己的文件中時，出于安全原因而復制備份會十分簡單。如果所有備份都位于一個文件中，就只能通過復制整個備份文件來創建最新備份的副本。
當所有備份都位于一個文件中時，不能刪除舊備份。
如果每個備份都有單獨命名的文件，則不可能意外覆蓋現有副本。
遺憾的是，這一點對您毫無幫助，您已在一個文件中包含多個備份。不過，可以通過兩種方式還原副本：手動還原或使用 SQL Server Management Studio (SSMS) 還原。
若要查看文件中的備份內容，可以使用 SSMS 創建引用該文件的新備份設備。創建引用后，可以顯示該備份設備中的內容的備份詳細信息。也可以使用 RESTORE HEADERONLY 命令。這兩種方法都會檢查備份設備，并提供一行輸出，用于描述文件中的每個備份。SSMS 使用友好名稱標識備份類型。若要使用正確的語法，需要按照 SQL Server 聯機叢書中有關該命令的條目（有關 SQL Server 2008 版本，請參閱此處）所提供的信息，確定每個備份的備份類型，從而可以使用適當的 RESTORE 命令還原備份。
您還需要確定要還原的備份。這有一點棘手，因為所需要的 RESTORE HEADERONLY 的輸出列名稱與您必須用于還原的選項不匹配。文件中的備份從 1 開始編號（1 表示最舊），在名為“Position”的列中可以找到編號。若要還原備份，必須在 RESTORE 命令的 WITH FILE=<編號> 部分中使用相應編號。下面是一個示例：
- RESTORE DATABASE test FROM DISK = 'C:\SQLskills\test.bak'
- WITH FILE = 1, NORECOVERY;RESTORE LOG test
- FROM DISK = 'C:\SQLskills\test.bak'
- WITH FILE = 2, NORECOVERY;
其他在此就不一一列舉了。您必須從某個數據庫備份開始還原序列，然后還原零個或多個差異數據庫和/或事務日志備份。更詳細的信息不在本專欄的討論范圍之內，不過，在我為 2009 年 11 月刊撰寫的文章利用備份進行災難恢復中，詳細介紹了有關可能需要的還原序列和其他 RESTORE 選項。
使用 SSMS 時，可在還原數據庫向導中指定備份文件，該向導會自動顯示文件中的所有備份，并允許您選擇需要的備份。圖 1 顯示了一個示例。
.jpg)
圖 1 使用 SSMS 還原數據庫向導顯示文件中的多個備份。
無論選擇哪個選項，在進行災難恢復時，在正式執行還原之前，必須試還原到另一個位置，這一點至關重要。我始終遵循的原則之一是“沒有成功還原，就沒有備份。”
問題：我有一個很大的數據庫，每隔幾周就需要將它復制到開發環境中。我的問題是，最近數據庫因要容納更多數據增大了，現在將它還原到開發環境中時，它顯得太大了。如何在還原該數據庫時使它縮小一些？
解答：這是一個相當普遍的問題，遺憾的是，沒有什么好的解決方法。
數據庫備份不會以任何方式更改數據庫，它僅僅讀取所有已使用的數據庫部分，將這些部分以及一些事務日志（有關原因和程度的說明，請參閱我的博客文章）包含在備份中。從數據庫備份進行的還原僅創建文件，寫出備份中的內容，然后對數據庫運行恢復操作。基本上，數據庫中的內容即是還原時獲得的內容。沒有選項可以用于在還原時縮減數據庫、在還原時解決索引碎片問題、在還原時更新統計數據或是人們可能需要執行的任何其他操作。
那么，如何實現您的目的呢？根據具體方案，您有三種方法。
首先，可以對生產數據庫執行縮減操作，以回收空的空間。這樣可使還原的數據庫副本與生產數據庫相同，而不會浪費空間，但是成本可能會很高。生產數據庫會再次增長，因而縮減操作可能成本極高（在 CPU、I/O 和事務日志方面），并可能導致索引碎片。索引碎片問題必須得到解決，從而會占用更多資源。您不會選擇這么做。（有關使用數據文件縮減的風險的更深入說明，請參閱我的博客文章。）您可以考慮只移除文件末尾的可用空間 (DBCC SHRINKFILE WITH TRUNCATEONLY)，但這可能不會達到您所希望的縮減大小。
其次，如果在開發過程中只需要還原一次生產數據庫，則需要有足夠空間來還原完整數據庫，然后進行縮減以回收空間。在此之后，需要確定是否要解決縮減操作所產生的碎片。
如果要運行查詢以進行性能測試或進行報告，碎片可能會極大降低這些查詢的性能。如果不運行這類查詢，則完全不必整理碎片。若要解決碎片問題，不能重新生成索引（使用 ALTER INDEX … REBUILD 命令），因為這需要額外空間并會導致數據庫再次增大，您需要重新組織索引（使用 ALTER INDEX … REORGANIZE 命令）。
如果一定要整理碎片，請務必將數據庫切換至 SIMPLE 恢復模型，以便事務日志不會因重新組織所生成的所有事務日志記錄而增長。如果將數據庫保留為 FULL 恢復模型，則日志會繼續增長，除非您將日志備份（您可能希望避免處理這些內容）寫入數據庫的開發副本中。
最后，如果在開發過程中需要多次還原生產數據庫，則不會希望多次重復第二種方法中的步驟。在這種情況下，最好按照第二種方法中的步驟執行，然后創建縮減（可能整理了碎片）數據庫的另一個備份。
此第二個備份隨后可以用于執行最小大小生產數據庫的多次還原。
總而言之，要將擁有大量可用空間的生產數據庫移動至開發環境，而不在初始還原時包括這些 SQL 可用空間，是無法實現的。
本文來源：微軟TechNet中文站
