管理信箱資料庫複本

  • 發行項

在Exchange Server中，您可以使用 Exchange 管理主控台 (EAC) 或 Exchange 管理命令介面，在建立、設定和填入信箱伺服器成員的資料庫可用性群組 (DAG) 之後，新增信箱資料庫複本。

管理資料庫副本

建立多個資料庫複本之後，您可以使用 EAC 或 Exchange 管理命令介面來監視每個複本的健康情況和狀態，以及執行與資料庫複本相關聯的其他管理工作。 可能需要執行的一些管理工作包含暫停或繼續資料庫副本、植入資料庫副本、監視資料庫副本、設定資料庫副本設定和移除資料庫副本。

暫停及繼續資料庫副本

基於各種原因，例如執行計劃性維護，您可能需要暫停和繼續資料庫複本的連續複寫活動。 此外，某些系統管理工作，例如植入，會要求您先暫停資料庫複本。 建議您在資料庫或其記錄檔的路徑變更時暫停所有複寫活動。 您可以使用 EAC，或在 Exchange 管理命令介面中執行 Suspend-MailboxDatabaseCopy 和 Resume-MailboxDatabaseCopy Cmdlet，來暫停和繼續資料庫複製活動。 如需如何暫停或繼續資料庫副本之連續複寫活動的詳細步驟，請參閱 擱置或恢復信箱資料庫副本。

植入資料庫副本

植入也稱為 「更新」是將空白資料庫或生產資料庫複本新增至與使用中資料庫相同 DAG 中另一部信箱伺服器上目標複製位置的程式。 這會成為由該伺服器維護之副本的基準線資料庫。

視情況而定，您可以使用自動程式或您起始的手動程式來植入資料庫。 假設目標伺服器及其儲存設定正確，新增資料庫副本時，將自動植入副本。 如果您想要手動植入資料庫複本，而且不想在建立複本時自動植入，您可以在執行Add-MailboxDatabaseCopy Cmdlet 時使用SeedingPostponed參數。

初始植入之後，很少需要重新植入資料庫複本。 不過，如果需要重新植入，或是想要手動植入資料庫複本，而不是讓系統自動植入複本，您有兩個選項。 您可以使用 EAC 中的更新信箱資料庫複製精靈，或使用 Exchange 管理命令介面中的 Update-MailboxDatabaseCopy Cmdlet 來重新儲存資料庫。 植入資料庫副本之前，您必須先暫停信箱資料庫副本。 如需如何植入資料庫副本的詳細步驟，請參閱 更新信箱資料庫副本。

手動植入作業完成之後，會自動繼續已植入之信箱資料庫副本的複寫。 如果您不想讓複寫自動繼續，您可以在執行 Update-MailboxDatabaseCopy 指令程式時使用 ManualResume 參數。

選擇要植入的項目

當您執行植入作業時，可以選擇植入信箱資料庫複本、信箱資料庫複本的內容索引目錄，或資料庫複本和內容索引目錄複本。 更新信箱資料庫副本精靈和 Update-MailboxDatabaseCopy Cmdlet 的預設行為是同時植入信箱資料庫副本和內容索引類別目錄副本。 若只要植入信箱資料庫複本而不植入內容索引目錄，請在執行Update-MailboxDatabaseCopy Cmdlet 時使用DatabaseOnly參數。 若要只植入內容索引類別目錄副本，請在執行 Update-MailboxDatabaseCopy 指令程式時使用 CatalogOnly 參數。

選取植入來源

任何健全狀況良好的資料庫副本都可以作為該資料庫之其他副本的植入來源使用。 當您的 DAG 遍佈多個實體位置時，此功能特別有用。 例如，假設有一個四個成員的 DAG 部署，其中兩個成員 (MBX1 和 MBX2) 位於奧勒崗州的波特蘭，而另兩個成員 (MBX3 和 MBX4) 位於紐約州的紐約市。 名爲 DB1 的信箱資料庫在 MBX1 上使用中，而在 MBX2 和 MBX3 上有 DB1 的被動副本。 將 DB1 的副本新增至 MBX4 時，您可以選擇使用 MBX3 上的副本作為植入來源。 這麼做，您可以避免植入超出 Portland 和 New York 之間的廣域網路 (WAN) 連結。

若要在新增資料庫複本時使用特定複本作為植入來源，您可以執行下列動作：

  • 執行Add-MailboxDatabaseCopy Cmdlet 來新增資料庫複本時，請使用SeedingPostponed參數。 如果您未使用 SeedingPostponed 參數，則會使用資料庫的作用中複本做為來源明確植入資料庫複本。

  • 您可以在 EAC 中指定要作為 [更新信箱資料庫複製精靈] 一部分的來源伺服器，也可以在執行Update-MailboxDatabaseCopy Cmdlet 時使用SourceServer參數來指定要植入的來源伺服器。 在先前的範例中，您應該將 MBX3 指定為來源伺服器。 如果您未使用 SourceServer 參數，資料庫複本將會從資料庫的作用中複本中明確植入。

