使用自治式資料保全保護關鍵資料庫免於故障和災害

關於自治式資料保全

自治式資料保全會建立並維護兩個完全不同的資料庫複本：您的應用程式連線與使用的主要資料庫，以及一個同步主要資料庫複本的待命資料庫。然後，如果主要資料庫因任何原因而無法使用，Autonomous Data Guard 就可以將待命資料庫轉換為主要資料庫，因此將開始為您的應用程式提供服務。

主要和待命資料庫通常稱為彼此的對等資料庫。每個自治式容器資料庫最多可以有兩個待命資料庫。

附註：

應用程式必須設定為使用通透應用程式連續性 (TAC)，才能享有 Autonomous Data Guard 所提供資料庫可用性功能的完整優點。

下圖顯示每個待命資料庫如何與主要資料庫同步。

autonomous-data-guard.eps 圖解描述

對主要資料庫所做的變更會記錄在主要資料庫的重做日誌中。自治式資料保全會將這些重做記錄以串流形式透過網路傳輸至待命資料庫的重做日誌。接著，待命資料庫會將這些記錄套用至待命資料庫。如此一來，待命資料庫就會與主要資料庫保持同步。

同步化幾乎是即時的，但就如同所述的處理作業表示，有兩項耗費時間的作業：將重做記錄傳輸到待命資料庫，並將重做記錄套用到待命資料庫。其中第一條稱為傳輸延遲，另一條稱為套用延遲。您可以從資料庫的「詳細資訊」頁面，從資源底下的自治式資料保全，檢視 Autonomous Database 目前的延遲值。您可以從容器資料庫的「詳細資訊」頁面，以類似的方式檢視容器資料庫中所有 Autonomous Database 目前的延遲值。

附註：

若有多個待命資料庫，不支援「串聯重做傳輸」。

設定自治式資料保全

在 Autonomous Database on Dedicated Exadata Infrastructure 中，您可以在自治式容器資料庫 (ACD) 層級設定和管理 Autonomous Data Guard。您可以使用 Oracle Cloud Infrastructure 主控台，為已佈建的 ACD 啟用 Autonomous Data Guard，並從其詳細資訊頁面最多新增兩個待命 ACD。請參閱在自治式容器資料庫上啟用自治式資料保全和新增第二個待命自治式容器資料庫，以瞭解相關指示。

設定自治式資料保全之前，請注意下列事項：

部署在 Exadata Cloud@Customer 上的 Autonomous Database 必須開啟連接埠 1522 ，才能在自治式資料保全設定中允許主要資料庫與待命資料庫之間的 TCP 流量。
無法對排定在未來三天內執行作用中維護的 ACD 啟用自治式資料保全。您可以先執行作用中的維護，再啟用自治式資料保全，或變更維護執行排程，以便在第二個待命資料庫新增後才開始執行。
新增第二個待命資料庫需要對第一個待命資料庫進行自動非輪流重新啟動。主要資料庫不受此非輪流重新啟動的影響。

使用客戶管理的金鑰設定自治式資料保全

在 Autonomous Database on Dedicated Exadata Infrastructure 中，您可以使用客戶管理的金鑰，在自治式容器資料庫 (ACD) 層級設定及管理 Autonomous Data Guard。您可以使用 Oracle Cloud Infrastructure 主控台，對已佈建的 ACD 啟用 Autonomous Data Guard，並從它的「詳細資訊」頁面新增最多兩個待命 ACD。如需相關指示，請參閱在自治式容器資料庫啟用自治式資料保全和新增第二個待命自治式容器資料庫。

使用客戶管理的金鑰設定自治式資料保全之前，請注意下列事項：

如果您使用 Oracle Cloud Infrastructure Key Management System (OCI KMS) 並想要啟用跨區域自治式資料保全，您必須先將 OCI 保存庫複寫到想要新增待命資料庫的區域。請參閱 Replicating Vaults and Keys ，瞭解詳細資訊。

附註：
引進跨區域保存庫複寫功能之前建立的虛擬保存庫，無法跨區域複寫。如果您在另一個區域中擁有需要複寫的保存庫，且該保存庫不支援複寫，請建立新的保存庫和新金鑰。不過，所有專用保存庫都支援跨區域複寫。如需詳細資訊，請參閱 Virtual vault 跨區域複寫。
如果您使用 Oracle Key Vault (OKV)，並且想要啟用跨區域自治式資料保全，請確定已在金鑰存放區中新增 OKV 叢集的連線 IP 位址。

