管理信箱資料庫副本

發行項
06/13/2016

適用版本： Exchange Server 2010 SP2, Exchange Server 2010 SP3

上次修改主題的時間： 2015-03-09

資料庫行動性是 Microsoft Exchange Server 2010 中的新架構，該架構移除了儲存群組的概念，並從信箱伺服器分離出 Exchange 2010 信箱資料庫。因爲已從 Exchange 2010 移除儲存群組，所以連續複寫目前是在資料庫層級上運作。在 Exchange 2010 中，交易記錄檔會複寫至一個或多個信箱伺服器，並重新顯示至儲存在這些伺服器上之信箱資料庫的一個或多個副本中。在 Exchange 2010 中保留了 Exchange Server 2007 連續複寫中使用的幾個概念。這些包含分歧的概念、使用自動資料庫裝載撥號，以及使用公用和私人網路。

管理資料庫副本

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

暫停及繼續資料庫副本

基於各種原因 (例如執行已規劃的維護)，您可能需要暫停及繼續資料庫副本的連續複寫活動。此外，某些系統管理工作 (例如植入) 需要先暫停資料庫副本。我們也建議您在變更資料庫或其記錄檔的路徑時，先暫停所有複寫活動。您可以使用 EMC 或在命令介面中執行 Suspend-DatabaseCopy 和 Resume-DatabaseCopy 指令程式來暫停與繼續資料庫副本活動。如需暫停或繼續資料庫副本之連續複寫活動的詳細步驟，請參閱擱置或繼續信箱資料庫複製。

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

植入資料庫副本

植入(也稱為更新) 是將空白資料庫或實際執行資料庫的副本新增至相同資料庫可用性群組 (DAG) 中另一個信箱伺服器上的目標資料庫位置作為實際執行資料庫的程序。這會成為由該伺服器維護之副本的基準線資料庫。

根據不同的情況而定，植入可以是自動的處理程序，也可以是您所初始的手動處理程序。假設目標伺服器及其儲存設定正確，新增資料庫副本時，將自動植入副本。如果您要手動植入資料庫副本，而且不希望在建立副本時發生自動植入，則可以在執行 Add-MailboxDatabaseCopy 指令程式時使用 SeedingPostponed 參數。

初始植入進行之後，很少需要重新植入資料庫副本。但如果必須重新植入，或您想要手動植入資料庫副本而非讓系統自動植入副本，您可以使用 EMC 中的「更新資料庫副本」精靈或命令介面中的 Update-MailboxDatabaseCopy 指令程式來執行這些工作。植入資料庫副本之前，您必須先暫停信箱資料庫副本。如需植入資料庫副本的詳細步驟，請參閱更新信箱資料庫副本。

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

選擇要植入的項目

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

選取植入來源

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

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

執行 Add-MailboxDatabaseCopy 指令程式以新增資料庫副本時，請使用 SeedingPostponed 參數。如果不使用 SeedingPostponed 參數，則會使用資料庫的使用中副本作爲來源，明確地植入資料庫副本。
執行 Update-MailboxDatabaseCopy 指令程式時，請使用 SourceServer 參數，並指定想要的來源伺服器進行植入在先前的範例中，您應該將 MBX3 指定為來源伺服器。如果不使用 SourceServer 參數，則會使用資料庫的使用中副本作爲來源，明確地植入資料庫副本。

植入和網路

除了選取植入信箱資料庫副本的特定來源伺服器之外，您也可以指定要使用的 DAG 網路，並在植入作業期間選擇性地覆寫 DAG 網路的壓縮和加密設定。

若要指定要用於植入的網路，請在執行 Update-MailboxDatabaseCopy 指令程式時使用 Network 參數，並指定要使用的 DAG 網路。如果您不使用 Network 參數，系統會使用下列在植入作業時用於選取要使用之網路的預設行為：

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

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

植入程序

當您使用 Add-MailboxDatabaseCopy 或 Update-MailboxDatabaseCopy 指令程式起始植入程序時，會執行以下工作：