植入和網路

除了選取特定來源伺服器來植入信箱資料庫複本，您也可以使用 Exchange 管理命令介面來指定要使用的 DAG 網路。 您可以選擇在種子作業期間覆寫 DAG 網路的壓縮和加密設定。

您可以在執行Update-MailboxDatabaseCopy Cmdlet 時，使用Network參數來指定要用於植入的網路，並指定您要使用的 DAG 網路。 如果您未使用 Network 參數，系統會使用下列預設行為來選取要用於植入作業的網路：

  • 如果來源伺服器和目標伺服器位於相同的子網路上，已設定包含該子網路的複寫網路，則會使用該複寫網路。

  • 如果來源伺服器和目標伺服器位於不同的子網路上，即使已設定包含這些子網路的複寫網路，仍將使用用戶端 (MAPI) 網路進行植入。

  • 如果來源伺服器和目標伺服器位於不同的資料中心，則會使用用戶端 (MAPI) 網路進行植入。

DAG 網路的加密和壓縮是在 DAG 層級中設定。 預設設定只會針對不同子網上的通訊使用加密和壓縮。 如果來源和目標位於不同的子網路上，而 DAG 是使用 NetworkCompression 和 NetworkEncryption 的預設值進行設定，您可以在執行 Update-MailboxDatabaseCopy 指令程式時，分別使用 NetworkCompressionOverride 和 NetworkEncryptionOverride 參數來覆寫這些值。

植入程序

當您使用 Add-MailboxDatabaseCopy 或 Update-MailboxDatabaseCopy Cmdlet 開始植入程式時，會執行下列工作：

  1. 系統會讀取 Active Directory 中的資料庫屬性來驗證指定的資料庫和伺服器，並確認來源和目標伺服器正在執行Exchange Server，它們都是相同 DAG 的成員，而且指定的資料庫不是復原資料庫。 也會讀取資料庫檔案路徑。

  2. 準備從目標伺服器上的 Microsoft Exchange 複寫服務重新植入檢查。

  3. 目標伺服器上的 Microsoft Exchange 複寫服務會檢查步驟 1 中 Active Directory 檢查所讀取的檔案目錄中是否有資料庫和交易記錄檔。

  4. Microsoft Exchange 複寫服務會將狀態資訊從目標伺服器傳回到從其執行指令程式的系統管理介面。

  5. 如果所有初步檢查都已通過，則會在繼續之前提示您確認作業。 如果您確認該作業，程序就會繼續進行。 如果在初步檢查期間發生錯誤，則會回報錯誤，而作業也會失敗。

  6. 植入作業是從目標伺服器上的 Microsoft Exchange 複寫服務啟動。

  7. Microsoft Exchange 複寫服務會暫停使用中資料庫副本的資料庫複寫。

  8. Microsoft Exchange 複寫服務會更新資料庫的狀態資訊，以反映植入的狀態。

  9. 如果目標伺服器上還沒有用於目標資料庫和記錄檔的目錄，則會建立這些目錄。

  10. 植入資料庫的要求是使用 TCP 從目標伺服器上的 Microsoft Exchange 複寫服務傳遞至來源伺服器上的 Microsoft Exchange 複寫服務。 植入資料庫的這個要求和後續的通訊會在設定為複寫網路的 DAG 網路上進行。

  11. 來源伺服器上的 Microsoft Exchange 複寫服務會透過 Microsoft Exchange 資訊儲存庫服務介面起始可延伸儲存引擎 (ESE) 資料流備份。

  12. Microsoft Exchange 資訊儲存庫服務會將資料庫資料串流傳送至 Microsoft Exchange 複寫服務。

  13. 資料庫資料會從來源伺服器的 Microsoft Exchange 複寫服務移至目標伺服器的 Microsoft Exchange 複寫服務。

  14. 目標伺服器上的 Microsoft Exchange 複寫服務會將資料庫複本寫入位於主資料庫目錄中名為 temp-seeding 的臨時目錄。

  15. 當達到資料庫的結尾時，來源伺服器上的資料流備份作業便會結束。

  16. 目標伺服器上的寫入作業完成後，資料庫會從 temp-seeding 目錄移至最終位置。 該 temp-seeding 目錄隨即遭到刪除。

  17. 在目標伺服器上，Microsoft Exchange 複寫服務會代理 Microsoft Exchange 搜尋服務的要求，以裝載資料庫副本的內容索引類別目錄 (如果存在)。 如果在資料庫副本的先前執行個體中，有現有的過期類別目錄檔案，裝載作業便會失敗，這會觸發從來源伺服器複寫的需求。 同樣地，如果類別目錄不存在於目標伺服器上資料庫副本的新執行個體上，則需要類別目錄的副本。 在從來源複製新類別目錄時，Microsoft Exchange 複寫服務會引導 Microsoft Exchange 搜尋服務暫停資料庫副本的索引。

  18. 目標伺服器上的 Microsoft Exchange 複寫服務會將植入類別目錄要求傳送至來源伺服器上的 Microsoft Exchange 複寫服務。

  19. 在來源伺服器上，Microsoft Exchange 複寫服務會從 Microsoft Exchange 搜尋服務要求目錄資訊，並要求暫停索引。

  20. 來源伺服器上的 Microsoft Exchange 搜尋服務會將搜尋類別目錄目錄資訊傳回到 Microsoft Exchange 複寫服務。

  21. 來源伺服器上的 Microsoft Exchange 複寫服務會從目錄讀取類別目錄檔案。

  22. 來源伺服器上的 Microsoft Exchange 複寫服務會使用跨複寫網路的連線，將類別目錄資料移至目標伺服器上的 Microsoft Exchange 複寫服務。 讀取完成之後，Microsoft Exchange 複寫服務會傳送一個要求到 Microsoft Exchange 搜尋服務以繼續來源資料庫的索引。

  23. 如果目標伺服器的目錄中有任何現有的類別目錄檔案，目標伺服器上的 Microsoft Exchange 複寫服務會將其刪除。

  24. 目標伺服器上的 Microsoft Exchange 複寫服務會將目錄資料寫入名為 CiSeed.Temp 的臨時目錄，直到資料完全傳輸為止。

  25. Microsoft Exchange 複寫服務會將完整的類別目錄資料移至最終位置。

  26. 目標伺服器上的 Microsoft Exchange 複寫服務會繼續搜尋目標資料庫的索引。

  27. 目標伺服器上的 Microsoft Exchange 複寫服務會傳回完成狀態。

  28. 作業的最終結果會傳遞到從其呼叫指令程式的系統管理介面。