Autonomous Data Guard 模型

自治式容器資料庫 (ACD) 從 2025 年 3 月的詳細資訊頁面中啟用自治式資料保全，最多可建立 2 個待命 ACD。在此版本中，將不再使用先前的自治式資料保全關聯模型和關聯的 API，並以新的自治式資料保全群組模型和 API 取代。從 Oracle Cloud Infrastructure (OCI) 主控台於 2025 年 3 月之後佈建的所有新 ACD，都會自動使用新的自治式資料保全群組模型。

若要轉換現有的 ACD，客戶可以從 OCI 主控台上的 ACD 詳細資訊頁面按一下升級至自治式資料保全群組，或使用 MigrateAutonomousContainerDatabaseDataguardAssociation API 移轉至新模型。

升級時：

您將切換至對自治式容器資料庫資源執行自治式資料保全作業的新使用者體驗，而不是對自治式容器資料庫資料保全關聯資源執行。
您的自治式資料保全關聯資源已轉換為具有多個待命支援的自治式資料保全群組資源。對現有的自治式資料庫或資料保全設定沒有任何影響。
佈建自治式資料保全後，您必須從 ACD 的詳細資訊頁面啟用自治式資料保全，才能使用自治式資料保全功能。
您必須從要分別以主要 ACD 或容錯移轉切換角色的 standby ACD ，起始「切換」和「容錯移轉」作業。
您將切換至 API 管理自治式資料保全組態上列為取代 API 的新自治式資料保全群組 API。現有的自主資料保全關聯 API 已被棄用，自 2026 年 3 月起將無法使用。
您必須訂閱自治式資料保全事件類型中列出的新自治式資料保全群組事件。現有的自治式資料保全關聯事件只能與舊的自治式資料保全關聯 API 搭配使用，而且會隨著這些 API 而不再使用。

角色轉換與作業

建立自治式容器資料庫 (ACD) 之後，您可以使用切換或容錯移轉作業來變更對等資料庫的角色。如果啟用自動容錯移轉，自治式資料保全會在主要資料庫因任何原因而無法使用時，自動執行容錯移轉作業。

切換是主要資料庫與其待命資料庫之間的角色回復。切換可確保不會遺失資料。在切換期間，主要資料庫會轉換成待命角色，待命資料庫會轉換成主要角色。若要執行切換作業，請參閱切換自治式資料保全組態中的角色。

容錯移轉是主要資料庫無法使用時。容錯移轉會將待命資料庫轉換成主要角色。如果未啟用自動容錯移轉，您可以執行手動容錯移轉，如在自治式資料保全組態中容錯移轉至待命資料庫中所述。

容錯移轉作業之後的資料庫可用性和狀態，是由兩個復原目標所描述：

復原時間目標 (RTO) 。RTO 是資料庫在容錯移轉後可供應用程式使用的最長時間，以及在失敗時與套用延遲的一種程度相關。對於 Autonomous Data Guard，RTO 最長可達 2 分鐘。
復原點目標 (RPO) 。RPO 是失敗主要資料庫所造成潛在資料遺失的最長持續時間，在失敗時與傳輸延遲程度有關。對於 Autonomous Data Guard，RPO 幾乎為零。

在容錯移轉之後，失敗的主要資料庫會變成停用的待命資料庫，而且任何資料庫連線都無法使用。您可以重新啟用它，然後執行復原作業，將它變成狀況良好的待命資料庫。將失敗的主要項目復原為待命資料庫之後，您便可以執行切換，讓它回到其原始的主要角色。若要執行復原作業，請參閱在自治式資料保全組態中恢復停用的待命資料庫。

自動容錯移轉或快速啟動容錯移轉

使用自動容錯移轉時，當主要 ACD 因區域失敗、可用性網域失敗、Exadata 基礎架構失敗或自治式 Exadata VM 叢集 (AVMC) 失敗或 ACD 本身失敗時，會自動容錯移轉至待命 ACD。這也稱為「快速啟動容錯移轉」。

