分散式交易、效能計數器和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; 
 

其他在此就不一一列舉了。您必須從某個Database Backup開始還原序列，然後還原零個或多個差異資料庫和/或交易記錄備份。更詳細的資訊不在本專欄的討論範圍之內，不過，在我為 2009 年 11 月刊撰寫的文章利用備份進行災難恢複中，詳細介紹了有關可能需要的還原序列和其他 RESTORE 選項。

使用 SSMS 時，可在還原資料庫嚮導中指定備份檔案，該嚮導會自動顯示檔案中的所有備份，並允許您選擇需要的備份。圖 1 顯示了一個樣本。

圖 1 使用 SSMS 還原資料庫嚮導顯示檔案中的多個備份。

無論選擇哪個選項，在進行災難恢複時，在正式執行還原之前，必須試還原到另一個位置，這一點至關重要。我始終遵循的原則之一是“沒有成功還原，就沒有備份。”

問題：我有一個很大的資料庫，每隔幾周就需要將它複製到開發環境中。我的問題是，最近資料庫因要容納更多資料增大了，現在將它還原到開發環境中時，它顯得太大了。如何在還原該資料庫時使它縮小一些？

解答：這是一個相當普遍的問題，遺憾的是，沒有什麼好的解決方案。

Database Backup不會以任何方式更改資料庫，它僅僅讀取所有已使用的資料庫部分，將這些部分以及一些交易記錄有關原因和程度的說明，請參閱我的部落格文章）包含在備份中。從Database Backup進行的還原僅建立檔案，寫出備份中的內容，然後對資料庫運行恢複操作。基本上，資料庫中的內容即是還原時獲得的內容。沒有選項可以用於在還原時縮減資料庫、在還原時解決索引片段問題、在還原時更新統計資料或是人們可能需要執行的任何其他動作。

那麼，如何?您的目的呢？根據具體方案，您有三種方法。

首先，可以對生產資料庫執行縮減操作，以回收空的空間。這樣可使還原的資料庫副本與生產資料庫相同，而不會浪費空間，但是成本可能會很高。生產資料庫會再次增長，因而縮減操作可能成本極高在 CPU、I/O 和交易記錄方面），並可能導致索引片段。索引片段問題必須得到解決，從而會佔用更多資源。您不會選擇這麼做。有關使用資料檔案縮減的風險的更深入說明，請參閱我的部落格文章。）您可以考慮只移除檔案末尾的可用空間 (DBCC SHRINKFILE WITH TRUNCATEONLY)，但這可能不會達到您所希望的縮減大小。

其次，如果在開發過程中只需要還原一次生產資料庫，則需要有足夠空間來還原完整資料庫，然後進行縮減以回收空間。在此之後，需要確定是否要解決縮減操作所產生的片段。

如果要執行查詢以進行效能測試或進行報告，片段可能會極大降低這些查詢的效能。如果不運行這類查詢，則完全不必整理片段。若要解決片段問題，不能重建索引使用 ALTER INDEX … REBUILD 命令），因為這需要額外空間並會導致資料庫再次增大，您需要重新組織索引使用 ALTER INDEX … REORGANIZE 命令）。

如果一定要整理片段，請務必將資料庫切換至 SIMPLE 恢複模型，以便交易記錄不會因重新組織所產生的所有交易記錄記錄而增長。如果將資料庫保留為 FULL 恢複模型，則日誌會繼續增長，除非您將記錄備份您可能希望避免處理這些內容）寫入資料庫的開發副本中。

最後，如果在開發過程中需要多次還原生產資料庫，則不會希望多次重複第二種方法中的步驟。在這種情況下，最好按照第二種方法中的步驟執行，然後建立縮減可能整理了片段）資料庫的另一個備份。

此第二個備份隨後可以用於執行最小大小生產資料庫的多次還原。

總而言之，要將擁有大量可用空間的生產資料庫移動至開發環境，而不在初始還原時包括這些 SQL 可用空間，是無法實現的。

原文地址

本文來源：微軟TechNet中文站