讀取來自 Active Directory 的資料庫內容以驗證指定的資料庫和伺服器，並驗證來源和目標伺服器執行的是 Exchange 2010、它們是相同 DAG 的成員，以及指定的資料庫不是復原資料庫。也會讀取資料庫檔案路徑。
準備從目標伺服器上的 Microsoft Exchange 複寫服務重新植入檢查。
目標伺服器上的 Microsoft Exchange 複寫服務會檢查步驟 1 中 Active Directory 檢查所讀取的檔案目錄中是否有資料庫和交易記錄檔。
Microsoft Exchange 複寫服務會將狀態資訊從目標伺服器傳回到從其執行指令程式的系統管理介面。
如果所有初步檢查都已通過，則會在繼續之前提示您確認作業。如果您確認該作業，程序就會繼續進行。如果在初步檢查期間發生錯誤，則會回報錯誤，而作業也會失敗。
植入作業是從目標伺服器上的 Microsoft Exchange 複寫服務啟動。
Microsoft Exchange 複寫服務會暫停使用中資料庫副本的資料庫複寫。
Microsoft Exchange 複寫服務會更新資料庫的狀態資訊，以反映植入的狀態。
如果目標伺服器上還沒有用於目標資料庫和記錄檔的目錄，則會建立這些目錄。
植入資料庫的要求是使用 TCP 從目標伺服器上的 Microsoft Exchange 複寫服務傳遞至來源伺服器上的 Microsoft Exchange 複寫服務。植入資料庫的這個要求和後續的通訊會在設定為複寫網路的 DAG 網路上進行。
來源伺服器上的 Microsoft Exchange 複寫服務會透過 Microsoft Exchange 資訊儲存庫服務介面起始可延伸儲存引擎 (ESE) 資料流備份。
Microsoft Exchange 資訊儲存庫服務會將資料庫資料串流傳送至 Microsoft Exchange 複寫服務。
資料庫資料會從來源伺服器的 Microsoft Exchange 複寫服務移至目標伺服器的 Microsoft Exchange 複寫服務。
目標伺服器上的 Microsoft Exchange 複寫服務會將資料庫副本寫入位於名爲 [temp-seeding] 的主要資料庫目錄中的暫存目錄。
當達到資料庫的結尾時，來源伺服器上的資料流備份作業便會結束。
目標伺服器上的寫入作業完成後，資料庫會從 temp-seeding 目錄移至最終位置。該 temp-seeding 目錄隨即遭到刪除。
在目標伺服器上，Microsoft Exchange 複寫服務會代理 Microsoft Exchange 搜尋服務的要求，以裝載資料庫副本的內容索引類別目錄 (如果存在)。如果在資料庫副本的先前執行個體中，有現有的過期類別目錄檔案，裝載作業便會失敗，這會觸發從來源伺服器複寫的需求。同樣地，如果類別目錄不存在，並且不存在於目標伺服器上資料庫副本的新執行個體上，則需要類別目錄的副本。在從來源複製新類別目錄時，Microsoft Exchange 複寫服務會引導 Microsoft Exchange 搜尋服務暫停資料庫副本的索引。
目標伺服器上的 Microsoft Exchange 複寫服務會將植入類別目錄要求傳送至來源伺服器上的 Microsoft Exchange 複寫服務。
在來源伺服器上，Microsoft Exchange 複寫服務會從 Microsoft Exchange 搜尋服務要求目錄資訊，並要求暫停索引。
來源伺服器上的 Microsoft Exchange 搜尋服務會將搜尋類別目錄目錄資訊傳回到 Microsoft Exchange 複寫服務。
來源伺服器上的 Microsoft Exchange 複寫服務會從目錄讀取類別目錄檔案。
來源伺服器上的 Microsoft Exchange 複寫服務會使用跨複寫網路的連線，將類別目錄資料移至目標伺服器上的 Microsoft Exchange 複寫服務。讀取完成之後，Microsoft Exchange 複寫服務會傳送一個要求到 Microsoft Exchange 搜尋服務以繼續來源資料庫的索引。
如果目標伺服器的目錄中有任何現有的類別目錄檔案，目標伺服器上的 Microsoft Exchange 複寫服務會將其刪除。
目標伺服器上的 Microsoft Exchange 複寫服務會將類別目錄資料寫入名爲 [CiSeed.Temp] 的暫存目錄，直到資料已完整傳輸為止。
Microsoft Exchange 複寫服務會將完整的類別目錄資料移至最終位置。
目標伺服器上的 Microsoft Exchange 複寫服務會繼續搜尋目標資料庫的索引。
目標伺服器上的 Microsoft Exchange 複寫服務會傳回完成狀態。
作業的最終結果會傳遞到從其呼叫指令程式的系統管理介面。