設定資料庫副本

建立資料庫副本之後，您可以在需要時檢視和修改其組態。 You can view some configuration information by examining the Properties page for a database copy in the EAC. 您也可以使用 Exchange 管理命令介面中的 Get-MailboxDatabase 和 Set-MailboxDatabaseCopy Cmdlet 來檢視和設定資料庫複製設定，例如重新執行延遲時間、截斷延遲時間和啟用喜好設定順序。 For detailed steps about how to view and configure database copy settings, see Configure mailbox database copy properties.

使用重新顯示延遲和截斷延遲選項

信箱資料庫副本支援使用重新顯示延遲時間和截斷延遲時間，兩者的設定都以分鐘為單位。 設定重新顯示延遲時間可讓您將資料庫副本還原至特定的時間點。 設定截斷延遲時間可讓您使用被動資料庫副本上的記錄檔，從使用中資料庫副本上的記錄檔遺失進行復原。 由於這兩個功能會導致暫時的記錄檔增多，因此使用任一功能都會影響您的儲存設計。

重新顯示延遲時間

重新執行延遲時間是信箱資料庫複製屬性，指定延遲資料庫複本記錄重新執行的時間量，以分鐘為單位。 當記錄檔已複寫到被動副本並已順利通過檢查後，重新顯示延遲計時器便會啟動。 透過延遲資料庫副本記錄檔的重新顯示，您就可以將資料庫復原至過去的特定時間點。 重新執行延隔時間設定成大於 0 的信箱資料庫副本稱為延遲的信箱資料庫副本，或簡稱為延遲副本。

在Exchange Server中使用資料庫複本和訴訟保留功能的策略，可以針對通常會導致資料遺失的一系列失敗提供保護。 不過，這些功能無法在發生邏輯損毀時針對資料遺失提供保護，雖然這種情況很罕見，但會導致資料遺失。 延遲副本的設計是用於發生邏輯損毀時，避免資料遺失。 通常有兩種類型的邏輯損毀：

  • 資料庫邏輯損毀：資料庫頁面總和檢查碼相符，但頁面上的資料在邏輯上錯誤。 這可能會在 ESE 嘗試寫入資料庫頁面時發生，即使作業系統傳回成功訊息時，資料仍永不寫入磁碟，或是寫入到錯誤的位置。 這稱為 遺失的排清。 為避免遺失清除遺失資料，ESE 在資料庫中包含遺失清除偵測機制以及頁面修補功能 (單一頁面還原)。

  • 儲存邏輯損毀：資料會以使用者未預期的方式新增、刪除或操作。 這些情況通常是由協力廠商應用程式所造成。 它通常只是因為使用者看起來像損毀而被視為損毀。 Exchange 存放區會將產生邏輯損毀的交易視為一系列有效的 MAPI 作業。 Exchange Server中訴訟保留功能可防止儲存邏輯損毀 (，因為它可防止使用者或應用程式) 永久刪除內容。 不過，也有可能是使用者信箱變成嚴重損毀的情況下，使其更容易將資料庫還原至損毀之前的特定時間點，然後匯出使用者信箱以擷取未損毀的資料。

