亚洲国产天堂ΑV日本国产,91视频网,久久精品青草社区

您當(dāng)前所在位置：首頁 → 數(shù)據(jù)庫 → MSSQL → 分布式事務(wù)、性能計數(shù)器和SQL備份

分布式事務(wù)、性能計數(shù)器和SQL備份 時間：2015-06-28 00:00:00 來源：IT貓撲網(wǎng) 作者：網(wǎng)管聯(lián)盟 我要評論(1)

問題：我們使用了大量分布式事務(wù)，正研究數(shù)據(jù)庫鏡像以使我們的關(guān)鍵數(shù)據(jù)庫之一具備高可用性。在測試過程中我們發(fā)現(xiàn)，在嘗試對鏡像數(shù)據(jù)庫進行故障轉(zhuǎn)移后，分布式事務(wù)有時會失敗。能否說明這是為什么？

解答：這實際上是記錄在案的使用分布式事務(wù)的限制。在使用數(shù)據(jù)庫鏡像或日志傳送時會存在該限制，基本上對于在執(zhí)行故障轉(zhuǎn)移后 Windows 服務(wù)器名稱會有所不同的任何技術(shù)，都存在該限制。

在使用 Microsoft 分布式事務(wù)處理協(xié)調(diào)器 (MSDTC) 事務(wù)時，本地事務(wù)處理協(xié)調(diào)器具有資源 ID，用于標識運行該協(xié)調(diào)器的服務(wù)器。在進行鏡像故障轉(zhuǎn)移時，主體數(shù)據(jù)庫會承載于另一個服務(wù)器上（鏡像伙伴），因此事務(wù)處理協(xié)調(diào)器的資源 ID 會有所不同。

如果某個分布式事務(wù)處于活動狀態(tài)，鏡像伙伴上的事務(wù)處理協(xié)調(diào)器會嘗試識別該事務(wù)的狀態(tài)，但是無法識別，因為它具有錯誤的資源 ID；MSDTC 無法識別該 ID，因為它最初未包含在該分布式事務(wù)中。在這種情況下，必須終止該分布式事務(wù)，這便是您所看到的行為。

跨數(shù)據(jù)庫事務(wù)（涉及多個數(shù)據(jù)庫中的更新的簡單事務(wù)）也存在類似問題。如果所涉及的一個數(shù)據(jù)庫進行了鏡像，另外一個沒有鏡像，則跨數(shù)據(jù)庫事務(wù)可以在這兩個數(shù)據(jù)庫中提交。如果進行強制鏡像故障轉(zhuǎn)移（當(dāng)主體與鏡像未同步，且執(zhí)行允許丟失數(shù)據(jù)的手動故障轉(zhuǎn)移時），在鏡像數(shù)據(jù)庫中提交的事務(wù)可能會丟失，這會破壞跨數(shù)據(jù)庫事務(wù)的完整性。

這可能會在鏡像數(shù)據(jù)庫未同步時發(fā)生（有關(guān)詳細信息，請參閱我發(fā)表的 2009 年 6 月專欄），因此提交的跨數(shù)據(jù)庫事務(wù)的日志記錄尚未發(fā)送到鏡像。在強制故障轉(zhuǎn)移后，新主體數(shù)據(jù)庫中不存在該事務(wù)，因此會破壞跨數(shù)據(jù)庫事務(wù)的完整性。

問題：最近我對某些性能計數(shù)器進行監(jiān)視，以解決一個數(shù)據(jù)庫存儲方面的問題。在這個過程中，我注意到了一些非常奇怪的現(xiàn)象：盡管數(shù)據(jù)庫中未進行任何操作，數(shù)據(jù)庫文件仍然存在寫入活動。數(shù)據(jù)和日志文件都存在這種情況。甚至在我確保未連接到 SQL Server 的情況下，這種情況仍在繼續(xù)。既然沒有連接，怎么會存在 I/O 活動呢？

解答：SQL Server 有很多需要運行的內(nèi)部操作；這些操作稱為后臺任務(wù)。系統(tǒng)中會執(zhí)行一個或多個后臺任務(wù)，從而導(dǎo)致 I/O 活動。下面簡單列出了可能的原因：