設定資料庫副本

建立資料庫副本之後，您可以在需要時檢視和修改其組態。您可以在 EMC 中檢查資料庫副本的 [內容] 頁面以檢視某些組態資訊。您也可以在命令介面中使用 Get-MailboxDatabase 和 Set-MailboxDatabaseCopy 指令程式以檢視和設定資料庫副本設定，例如重新顯示延遲時間、截斷延遲時間和啟動喜好設定順序。如需檢視和設定資料庫副本設定的詳細步驟，請參閱設定信箱資料庫副本內容。

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

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

重新顯示延遲時間

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

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

資料庫邏輯損毀 資料庫頁面總和檢查碼相符，但頁面上的資料邏輯錯誤。這可能會在 ESE 嘗試寫入資料庫頁面時發生，即使作業系統傳回成功訊息時，資料仍永不寫入磁碟，或是寫入到錯誤的位置。這稱為遺失清除。為避免遺失清除遺失資料，ESE 在資料庫中包含遺失清除偵測機制以及頁面修補功能 (單一頁面還原)。
儲存邏輯損毀 資料是以使用者非預期的方式新增、刪除或處理。這些情況通常是由協力廠商應用程式所造成。它通常只是因為使用者看起來像損毀而被視為損毀。Exchange 存放區會將產生邏輯損毀的交易視為一系列有效的 MAPI 作業。Exchange 2010 中的訴訟保留功能提供儲存邏輯損毀的保護 (因為它會防止使用者或應用程式永久刪除內容)。不過，如果使用者信箱的損毀情況很嚴重，將資料庫還原至損毀前的時間點，然後匯出使用者信箱以擷取未損毀的資料會比較容易。

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

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

與 Exchange 2007 中的待命連續複寫 (SCR) (具有 50 個記錄檔的硬式編碼重新顯示延遲) 不同，它沒有延遲記錄檔的硬式編碼數量。重新顯示延遲時間是一個由系統管理員設定的值，且預設為停用。
重新顯示延遲時間的預設設定為 0 天，最大設定為 14 天。
延遲的副本不會被視為高可用性的副本。它們的設計是用於嚴重損壞復原，以防止儲存邏輯損毀。
重新顯示延遲時間越大，資料庫復原程序所需的時間就越長。根據復原期間需要重新顯示之記錄檔的數目，以及硬體重新顯示的速度，復原資料庫可能需花費數小時或更久。
建議您判斷延遲的副本對於您的整體嚴重損壞復原策略是否重要。如果使用它們對策略來說很重要，建議您使用多個延遲的副本；如果您沒有多個延遲的副本，請使用獨立磁碟容錯陣列 (RAID) 來保護單一延遲的副本。如果您遺失磁碟，或者如果發生損毀，就不會遺失延遲時間點。
延遲的副本不能使用 ESE 單一頁面還原功能進行修補。如果延遲的副本發生資料庫頁面損毀 (例如，-1018 錯誤)，則必須將其重新植入 (將會失去副本的延遲層面)。

如果您希望資料庫重新顯示所有記錄檔，並使資料庫副本保持在最新狀態，啟動及復原延遲的信箱資料庫副本是很簡單的程序。如果您要重新顯示截至某一個特定時間點的記錄檔，這會是較困難的作業，因爲您必須手動操作記錄檔並執行 Eseutil 工具。

如需啟動延遲之信箱資料庫副本的詳細步驟，請參閱啟動延遲的信箱資料庫副本。

截斷延遲時間

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

資料庫副本和記錄檔截斷

記錄檔截斷在 Exchange 2010 和 Exchange 2007 中的作用相同。截斷行為是由副本的重新顯示延遲時間和截斷延遲時間的設定來決定。

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

必須已成功備份記錄檔，或者必須啟用循環記錄。
記錄檔必須在資料庫的檢查點 (復原所需的最小記錄檔) 之下。
其他所有延遲的副本必須已檢查記錄檔。
其他所有副本 (非延遲的副本) 必須已重新顯示該記錄檔。

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