在 ACD 上設定自治式資料保全時，您無法啟用自動容錯移轉。從 ACD 詳細資訊頁面更新自治式資料保全設定值時，才能啟用或停用自動容錯移轉。

附註：

無法對在 Exadata Cloud@Customer 中部署且設定跨區域自治式資料保全的 Autonomous Database 啟用自動容錯移轉。

您無法為第一個待命 ACD 新增啟用自動容錯移轉的第二個待命 ACD。因此，在建立第二個待命 ACD 之前，請先使用更新自治式資料保全設定值停用自動容錯移轉，並視需要稍後重新啟用。

最大效能和最大可用性保護模式都支援自動容錯移轉：

在最大可用性模式中，自動容錯移轉可確保零資料遺失。
在最大效能模式中，自動容錯移轉可確保待命資料庫不會落後主要資料庫，超過為快速啟動容錯移轉延遲限制指定的值。依照預設，快速啟動容錯移轉延遲限制會設為 30 秒，而且僅適用於「最大效能」模式。在此情況下，只有當待命資料庫的套用延遲 (潛在資料遺失) 未超過設定的延遲限制時，才能進行自動容錯移轉。您可以將「快速啟動」容錯移轉延遲限制修改為 5 到 3600 之間的任何值。

請參閱更新自治式資料保全設定值以瞭解詳細資訊。

除了硬體故障、可用性網域中斷及區域中斷之外，還有其他幾種資料庫狀況可以觸發快速啟動容錯移轉，如下所示：

資料庫狀況條件	描述
控制檔損毀	因為磁碟故障，所以控制檔已永久損毀。
損毀的說明	重要資料庫的字典損毀。目前只有在資料庫開啟時才能偵測到此狀態。
資料檔寫入錯誤	所有資料檔 (包括暫存檔、系統資料檔以及還原檔) 都會發生寫入錯誤。

由於自動容錯移轉，失敗主要資料庫的角色會變成「停用待命」，在短時間內，待命資料庫會擔任主要資料庫的角色。自動容錯移轉結束後，會在停用的待命資料庫詳細資訊頁面顯示訊息，告知發生容錯移轉。

服務解決之前的主要自治式容器資料庫問題之後，您可以執行手動切換，將這兩個資料庫回復成最初的角色。佈建待命資料庫之後，您可以執行與待命資料庫相關的各種管理作業，包括：

手動將主要資料庫轉換成待命資料庫。
手動將主要資料庫容錯移轉至待命資料庫。
容錯移轉後將主要資料庫恢復成待命角色。
正在終止待命資料庫。

在具有多個待命資料庫和自動容錯移轉的自治式資料保全設定中：

手動容錯移轉需要您手動復原原始的主要資料庫，而原始的主要資料庫會變成新的待命資料庫。
每當發生自動容錯移轉時，Autonomous Database on Dedicated Exadata Infrastructure 會嘗試將舊的主要資料庫恢復為待命資料庫。不過，如果嘗試失敗，則必須手動復原。

快照待命資料庫

快照待命資料庫是透過將待命自治式容器資料庫 (ACD) 轉換為快照待命 ACD 所建立的完全可更新待命資料庫。請參閱將實體待命轉換為快照待命，以取得逐步指示。

快照待命資料庫會接收並存檔，但不會套用主要資料庫的重做資料。不過，它會增加您的「復原時間目標 (RTO)」，因為不會套用主要資料庫的即時變更。

快照待命功能支援各種使用案例，但以下是主要使用案例；

以讀寫模式將主要和待命應用程式執行處理連線至主要和待命資料庫，以執行初始組態。
請先修正快照待命資料庫，然後使用待命應用程式執行處理進行測試，以確認修正程式穩定性。這需要先將實體待命轉換成快照待命資料庫，才能在快照待命資料庫套用修正程式。

附註：

您無法將實體待命自治式容器資料庫轉換為啟用自動容錯移轉的快照待命資料庫。

在轉換為快照待命時，您可以啟用只在快照模式中作用中的新資料庫服務，或使用與主要資料庫搭配使用的相同服務集。不過，在快照待命資料庫上啟動主要資料庫服務可能會導致快照待命連線要求轉送到主要資料庫，反之亦然，如果您使用不正確的資料庫連線字串。因此，連線到您的主要資料庫和快照待命資料庫時，必須小心使用適當的連線字串。