虛影清理：刪除操作僅將記錄標記為已刪除，以優(yōu)化取消操作時的性能；該操作實際上不對空間清零。一旦提交了刪除操作，便必須執(zhí)行某種操作，以從數(shù)據(jù)庫中實際移除被刪除的記錄。這是由虛影清理任務(wù)完成的。有關(guān)詳細信息，請參閱我的博客文章，這篇文章還說明了如何檢查虛影清理任務(wù)是否正在運行。

自動縮減：啟用此任務(wù)可以自動移除數(shù)據(jù)庫中的空空間。此任務(wù)的工作方式是，將數(shù)據(jù)文件末尾的頁面移動至開頭，合并末尾的可用空間，然后截斷文件。您當(dāng)然可以啟用此任務(wù)，但絕對不應(yīng)這樣做，因為這樣會導(dǎo)致索引碎片問題（從而降低性能）并會占用大量資源。通常，還會為數(shù)據(jù)庫啟用自動增長，因此可能會陷入縮減-增長-縮減-增長的循環(huán)，這就做了大量無用功。您可以使用下面的查詢檢查所有數(shù)據(jù)庫的狀態(tài)：

SELECT?name,?is_auto_shrink_on?FROM?sys.databases;?

延遲丟棄：此任務(wù)負責(zé)執(zhí)行丟棄或截斷表和索引所需的工作（進行索引重新生成操作可能引起索引丟棄，即生成新索引，然后丟棄舊索引）。對于小型表和索引，會立即執(zhí)行取消分配。對于較大的表和索性，會通過后臺任務(wù)成批執(zhí)行取消分配。這是為了確保獲取所有必需的鎖，而不致耗盡內(nèi)存。您可以按照此處的聯(lián)機叢書中所述，使用各種延遲丟棄性能計數(shù)器監(jiān)視此任務(wù)。

延遲寫入：此任務(wù)負責(zé)從內(nèi)存中緩存（稱為緩沖池）移除舊頁面。當(dāng)服務(wù)器內(nèi)存不足時，即使對頁面進行了更改，也可能必須將其移除。在這種情況下，更改過的頁面必須先寫入磁盤，之后才能從內(nèi)存中移除。您可以按照此處的聯(lián)機叢書中所述，使用"Lazy writes/sec"性能計數(shù)器監(jiān)視此任務(wù)。

以上所有這些任務(wù)都可能對數(shù)據(jù)庫進行更改。它們?nèi)际褂檬聞?wù)進行更改，只要提交事務(wù)，事務(wù)所生成的事務(wù)日志記錄就必須寫入磁盤上的數(shù)據(jù)庫日志部分。因為會時常對數(shù)據(jù)庫進行更改，所以還必須存在檢查點，以將更改的數(shù)據(jù)文件頁面刷新到磁盤。有關(guān)詳細信息，請參閱我為 TechNet 雜志 2009 年 2 月刊撰寫的文章了解 SQL Server 中的日志記錄和恢復(fù)功能。

可以看到，不存在活動的 SQL Server 連接，不一定意味著進程處于靜止狀態(tài)，它可能正忙于執(zhí)行一個或多個后臺任務(wù)。如果所有數(shù)據(jù)庫活動都完成很久后，I/O 活動仍在進行，可能還需要檢查是否在運行計劃作業(yè)。

問題：我是非自愿 DBA，正在嘗試不同的任務(wù)以盡快熟悉工作。前任 DBA 設(shè)置作業(yè)將備份寫入一個文件，但是我不知道如何還原這些備份。是否可以查看文件中的備份內(nèi)容？我該如何正確地還原這些備份？

解答：盡管可以將備份附加到同一個文件，但是大多數(shù)人將每個備份放在名稱有意義的（通常還帶日期/時間戳組合）的獨立文件中。這樣有助于避免您所面臨的問題，也便于執(zhí)行其他任務(wù)：

每個備份都位于自己的文件中時，出于安全原因而復(fù)制備份會十分簡單。如果所有備份都位于一個文件中，就只能通過復(fù)制整個備份文件來創(chuàng)建最新備份的副本。
當(dāng)所有備份都位于一個文件中時，不能刪除舊備份。
如果每個備份都有單獨命名的文件，則不可能意外覆蓋現(xiàn)有副本。
遺憾的是，這一點對您毫無幫助，您已在一個文件中包含多個備份。不過，可以通過兩種方式還原副本：手動還原或使用 SQL Server Management Studio (SSMS) 還原。