記錄檔必須位於資料庫的檢查點之下。
記錄檔必須比 ReplayLagTime + TruncationLagTime 更舊。
必須已在使用中的副本上截斷記錄檔。

資料庫啟動原則

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

如果您將一個或多個信箱資料庫副本部署至另一個或待命的資料中心。
如果您將資料庫副本設定為用於復原用途的延遲副本。
如果您正在執行伺服器維護或升級。

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

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

平衡資料庫副本

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

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

伺服器	使用中資料庫數目	被動資料庫數目	裝載的資料庫數目	喜好設定計數清單
EX1	5	11	5	4, 4, 3, 5
EX2	1	15	1	1, 8, 6, 1
EX3	12	4	12	13, 2, 1, 0
EX4	1	15	1	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	4, 4, 4, 4
EX2	4	12	4	4, 4, 4, 4
EX3	4	12	4	4, 4, 4, 4
EX4	4	12	4	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	指定指令碼在決定如何轉散發使用中資料庫時，應納入非複寫的資料庫 (未包含副本的資料庫)。雖然非複寫的資料庫無法移動，但是可能會影響複寫資料庫的散發。

RedistributeActiveDatabases.ps1 範例

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

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

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

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference

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

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution

監視資料庫副本

如果發生會影響資料庫使用中副本的失敗，資料庫副本是第一道防線。因此，監視資料庫副本的健全狀況和狀態，以確保它們在需要時可供使用十分重要。您可以在 EMC 中檢查資料庫副本的 [內容] 頁面以檢視特定的健全狀況和狀態資訊。您也可以在命令介面中使用 Get-MailboxDatabaseCopyStatus 指令程式以檢視資料庫副本的各種狀態資訊。

如需監視資料庫副本的詳細資訊，請參閱監視高可用性及站台恢復。

移除資料庫副本

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

資料庫轉換

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

您可以在 EMC 中的 [資料庫副本] 索引標籤下檢閱 [副本狀態] 欄位，快速識別哪個信箱伺服器是目前的信箱資料庫主機。只有使用中的副本狀態才會是 [裝載]。其他所有資料庫副本將顯示資料庫副本複寫的目前狀態。您可以使用 EMC 中的「移動信箱資料庫主機」精靈，或命令介面中的 Move-ActiveMailboxDatabase 指令程式來執行切換。

在啟動被動副本之前，有幾個需要執行的內部檢查：

檢查資料庫副本的狀態。如果資料庫副本的狀態為失敗，則會阻止轉換。您可以使用 Move-ActiveMailboxDatabase 指令程式的 SkipHealthChecks 參數來覆寫此行為，並略過健全狀況檢查。此參數可讓您在失敗狀態下，將使用中的副本移至資料庫副本。
檢查資料庫副本的副本佇列和重新顯示佇列長度，以確定其值在設定條件內。同時，驗證資料庫副本以確定它目前並未當做植入的來源使用。如果佇列長度的值在設定的條件以外，或如果資料庫目前當做植入的來源使用，則會阻止轉換。您可以使用 Move-ActiveMailboxDatabase 指令程式的 SkipLagChecks 參數來覆寫此行為，並略過這些檢查。此參數會允許啟動在所設定條件之外重新顯示及複製佇列的副本。
檢查資料庫副本的搜尋類別目錄 (內容索引) 的狀態。如果搜尋類別目錄不是最新的、處於不正常的狀態或已損毀，則會阻止轉換。您可以使用 Move-ActiveMailboxDatabase 指令程式的 SkipClientExperienceChecks 參數來覆寫此行為，並略過搜尋類別目錄檢查。這個參數會造成此搜尋略過類別目錄健全狀況檢查。如果您在啟動之資料庫副本的搜尋類別目錄處於不正常或無法使用的狀態，而您使用此參數略過類別目錄健全狀況檢查並啟動資料庫副本，您將需要再次對搜尋類別目錄進行編目，或是再次植入搜尋類別目錄。

執行資料庫轉換時，您也可以選擇覆寫為主控要啟動之被動資料庫副本的伺服器設定的裝載撥號設定。使用 Move-ActiveMailboxDatabase 指令程式的 MountDialOverride 參數指示目標伺服器覆寫其自己的裝載撥號設定，並使用由 MountDialOverride 參數指定的內容。

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