附註：

當您使用快照待命建立新的服務時，會更新快照待命 ACD 中所有 Autonomous Database 的公事包。若要存取資料庫，請從待命 Autonomous Database 重新載入公事包，並使用快照待命連線字串。

您可以手動將快照待命 ACD 轉換回 Oracle Cloud Infrastructure (OCI) 的實體待命 ACD。如需詳細指示，請參閱將快照待命轉換成實體待命。如果快照待命未手動轉換成實體待命，則會在建立 7 天後自動將它轉換回實體待命。無論是哪一種情況，將快照待命資料庫轉換回實體待命資料庫，將會捨棄快照待命資料庫的所有本機更新，並套用從主要資料庫收到的重做資料。

當待命 ACD 處於快照待命模式時，您無法對主要 ACD 執行下列作業：

建立或終止自治式資料庫
擴大或縮小自治式資料庫
回復自治式資料庫

如果情況需要，您可以從主要資料庫手動容錯移轉至快照待命資料庫。在此情況下，容錯移轉會捨棄對您的快照備用所做的本機更新，並套用來自主要資料庫的資料，以將您的快照備用資料庫轉換成實體備用資料庫。如需逐步指示，請參閱 Fail Over to the Standby in an Autonomous Data Guard Configuration 。

不允許在主要資料庫與其快照待命資料庫之間切換。您必須先手動將快照待命轉換為實體待命，再嘗試切換。

從從屬端應用程式存取待命資料庫

在自治式資料保全組態中，您的從屬端應用程式通常會連線至主要資料庫並執行作業。

連接到實體待命資料庫

除了此一般連線之外，Autonomous Data Guard 還提供在待命資料庫上執行唯讀作業連線從屬端應用程式的選項。若要使用此選項，從屬端應用程式會使用包括 "_RO" (唯讀) 的資料庫服務名稱連線至資料庫，如自治式資料庫的預先定義資料庫服務名稱中所述。

連接到快照備用資料庫

Autonomous Data Guard 也可讓您將執行讀寫作業的用戶端應用程式連線至快照待命資料庫。這些作業是快照待命資料庫的本機作業，請勿修改其主要資料庫。若要連線至快照待命資料庫，從屬端應用程式可以使用包括 "_SS" (用於「快照待命」) 的資料庫服務名稱，如自治式資料庫的預先定義資料庫服務名稱中所述。

附註：

當待命資料庫處於快照待命模式時，名稱中包含 "_RO" 服務的所有資料庫服務皆為非作用中，無法用於連線。

監督延遲時間