資料庫副本、保留原則和 ESE 單一頁面還原的組合還原只會保留罕見但嚴重的儲存邏輯損毀情況。 您對於是否要搭配重新顯示延遲 (延遲副本) 使用資料庫副本的決定，將取決於您所使用的協力廠商應用程式，以及組織使用儲存邏輯損毀的歷程記錄。

如果您選擇使用延遲的副本，請注意其用法的下列隱含意義：

  • 重新顯示延遲時間是一個由系統管理員設定的值，且預設為停用。

  • 重新顯示延遲時間的預設設定為 0 天，最大設定為 14 天。

  • 延遲的副本不會被視為高可用性的副本。 它們的設計是用於嚴重損壞復原，以防止儲存邏輯損毀。

  • 重新顯示延遲時間設定越大，資料庫復原程序所需的時間就越長。 根據復原期間需要重新顯示之記錄檔的數目，以及硬體重新顯示的速度，復原資料庫可能需花費數小時或更久。

  • 建議您判斷延遲的副本對於您的整體嚴重損壞復原策略是否重要。 如果使用它們對策略來說很重要，建議您使用多個延遲的副本；如果您沒有多個延遲的副本，請使用獨立磁碟容錯陣列 (RAID) 來保護單一延遲的副本。 如果您遺失磁碟，或者如果發生損毀，就不會遺失延遲時間點。

  • 延遲的複本無法使用 ESE 單一分頁還原功能進行修補。 例如，如果延遲的複本發生資料庫頁面損毀 (-1018 錯誤) ，則必須重新儲存複本。 重新分層會遺失複本的延遲層面。

如果您想要資料庫重新執行所有記錄檔，並讓資料庫複製成為最新狀態，則啟動和復原延遲的信箱資料庫複本是一個簡單的程式。 如果您想要將記錄檔重新執行到特定的時間點，則會比較困難，因為您必須手動操作記錄檔，並執行 Exchange Server Database Utilities (Eseutil.exe) 。

如需如何啟用延遲信箱資料庫複本的詳細步驟，請參閱 啟用延遲的信箱資料庫複本。

截斷延遲時間

截斷延遲時間是信箱資料庫複本的 屬性，指定在將記錄檔重新執行到資料庫複本之後，延遲資料庫複本記錄刪除的時間量，以分鐘為單位。 當記錄檔已被複寫到被動副本、成功通過檢查，並且成功重新顯示至資料庫副本時，截斷延遲計時器便會啟動。 透過延遲資料庫副本記錄檔的截斷，您可以從影響資料庫使用中副本之記錄檔的失敗中復原。

資料庫副本和記錄檔截斷

記錄截斷在 Exchange 2016 和 Exchange 2019 中的運作方式與在 Exchange 2010 中相同。 截斷行為是由副本的重新顯示延遲時間和截斷延遲時間的設定來決定。

延遲設定保留為其預設值 0 (停用) 時，必須符合下列條件，才會截斷資料庫副本的記錄檔：

  • 必須已成功備份記錄檔，或者必須啟用循環記錄。

  • 記錄檔必須在資料庫的檢查點 (復原所需的最小記錄檔) 之下。

  • 其他所有延遲的副本必須已檢查記錄檔。

  • 除了延遲的複本以外，所有其他複本 () 必須重新執行記錄檔。

必須符合下列條件，延遲的資料庫副本才會發生截斷：

  • 記錄檔必須位於資料庫的檢查點之下。

  • 記錄檔必須比 ReplayLagTime + TruncationLagTime 更舊。

  • 必須已在使用中的副本上截斷記錄檔。

在Exchange Server中，當一或多個被動複本暫停時，主動信箱資料庫複本上不會發生記錄截斷。 如果規劃好的維護活動執行時間長 (例如數天)，則可能會累積相當長的記錄檔。 若要避免記錄磁碟機填滿了交易記錄，您可以將受影響的被動資料庫副本移除，而非暫停它。 完成規劃的維護後，您可以重新新增被動資料庫副本。

Exchange Server現在有稱為鬆散截斷的功能，預設為停用。 正常作業期間，在資料庫的所有副本皆確認已重新顯示 (被動副本) 或接收到 (遲延副本) 記錄檔之前，每個資料庫副本都會保留需要傳送至其他資料庫副本的記錄。 這是預設記錄截斷行為。 如果資料庫副本因某個原因而離線，則記錄檔會始累積於資料庫的其他副本所使用的磁碟上。 如果受影響的資料庫副本長時間離線，則可能會導致其他資料庫副本的磁碟空間不足。

啟用鬆散截斷和迴圈記錄時，截斷行為會不同。 每個資料庫副本都會追蹤本身的可用磁碟空間，並在可用空間偏低時套用鬆散截斷行為。

  • 就主動副本而言，最舊的落後副本 (在記錄重新顯示中最落後的被動資料庫副本) 會被忽略，而會從其餘最舊的被動副本開始截斷。 全域截斷會在主動資料庫副本中計算。

  • 對於被動複本，如果空間變低，則會使用稍後在登錄值資料表中所述的已設定參數，獨立截斷其記錄檔。被動複本會嘗試遵守在使用中複本上所做的截斷決策。 撇開 MinCopiesToProtect 這個名稱隱含的意義，Exchange 將只會忽略執行截斷時已知的最舊落後副本。