若要查看文件中的備份內(nèi)容，可以使用 SSMS 創(chuàng)建引用該文件的新備份設(shè)備。創(chuàng)建引用后，可以顯示該備份設(shè)備中的內(nèi)容的備份詳細信息。也可以使用 RESTORE HEADERONLY 命令。這兩種方法都會檢查備份設(shè)備，并提供一行輸出，用于描述文件中的每個備份。SSMS 使用友好名稱標識備份類型。若要使用正確的語法，需要按照 SQL Server 聯(lián)機叢書中有關(guān)該命令的條目（有關(guān) SQL Server 2008 版本，請參閱此處）所提供的信息，確定每個備份的備份類型，從而可以使用適當(dāng)?shù)?RESTORE 命令還原備份。

您還需要確定要還原的備份。這有一點棘手，因為所需要的 RESTORE HEADERONLY 的輸出列名稱與您必須用于還原的選項不匹配。文件中的備份從 1 開始編號（1 表示最舊），在名為"Position"的列中可以找到編號。若要還原備份，必須在 RESTORE 命令的 WITH FILE=<編號> 部分中使用相應(yīng)編號。下面是一個示例：

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;?

其他在此就不一一列舉了。您必須從某個數(shù)據(jù)庫備份開始還原序列，然后還原零個或多個差異數(shù)據(jù)庫和/或事務(wù)日志備份。更詳細的信息不在本專欄的討論范圍之內(nèi)，不過，在我為 2009 年 11 月刊撰寫的文章利用備份進行災(zāi)難恢復(fù)中，詳細介紹了有關(guān)可能需要的還原序列和其他 RESTORE 選項。

使用 SSMS 時，可在還原數(shù)據(jù)庫向?qū)е兄付▊浞菸募?，該向?qū)詣语@示文件中的所有備份，并允許您選擇需要的備份。圖 1 顯示了一個示例。

圖 1 使用 SSMS 還原數(shù)據(jù)庫向?qū)э@示文件中的多個備份。

無論選擇哪個選項，在進行災(zāi)難恢復(fù)時，在正式執(zhí)行還原之前，必須試還原到另一個位置，這一點至關(guān)重要。我始終遵循的原則之一是"沒有成功還原，就沒有備份。"

問題：我有一個很大的數(shù)據(jù)庫，每隔幾周就需要將它復(fù)制到開發(fā)環(huán)境中。我的問題是，最近數(shù)據(jù)庫因要容納更多數(shù)據(jù)增大了，現(xiàn)在將它還原到開發(fā)環(huán)境中時，它顯得太大了。如何在還原該數(shù)據(jù)庫時使它縮小一些？

解答：這是一個相當(dāng)普遍的問題，遺憾的是，沒有什么好的解決方法。

數(shù)據(jù)庫備份不會以任何方式更改數(shù)據(jù)庫，它僅僅讀取所有已使用的數(shù)據(jù)庫部分，將這些部分以及一些事務(wù)日志（有關(guān)原因和程度的說明，請參閱我的博客文章）包含在備份中。從數(shù)據(jù)庫備份進行的還原僅創(chuàng)建文件，寫出備份中的內(nèi)容，然后對數(shù)據(jù)庫運行恢復(fù)操作。基本上，數(shù)據(jù)庫中的內(nèi)容即是還原時獲得的內(nèi)容。沒有選項可以用于在還原時縮減數(shù)據(jù)庫、在還原時解決索引碎片問題、在還原時更新統(tǒng)計數(shù)據(jù)或是人們可能需要執(zhí)行的任何其他操作。

那么，如何實現(xiàn)您的目的呢？根據(jù)具體方案，您有三種方法。

首先，可以對生產(chǎn)數(shù)據(jù)庫執(zhí)行縮減操作，以回收空的空間。這樣可使還原的數(shù)據(jù)庫副本與生產(chǎn)數(shù)據(jù)庫相同，而不會浪費空間，但是成本可能會很高。生產(chǎn)數(shù)據(jù)庫會再次增長，因而縮減操作可能成本極高（在 CPU、I/O 和事務(wù)日志方面），并可能導(dǎo)致索引碎片。索引碎片問題必須得到

關(guān)鍵詞標簽：SQL備份

相關(guān)閱讀

文章評論

查看所有1條評論>>

分布式事務(wù)、性能計數(shù)器和SQL備份

分布式事務(wù)、性能計數(shù)器和SQL備份