當使用「自治式資料保全」的資料庫正在執行時，您可以在側邊功能表的「資源」下選擇自治式資料保全關聯，以監督傳輸延遲並從資料庫 (或容器資料庫的「詳細資訊」頁面套用延遲時間。您也可以使用 OCI 主控台或可觀察性 API 來監控傳輸延遲並設定警示和通知。如需詳細資訊，請參閱 Database Observability with Autonomous Database Metrics 。

您應該預期隨著時間的推移，會看到隨時間推移的小幅波動，這是資料庫 ebbs 和流量上的工作負載。不過，如果您注意到延遲時間的持續向上趨勢，您可以採取下列動作來解決此情況：

套用延遲的向上趨勢。套用延遲的持續向上趨勢表示待命資料庫的容量不足，無法跟上來自主要資料庫的重做記錄。若要解決此情況，請縱向擴展資料庫的 OCPU，如新增 CPU 或儲存體資源至專用 Autonomous Database 中所述。
傳輸延遲的向上趨勢。傳輸延遲的持續向上趨勢表示網路效能問題。Oracle Cloud 營運人員會持續監控網路效能，因此您應該在不採取任何動作的情況下看到狀況自行解決。不過，您可以提出服務要求 (如在 My Oracle Support 中建立服務要求中所述)，將情況帶給作業人員。

Autonomous Data Guard 組態選項

建立啟用自治式資料保全的自治式容器資料庫時，您可以指定要在其中建立待命資料庫的 Exadata 基礎架構和自治式 Exadata VM 叢集資源，以及指定要使用的資料保護模式。

指定待命資料庫要使用的 Exadata 基礎架構和自治式 Exadata VM 叢集資源時，有下列選擇：

與主要資料庫的 Exadata 基礎架構和自治式 Exadata VM 叢集位於不同區域：
這個選擇提供最高等級的災害保護，包括災害遺失外部網路連線或整個區域的電源。

為了充分利用此跨區域保護，您也必須設定應用程式層以支援跨區域保護。因此，如果您的應用程式層已使用此方式設定，或您願意重新設定以支援跨區域保護，Oracle 建議您選擇此選項。

如果您選擇在不同的區域中尋找待命資料庫，Oracle 建議您使用最大效能保護模式。
在與主要資料庫的 Exadata 基礎架構和自治式 Exadata VM 叢集不同的可用性網域 (AD) 中：
這個選擇提供高層級的災害保護，包括災害遺失外部網路連線或區域內可用性網域的電源。

此選擇在應用程式層的資料保護與簡單組態之間提供良好的平衡。

如果您選擇在不同的可用性網域中尋找待命資料庫，Oracle 建議您使用最大可用性保護模式。
在與主要資料庫的 Exadata 基礎架構和自治式 Exadata VM 叢集相同的可用性網域 (AD) ：
此選項提供對災害的最低保護層級，Oracle 建議您不要選擇此選項。

如果主要資料庫的 Exadata 基礎架構和自治式 Exadata VM 叢集資源位於只有一個可用性網域的區域，Oracle 建議您使用「在其他區域」選項。

如果您選擇在相同的可用性網域中尋找待命資料庫，Oracle 建議您使用最大可用性保護模式。
與主要資料庫的 Exadata 基礎架構和自治式 Exadata VM 叢集不同的租用戶：
適用於：僅限 Oracle Public Cloud

此選項可讓您從不同的租用戶新增待命資料庫，讓您的資料庫容錯移轉或切換至該跨租用戶待命資料庫。您也可以在遠端租用戶中建立快照待命。擁有跨租用戶待命資料庫有助於跨租用戶進行資料庫移轉。

跨租用戶待命資料庫：
- 可以使用 ECPU 或 OCPU 運算模型啟用。待命資料庫必須使用與主要資料庫相同的運算模型。
- 不支援自動容錯移轉。您只能改用手動容錯移轉。
- 無法使用 Oracle Cloud Infrastructure 主控台新增。您只能使用 CLI 或 REST API 新增跨租用戶待命資料庫。

關於保護模式

Autonomous Data Guard 提供下列資料保護模式：

最佳可用性。此保護模式提供可能的最高階資料保護，而不犧牲主要資料庫的使用狀態。

主要資料庫要等到收到待命資料庫上的資料確認後 ( 不會將資料寫入磁碟)，才會確認交易。如果主要資料庫在 30 秒內未收到此認可，其運作方式就如同處於最大效能模式，以保留主要資料庫可用性，直到再次及時收到認可為止。

此保護模式可確保零資料遺失，但若發生某些雙重錯誤，例如待命資料庫失敗後的主要資料庫失敗。
最大效能。這是預設保護模式。它提供可能的最高階的資料保護，而不影響主要資料庫的效能。

主要資料庫會在將這些交易產生的所有重做資料寫入其線上重做日誌時立即確認交易。它也會將重做資料傳送至待命資料庫，但會針對交易確認以非同步方式進行，因此主要資料庫效能不會受到將重做資料寫入待命資料庫的延遲影響。

此保護模式提供的資料保護比最大可用性模式稍微少，而且對主要資料庫效能的影響極小。

您可以從 Oracle Cloud Infrastructure (OCI) 主控台變更自治式資料保全設定中的保護模式。如需逐步指示，請參閱更新自治式資料保全設定值。

如需有關 Oracle Data Guard (在「自治式資料保全」功能下) 保護模式的詳細資訊，請參閱 Oracle Data Guard Concepts and Administration 中的 Oracle Data Guard Protection Modes 。

設定自治式資料保全的最佳做法

雖然 Autonomous Database 可讓您使用 Autonomous Data Guard 建立最多兩個待命 ACD，但您可以視需要選擇使用單一或多個待命 ACD。不過，若要使用 Autonomous Database 提供最具復原能力的災難復原選項，您可以新增一個本機待命資料庫 ACD 和一個遠端或跨區域待命資料庫 ACD，並將最大可用性新增為資料保護模式。

讓我們瞭解此設計的優點：

本機待命：
- 自動容錯移轉至相同區域中的本機待命資料庫，可提供顯著的本機災害隔離和應用程式容錯移轉簡單性。
- 本機待命資料庫的業務價值在零資料遺失容錯移轉中會出現，而應用程式停機時間會降低到幾秒鐘。
- 應用程式會自動且通透地容錯移轉至本機待命資料庫，在應用程式伺服器與資料庫之間維持相同的延遲。這對 OLTP 和套裝應用程式尤其重要，因為較高的延遲可能大幅影響傳輸量和整體的應用程式回應時間。
遠端待命：
- 如果區域災難導致無法存取主要和本機待命系統，則應用程式和資料庫可能會容錯移轉至遠端待命系統。
- 雖然當區域災害發生時，資料庫停機時間仍然非常低，但由於對次要區域進行 DNS、應用程式和資料庫容錯移轉作業所需的額外協調流程，應用程式停機時間可能會更高。
最佳可用性：
- 如果啟用自動容錯移轉或快速啟動容錯移轉 (FSFO)，則當主要 ACD 變成無法使用時，Autonomous Data Guard 會容錯移轉至本機待命資料庫，而不會遺失資料，也不會變更應用程式中的資料庫延遲。
- 如果啟用自動容錯移轉或快速啟動容錯移轉 (FSFO)，則當整個主要區域變成無法存取時，系統就會容錯移轉至遠端待命資料庫，但可能會遺失資料。

自治式資料保全如何影響標準管理作業

在某些情況下，您在自治式容器資料庫上執行的標準管理作業，與標準容器資料庫相比，在自治式資料保全組態中的主要和待命容器資料庫運作方式不同。下列清單說明這些差異。

變更維護排程
主要容器資料庫與其待命資料庫的維護排程已連結：待命資料庫的維護會在主要資料庫維護前幾天執行。預設值為 7 天；您可以在建立主要容器資料庫時選擇 1 到 7 天，或是在稍後編輯其「維護詳細資訊」來選擇。
變更維護類型
主要容器資料庫與其待命資料庫的維護類型必須相同。當您建立主要容器資料庫時，或者編輯主要容器資料庫的「維護詳細資訊」，選擇主要和待命資料庫的維護類型。
停用自動備份
使用自治式資料保全佈建自治式容器資料庫 (ACD) 時，無法停用自動備份。
管理排定的維護
您可以個別管理主要容器資料庫與其待命資料庫的排定維護。不過，由於兩者維護已連結，因此如果您選擇覆寫排定的維護時間，就必須在主要維護之前，對待命資料庫執行排定的維護。
移動至其他區間
您可以單獨和獨立地將主要和待命容器資料庫移動到不同的區間，就像它們是標準容器資料庫一樣。不過，與標準容器資料庫一樣，移動容器資料庫時應特別小心，以確保容器資料庫仍可供適當的雲端使用者群組存取。
重新啟動
您可以個別和獨立重新啟動主要和待命容器資料庫，就像它們是標準容器資料庫一樣。
輪換加密金鑰
您可以從主要 ACD 或主要資料庫輪換加密關鍵碼。
終止
您可以個別終止主要和待命容器資料庫。不過，終止主要容器資料庫及終止待命容器資料庫的後果不同：
- 終止主要容器資料庫會終止主要和待命容器資料庫。您無法終止包含自治式資料庫的主要容器資料庫。
- 終止待命容器資料庫會終止待命容器資料庫，並將其從自治式資料保全組態中移除。如果只剩下主要資料，就會移除自治式資料保全組態，將主要資料轉變成獨立容器資料庫。

逐步指南

如需管理自治式容器資料庫中自治式資料保全組態的逐步指引，請參閱：

您也可以使用 API 檢視及管理自治式資料保全組態。如需詳細資訊，請參閱 API to Manage Autonomous Data Guard Configuration 。