離線資料庫重新連線時，將會遺漏已從其他狀況良好副本中刪除的記錄檔，而其狀況良好副本狀態會是 FailedAndSuspended。 在此情況下，如果設定 Autoreseed，則會自動重新植入受影響的副本。 如果未設定 Autoreseed，則系統管理員需要手動植入資料庫副本。

如果已停用迴圈記錄，鬆散截斷會遵循備份，因此如果記錄尚未備份，則鬆散截斷將不會移除它們。

截斷是慣用架構的建議功能，其中不會使用備份並啟用迴圈記錄。

必要的狀況良好副本數目、可用磁碟空間閾值以及要保留的記錄數目都是可設定的參數。 根據預設，可用磁碟空間閾值為 204800 MB (200 GB)、為被動副本保留的記錄數目為 100,000 個 (100 GB)，主動副本則為 10,000 個 (10 GB)。

編輯每個 DAG 成員上的 Windows 登錄，即可執行啟用鬆散截斷以及設定鬆散截斷參數。 有三個可設定的登錄值都是儲存在 HKLM\Software\Microsoft\ExchangeServer\v15\BackupInformation 下方。 在預設情況下，具有下列 DWORD 值的 BackupInformation 機碼並不存在，而必須手動建立。 下表說明 BackupInformation 下的 DWORD 登錄值：

登錄值 描述 預設值
LooseTruncation_MinCopiesToProtect 此機碼可用來啟用鬆散截斷。 它代表在資料庫的主動副本上要受到保護而不進行鬆散截斷的被動副本數目。 將這個機碼的值設定為 0，即會停用鬆散截斷。 0
LooseTruncation_MinDiskFreeSpaceThresholdInMB 觸發鬆散截斷的可用磁碟空間 (MB) 閾值。 如果可用磁碟空間低於這個值，則會觸發鬆散截斷。 如果未設定此登錄值，則鬆散截斷會使用預設值 200 GB。
LooseTruncation_MinLogsToProtect 要截斷記錄的狀況良好副本上所要保留的記錄檔數目下限。 如果設定了此登錄值，則會同時對主動和被動副本套用此設定值。 如果未設定此登錄值，則會使用被動資料庫副本的預設值 100,000 和主動資料庫副本的預設值 10,000。

使用LooseTruncation_MinLogsToProtect登錄值時，請注意主動和被動資料庫複本的行為不同。 在使用中資料庫複本上，這是在受保護的被動複本和使用中複本的必要範圍所需的記錄檔之前，保留的額外記錄數目。在被動資料庫複本上，這是從最新可用記錄檔維護的記錄數目。 此數位的十分之一也會用來維護此被動複製所需範圍之前的記錄。 有兩個限制可確保延遲的資料庫複本不會佔用太多空間，因為它們的必要範圍通常非常大。

資料庫啟動原則

有時候您可能想要建立信箱資料庫副本，並在失敗發生時，防止系統自動啟動該副本，例如：

  • 如果您將一或多個信箱資料庫副本部署至另一個或待命的資料中心。

  • 如果您將延遲的資料庫副本設定為用於復原用途。

  • 如果您要執行維護或伺服器升級。

在先前的每個案例中，您有幾個不想要讓系統自動啟動的資料庫副本。 若要防止系統自動啟動信箱資料庫副本，您可以將副本設定為阻止 (暫停) 啟動。 這可讓系統透過記錄檔傳送和重新顯示，使副本維持在最新狀態，但防止系統自動啟動與使用該副本。 阻止啟動的副本必須由系統管理員手動啟動。 您可以使用 Set-MailboxServer Cmdlet 或個別資料庫複本，使用 Set-MailboxDatabaseCopy Cmdlet 將 DatabaseCopyAutoActivationPolicy 參數設定為 Blocked，以設定整個伺服器的資料庫啟用原則。

如需設定資料庫啟動原則的詳細資訊，請參閱設定信箱資料庫複本的啟動原則。

在連續複寫上移動信箱的影響

在高記錄檔產生率的忙碌信箱資料庫中，如果複寫至被動資料庫副本無法與記錄檔產生保持同步，則很有可能會造成資料遺失。 有一個情況可推動高記錄檔產生率，即為信箱移動。 Exchange Server包含 Exchange 信箱複寫服務等服務所使用的資料保證 API (MRS) ，根據系統或系統管理員所設定的DataMoveReplicationConstraint參數值來檢查資料庫複製架構的健康情況。 具體而言，「資料保證 API」可用於：

  • 檢查複寫健康情況：確認資料庫複本的必要條件數目可供使用。

  • 檢查複寫排清：確認已根據資料庫複本的必要數目重新執行必要的記錄檔。

執行時，API 會將以下狀態資訊傳回呼叫應用程式：

  • 重試：表示有暫時性錯誤導致無法針對資料庫檢查條件。

  • 已滿足：表示資料庫符合必要條件，或資料庫未複寫。

  • NotSatisfied：表示資料庫不符合必要條件。 In addition, information is provided to the calling application as to why the NotSatisfied response was returned.

信箱資料庫的 DataMoveReplicationConstraint 參數值會決定應在要求中評估多少個資料庫複本。 DataMoveReplicationConstraint參數具有下列可能值：

  • None：當您建立信箱資料庫時，預設會設定此值。 當此值已設定時，會忽略「資料保證 API」條件。 此值應該僅用於未複寫的信箱資料庫。

  • SecondCopy：當您新增信箱資料庫的第二個複本時，這是預設值。 當此值已設定時，至少有一個被動資料庫副本必須符合「資料保證 API」條件。

  • SecondDatacenter：設定此值時，另一個 Active Directory 月臺中至少有一個被動資料庫複製必須符合資料保證 API 條件。

  • AllDatacenters：設定此值時，每個 Active Directory 月臺中至少必須有一個被動資料庫複本符合資料保證 API 條件。

  • AllCopies：設定此值時，信箱資料庫的所有複本都必須符合資料保證 API 條件。

檢查複寫健康狀況

當執行「資料保證 API」以評估資料庫副本基礎架構的健康狀況時，會評估幾個項目。

在所有案例中，被動資料庫複製必須符合下列條件：

  • 健康狀況良好。

  • 在 10 分鐘的重新顯示延遲時間內重新顯示佇列。

  • 少於 10 筆記錄的複製佇列長度。

  • 平均複製佇列長度少於 10 筆記錄。 平均複製佇列長度根據應用程式已查詢資料庫狀態的次數而計算。

如果 DataMoveReplicationConstraint 參數設定為... 然後，針對指定的資料庫...
SecondCopy 至少一個複寫資料庫的被動資料庫複本必須符合先前所述的條件。
SecondDatacenter 另一個 Active Directory 月臺中至少有一個被動資料庫複本必須符合先前所述的條件。
AllDatacenters 必須掛接主動式複本，而且每個 Active Directory 月臺中的被動複本必須符合先前所述的條件。
AllCopies 必須掛接主動式複本，而且所有被動資料庫複本都必須符合先前所述的條件。

檢查複寫清除

「資料保證 API」也可用來驗證資料庫副本的必要條件數已重新顯示必要的交易記錄。 這是藉由比較最後記錄重新顯示時間戳記與呼叫服務的認可時間戳記 (大部分情況下，這是包含必要資料之最後記錄檔的時間戳記) 來進行驗證，再另外加上五秒鐘 (處理系統時間偏移或漂移)。 如果重新執行時間戳記大於認可時間戳記，則會滿足 DataMoveReplicationConstraint 參數。 如果重新執行時間戳記小於認可時間戳記，則不會滿足 DataMoveReplicationConstraint 。

將大量信箱移入或移出 DAG 內的複寫資料庫之前，建議您根據下列專案，在每個信箱資料庫上設定 DataMoveReplicationConstraint 參數：

如果您要部署... 將 DataMoveReplicationConstraint 設定為...
沒有任何資料庫副本的信箱資料庫 None
單一 Active Directory 站台內的 DAG SecondCopy
使用延伸 Active Directory 站台的多個資料中心中的 DAG SecondCopy
跨兩個Active Directory 月臺的 DAG，而且您在每個月臺中會有高可用性資料庫複本 SecondDatacenter
跨兩個 Active Directory 站台的 DAG，而且您在第二個站台中只有一個延遲資料庫副本 SecondCopy
這是因為記錄檔在重新顯示至資料庫副本之前，「資料保證 API」不保證待認可的資料，而且由於待延遲的資料庫副本的性質，此限制將造成無法移動要求，除非延遲資料庫副本 ReplayLagTime 值低於 30 分鐘。
跨三個或三個以上 Active Directory 站台的 DAG，每一個站台將包含高可用性的資料庫副本 AllDatacenters

平衡資料庫副本

由於 DAG 的固有性質 (因為資料庫轉換或容錯移轉)，使用中信箱資料庫副本會在整個 DAG 的存留時間內多次變更主機。 因此，DAG 在使用中信箱資料庫副本散發方面可能變得不平衡。 下表顯示 DAG 的範例，該 DAG 具有四個資料庫，每個資料庫各有四份副本 (每部伺服器上共有 16 個資料庫)，且使用中資料庫副本的散發不平均。

具有不平衡的使用中副本散發的 DAG

伺服器 主動資料庫數目 被動資料庫數目 裝載的資料庫數目 卸載的資料庫數目 喜好設定計數清單
EX1 5 11 5 0 4, 4, 3, 5
EX2 1 15 1 0 1, 8, 6, 1
EX3 12 4 12 0 13, 2, 1, 0
EX4 1 15 1 0 1, 1, 5, 9

在先前的範例中，每個資料庫有四份副本，因此，只有四個啟動喜好設定的可能值 (1、2、3 或 4)。 [喜好設定計數清單] 欄位顯示具有每一個這些值之資料庫數目的計數。 例如，在 EX3 上，有 13 份資料庫副本的啟動喜好設定為 1、兩份副本的啟動喜好設定為 2、一份副本的啟動喜好設定為 3，而沒有任何副本的啟動喜好設定為 4。

如您所見，在每個 DAG 成員所主控的使用中資料庫數目、每個 DAG 成員所主控的被動資料庫數目，或主控之資料庫的啟動喜好設定計數等方面，此 DAG 並不平衡。

您可以使用 RedistributeActiveDatabases.ps1 指令碼，以平衡跨 DAG 的使用中信箱資料庫副本。 此指令碼會在資料庫副本之間移動資料庫，嘗試讓 DAG 中的每一部伺服器上擁有相等的裝載資料庫數目。 如有需要，此指令碼還會嘗試跨站台平衡使用中資料庫。

指令碼提供兩個用來在 DAG 中平衡使用中資料庫副本的選項：

  • BalanceDbsByActivationPreference：指定此選項時，腳本會嘗試根據啟用喜好設定 (將資料庫移至其最慣用的複本) 而不考慮 Active Directory 網站。

  • BalanceDbsBySiteAndActivationPreference：指定此選項時，腳本會嘗試將使用中資料庫移至其最慣用的複本，同時嘗試平衡每個 Active Directory 月臺內的作用中資料庫。

使用第一個選項執行指令碼之後，先前不平衡的 DAG 會變成平衡，如下表所示。

具有平衡的使用中副本散發的 DAG

伺服器 主動資料庫數目 被動資料庫數目 裝載的資料庫數目 卸載的資料庫數目 喜好設定計數清單
EX1 4 12 4 0 4, 4, 4, 4
EX2 4 12 4 0 4, 4, 4, 4
EX3 4 12 4 0 4, 4, 4, 4
EX4 4 12 4 0 4, 4, 4, 4

如上表所示，在每部伺服器上的使用中和被動資料庫數目方面，以及跨伺服器的啟動喜好設定方面，此 DAG 目前已平衡。

下表列出 RedistributeActiveDatabases.ps1 指令檔的可用參數。

RedistributeActiveDatabases.ps1 指令碼參數

參數 描述
DagName 指定要重新平衡的 DAG 名稱。 若省略此參數，會使用本機伺服器為其成員的 DAG。
BalanceDbsByActivationPreference 指定腳本應該將資料庫移至其最慣用的複本，而不考慮 Active Directory 網站。
BalanceDbsBySiteAndActivationPreference 指定腳本應該嘗試將使用中資料庫移至其最慣用的複本，同時嘗試平衡每個 Active Directory 月臺內的作用中資料庫。
ShowFinalDatabaseDistribution 指定在轉散發完成之後，顯示目前資料庫散發的報告。
AllowedDeviationFromMeanPercentage 指定允許跨站台的使用中資料庫變化，並以百分比表示。 預設值為 20%。 例如，如果有 99 個資料庫在三個站台之間散發，則理想的散發應該是每個站台 33 個資料庫。 如果允許的偏差為 20%，則指令碼會嘗試平衡資料庫，以便每個站台不會高於或低於此數字超過 10%。 33 的 10% 為 3.3，且會進位至 4。 因此，指令碼會嘗試讓每個站台有 29 到 37 個資料庫。
ShowDatabaseCurrentActives 指定指令碼針對每個資料庫產生一份報告，其中詳細說明資料庫的移動方式，以及資料庫目前在其最慣用的副本上是否為使用中。
ShowDatabaseDistributionByServer 指定指令碼針對每部伺服器產生一份報告，其中顯示其資料庫散發。
RunOnlyOnPAM 指定指令碼只在目前擁有 PAM 角色的 DAG 成員上執行。 指令碼會確認它是從 PAM 執行。 如果它不是從 PAM 執行，則指令碼會結束。
LogEvents 指定指令碼應記錄包含動作摘要的事件 (MsExchangeRepl event 4115)。
IncludeNonReplicatedDatabases 指定指令碼在決定如何轉散發使用中資料庫時，應納入非複寫的資料庫 (未包含副本的資料庫)。 雖然非複寫的資料庫無法移動，但是可能會影響複寫資料庫的散發。
確認 Confirm 參數可用來隱藏執行命令檔時依預設出現的確認提示。 若要隱藏確認提示，請使用語法 -Confirm:$False。 您必須在語法中加入冒號 ( :)。

RedistributeActiveDatabases.ps1 範例

此範例顯示 DAG 目前的資料庫散發，包括喜好設定計數清單。

RedistributeActiveDatabases.ps1 -DagName DAG1 -ShowDatabaseDistributionByServer | Format-Table

此範例會使用啟動喜好設定來轉散發及平衡 DAG 中的使用中信箱資料庫副本。

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -Confirm:$False

此範例會使用啟動喜好設定來轉散發及平衡 DAG 中的使用中信箱資料庫副本，並產生散發的摘要。

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution

監視資料庫副本

您可以藉由檢查 EAC 中資料庫副本的詳細資料，檢視各種資訊，包含副本佇列長度、重新顯示佇列長度、狀態，以及索引狀態資訊。 您也可以使用 Exchange 管理命令介面中的 Get-MailboxDatabaseCopyStatus Cmdlet 來檢視資料庫複本的各種狀態資訊。

注意事項

如果發生會影響資料庫使用中副本的失敗，資料庫副本是第一道防線。 因此，請務必監視資料庫複本的健康情況和狀態，以確保它們可在需要時使用。

如需監視資料庫複本的詳細資訊，請 參閱監視資料庫可用性群組。

移除資料庫副本

您可以使用 EAC，或使用 Exchange 管理命令介面中的 Remove-MailboxDatabaseCopy Cmdlet，隨時移除資料庫複本。 在移除資料庫副本之後，必須手動刪除所移除資料庫副本所在伺服器上的任何資料庫和交易記錄檔。 如需如何移除資料庫副本的詳細步驟，請參閱 移除信箱資料庫副本。

資料庫轉換

主控資料庫作用中副本的信箱伺服器稱為信箱資料庫主機。 啟動被動資料庫副本的程序會變更資料庫的信箱資料庫主機，並將被動副本變成新的使用中副本。 這個程序稱為資料庫轉換。 在資料庫轉換中，資料庫的使用中副本會從信箱伺服器上卸載，而且該資料庫的被動副本會掛載為另一個信箱伺服器上新的使用中信箱資料庫。 執行轉換時，您可以選擇性地覆寫新信箱資料庫主機上的資料庫裝載撥號設定。

You can quickly identify which Mailbox server is the current mailbox database master by reviewing the right-hand column under the Database Copies tab in the EAC. 您可以使用 EAC 中的 Activate 連結，或使用 Exchange 管理命令介面中的 Move-ActiveMailboxDatabase Cmdlet 來執行切換。

在啟用被動複製之前，會執行數個內部檢查。 在某些情況下，資料庫切換會遭到封鎖或取消。 在其他情況下，您可以使用 Cmdlet 來移動或略過某些檢查。

  • 檢查資料庫副本的狀態。 如果資料庫副本的狀態為失敗，則會阻止轉換。 您可以使用Move-ActiveMailboxDatabase Cmdlet 的SkipHealthChecks參數來覆寫此行為並略過健康情況檢查。 此參數可讓您將使用中複本移至處於失敗狀態的資料庫複本。

  • 主動資料庫副本會查看其目前是否為任何資料庫被動副本的植入來源。 如果作用中副本目前作為植入來源，則會封鎖轉換。 您可以使用Move-ActiveMailboxDatabase Cmdlet 的SkipActiveCopyChecks參數來覆寫此行為並略過植入來源檢查。 此參數可讓您移動要作為植入來源的主動副本。 使用此參數將造成植入作業取消，並視為失敗。

  • 檢查資料庫副本的副本佇列和重新顯示佇列長度，以確定其值在設定條件內。 同時，驗證資料庫副本以確定它目前並未當做植入的來源使用。 如果佇列長度的值在設定的條件以外，或如果資料庫目前當做植入的來源使用，則會阻止轉換。 您可以使用Move-ActiveMailboxDatabase Cmdlet 的SkipLagChecks參數來覆寫此行為並略過這些檢查。 此參數會允許啟動在所設定條件之外重新顯示及複製佇列的副本。

  • 檢查資料庫副本的搜尋類別目錄 (內容索引) 的狀態。 如果搜尋類別目錄不是最新的、處於不正常的狀態或已損毀，則會阻止轉換。 您可以使用Move-ActiveMailboxDatabase Cmdlet 的SkipClientExperienceChecks參數來覆寫此行為並略過搜尋目錄檢查。 這個參數會造成此搜尋略過類別目錄健全狀況檢查。 如果您在啟動之資料庫副本的搜尋類別目錄處於不正常或無法使用的狀態，而您使用此參數略過類別目錄健全狀況檢查並啟動資料庫副本，您將需要再次對搜尋類別目錄進行編目，或是再次植入搜尋類別目錄。

當您執行資料庫切換時，您也可以選擇覆寫針對裝載所啟用被動資料庫複本之伺服器所設定的掛接撥號設定。 使用Move-ActiveMailboxDatabase Cmdlet 的MountDialOverride參數，會指示目標伺服器覆寫自己的掛接撥號設定，並使用MountDialOverride參數所指定的掛接撥號設定。

如需執行資料庫副本轉換的詳細步驟，請參閱啟動信箱資料庫副本。