Oracle 資料庫工作負載的災難復原選項
本指南說明在 Bare Metal 解決方案環境中執行重要 Oracle 資料庫工作負載的使用者可用的災難復原選項。
本指南假設您正在執行 Oracle Enterprise Edition。本指南所述的部分功能須另外取得授權， Enterprise Edition 授權不適用於這些功能。部分功能包括但不限於：
- Oracle Real Application Clusters
- Oracle Active Data Guard
- Oracle 進階壓縮
- Oracle GoldenGate
請參閱 Oracle 授權協議，瞭解您在規劃災難復原和高可用性時，有權使用哪些功能。
應用程式 RTO 和 RPO
您必須根據應用程式的復原時間目標 (RTO) 和復原點目標 (RPO)，決定 Oracle 資料庫技術的災難復原方式。一般來說，RTO 是指系統可接受的停機時間，而 RPO 是指可接受的資料遺失量。這些值越低，系統的成本和複雜度就會越高。如要進一步瞭解 RTO 和 RPO，請參閱「DR 規劃的基本概念」。
標示為「RPO = 0」或「零資料遺失」的架構，必須先在多個位置寫入資料，才能視為「已提交」至資料庫。隨著 RPO 接近零，延遲就會成為問題。
除非在設計階段妥善考量，否則導入零資料遺失架構可能會對整體應用程式效能造成不利影響。
高可用性與災難復原
在設計可靠的資料庫架構時，高可用性和災難復原是互補的概念。在本指南的脈絡中，高可用性是指系統能夠自動從系統上的個別或連鎖故障中復原的能力。另一方面，災難復原是整體業務持續性計畫的一部分，適用於可能導致整個系統群組無法使用的重大故障。由於災難復原服務必須在災難發生時復原大量整合元件，因此涵蓋的範圍較廣。
設計可靠的系統時，請務必將高可用性視為「第一道防線」。高可用性的資料庫架構必須能夠承受個別失敗情形，並持續執行，不會導致應用程式停機。系統的高可用性元件必須包含但不限於下列項目：
- 為伺服器、網路或儲存硬體提供備援電源
- 多個網路介面、交換器和電纜
- 備援儲存架構、控制器和磁碟裝置
- Google Cloud 和 Bare Metal 解決方案區域擴充功能之間具備錯誤容錯功能的合作夥伴互連網路
- 使用 Oracle RAC 避免因伺服器故障而停用資料庫
災難復原設計必須包含流程，以便從導致元件無法使用的多重連鎖故障中復原。災難復原計畫必須考量下列事項：
- 區域性中斷
- 天災
- 導致應用程式一或多個元件完全中斷的事件
Oracle 災難復原和高可用性工具
以下是一些 Oracle 災難復原和高可用性工具：
- Oracle Real Application Clusters
- Oracle Recovery Manager
- Oracle Data Guard
- Flashback 資料庫
- Oracle GoldenGate
Oracle Real Application Clusters
Oracle Real Application Cluster (RAC) 可用於水平擴充資料庫工作負載，以便由多個資料庫伺服器提供服務。使用 RAC 的資料庫可在區域擴充功能內的伺服器之間設定主動/主動。
RAC 通常用於為需要防範單一伺服器故障的系統提供高可用性。由於叢集的「共用一切」方法 (共用儲存空間和共用網路)，在 Bare Metal 解決方案環境中執行的 RAC 叢集必須位於單一 Bare Metal 解決方案 Pod 中。因此，RAC 可解決高可用性問題，但無法解決災難復原需求。
如要瞭解如何設定 RAC 以供 Bare Metal 解決方案使用，請參閱「在 Bare Metal 解決方案上安裝 Oracle RAC」。
Oracle Recovery Manager
Oracle Recovery Manager (RMAN) 是備份及復原 Oracle 資料庫的主要工具，因為它可以讀取 Oracle 專屬的資料檔案格式。可用於執行資料庫複本、時間點復原，甚至是還原 Oracle 資料庫中的單一資料表。
RMAN 是唯一可在資料庫開啟時用於備份的工具。也用於維護可用於復原的備份檔案目錄。
Oracle Data Guard
Oracle Data Guard 會將資料庫複製到遠端 RAC 叢集或其他資料庫安裝作業。Data Guard 支援物理或邏輯設定中的待命資料庫。
實體備援資料庫是區塊對區塊的副本，可讓資料庫的一個副本開放供寫入；其他副本則會掛載 (但不會開啟) 以套用變更，或開啟唯讀模式以支援報表應用程式。
如要瞭解如何在 Bare Metal 解決方案中設定 Data Guard，請參閱「在 Bare Metal 解決方案中部署 Oracle Data Guard」。
FLASHBACK DATABASE
Oracle 企業版的 FLASHBACK DATABASE 功能可讓管理員快速將資料庫倒轉至特定時間點，而不需要執行耗時的資料庫還原作業。
在災難復原作業中，FLASHBACK DATABASE 通常會在備援作業期間與 Data Guard 搭配使用，以便加快資料庫復原作業。失敗的資料庫會閃回至與新主要資料庫上的記錄相符的特定時間點，並重新執行，以便進行完整重新同步處理。
Oracle GoldenGate
Oracle GoldenGate 是一項邏輯複製工具，通常用於啟用主動/主動多站點部署，或在硬體平台之間移動資料。使用 GoldenGate 時，來源資料庫上的 extract 程序會擷取線上重做記錄中的變更，並將這些變更寫入記錄檔，再傳送至目標資料庫。目標資料庫上的 replicat 程序會將交易從尾端檔案轉換為 SQL，並在目標資料庫上執行 SQL。
這項架構讓 GoldenGate 成為一項強大的工具，可在資料庫平台之間移動資料，或在複製資料時進行轉換。與 Data Guard 不同，GoldenGate 需要在來源和目標系統上安裝及維護個別軟體。由於交易會在目標資料庫中轉譯並套用為 SQL，因此無法使用 GoldenGate 進行同步複製。雖然 GoldenGate 可提供最少的複製延遲時間，但單靠 GoldenGate 無法保證 RPO 為零。
災難復原部署模型 (僅限資料庫)
Oracle 已建立 Maximum Availability Architecture (MAA) 架構，提供建議的災難復原模型，方便您部署應用程式和資料庫。
下列每個模型都會提供特定的回購時間和回購點目標：
這些模型會對應至特定部署模式，以便在預期和非預期的停機事件中，達到 RPO 和 RTO 目標。每個資料庫工作負載都必須評估其可用性需求，並使用相應的模型進行設計。開發資料庫通常會使用保護層級低於實際工作環境和品質保證環境的模型。
青銅模型適用於不需要以分鐘為單位測量 RTO 的資料庫。銀級以上方案包含在遠端網站執行的待命資料庫。每個模型都會納入較低層級模型的功能。舉例來說，銅牌模型採用備份和復原概念，即使已部署待命資料庫，仍必須遵循這些概念。
銅模型
Copper 模型提供最少的部署作業，可將資料庫備份至本機儲存媒體，並複製至位於區域擴充功能之外的儲存空間。這項部署作業需要採用兩階段方法，但可以使用指令碼，透過 Google Cloud SDK 自動傳送備份。
由於需要進行兩階段復原，因此使用這種部署方式也會增加 RTO。RMAN 無法直接存取備份，因此必須先將備份移至 RMAN 可存取的位置，才能開始復原作業。
| 服務中斷 | 中斷類型 | RPO | RTO |
|---|---|---|---|
| 非預期 | 可復原的節點或執行個體失敗 | 0 | 重新啟動執行個體所需的時間 |
| 災難：資料毀損 | 從 RE 轉出的最後一個封存記錄、增量或完整備份 | 小時，取決於資料庫大小和指派給合作夥伴互連網路的頻寬 | |
| 災難：區域拓展失敗 | 從 RE 轉出的上次封存記錄、增量或完整備份 | 天數 / 週數，視區域擴充功能恢復上線所需的時間而定 | |
| 預定 | 資料庫修補程式、OS / FW 更新 | 0 | 更新及重新啟動執行個體所需的時間 |
| 重大資料庫升級 | 0 | 1 到 2 小時 |
銅級模型
銅級機型提供兩種部署選項。兩者都使用Google Cloud原生儲存空間來保留資料庫備份。
銅等部署 1：在區域儲存空間上備份
在這個部署中，備份會直接寫入外部媒體。在大多數情況下，建議的備份目的地是使用 Cloud Storage FUSE 的 Cloud Storage，這會將 Cloud Storage 值區呈現為檔案系統。
如需使用 Cloud Storage FUSE 的建議，請參閱 Oracle 備份、NFS 和 Cloud Storage。 Google Cloud 您也可以使用 Filestore，將 NFS 共用項目提供給裸機解決方案執行個體。
下圖為部署範例。
| 服務中斷 | 中斷類型 | RPO | RTO |
|---|---|---|---|
| 非預期 | 可復原的節點或執行個體失敗 | 0 | 重新啟動執行個體所需的時間 |
| 災難：資料毀損 | 上次封存記錄、增量或完整備份 | 時數 (視資料庫大小和指派給合作夥伴互連網路的頻寬而定) | |
| 災難：區域拓展失敗 | 上次封存記錄、增量或完整備份 | 天數 / 週數，視區域擴充功能恢復上線所需的時間而定 | |
| 預定 | 資料庫修補程式、OS/FW 更新 | 0 | 更新及重新啟動執行個體所需的時間 |
| 重大資料庫升級 | 0 | 1 到 2 小時 |
銅級部署 2：使用備份與災難復原功能進行備份
在這個部署作業中，備份和災難復原服務會用於在Google Cloud中儲存備份。備份和 DR 提供永久增量備份方法，可將備份內容儲存在 Cloud Storage 支援的高效能媒體中，以便長期保留。
備份和災難復原服務提供的 RTO 速度也比在 Filestore 或 Cloud Storage 中儲存備份更快，因為它可以立即為 Oracle 例項提供資料庫檔案的映像檔。掛載和遷移功能可快速將資料庫上線，同時將資料複製回實際工作儲存媒體，大幅降低 RTO。
下圖為部署範例。
| 服務中斷 | 中斷類型 | RPO | RTO |
|---|---|---|---|
| 非預期 | 可復原的節點或執行個體失敗 | 0 | 重新啟動執行個體所需的時間 使用 RAC 時為幾秒 |
| 災難：資料毀損 | 上次封存記錄、增量或完整備份 | 幾分鐘到幾小時不等，視效能需求、資料庫大小和指派給合作夥伴互連網路的頻寬而定 | |
| 災難：區域拓展失敗 | 上次封存記錄、增量或完整備份 | 天數 / 週數，視區域擴充功能恢復上線或客戶能否遷移至其他區域擴充功能所需的時間而定。 | |
| 預定 | 資料庫修補程式、OS / FW 更新 | 0 | 更新及重新啟動執行個體所需的時間 |
| 重大資料庫升級 | 0 | 1 到 2 小時 |
銀色
銀級模式會使用 Oracle Data Guard 導入資料庫複製功能。Data Guard 提供即時資料庫複製作業，其中有一或多個資料庫會做為待命資料庫。由於 Data Guard 會在資料庫變更發生時傳輸及套用變更，因此 RPO 可能會接近零。銀級模型仰賴非同步複製功能；使用同步複製功能可確保零資料遺失，但在區域間傳送資料所需的時間通常會使應用程式回應時間超出可接受的限制。
如果主要資料庫在使用者定義的一段時間內無法使用，Data Guard 的快速啟動容錯功能就能執行自動容錯作業。設定會受到 Data Guard 觀察器程序的監控，而該程序可以執行。
銀色模型的好處是，可確保資料庫在區域性故障時仍可使用，但備援和切換作業可能會影響應用程式效能，因為應用程式伺服器和資料庫之間的網路延遲時間會增加。我們不建議在不同區域執行應用程式和支援的資料庫。雖然資料庫的 RTO 可能不到 1 分鐘，但應用程式容錯的情況可能需要數分鐘到數小時，服務才能完全運作。在大多數情況下，執行跨區災難復原備援計畫時，通常會涉及手動程序，因為需要移動的元件數量。
在 Silver 模型中，您可能仍會在季度修補活動期間進行停機或維護作業。導入 Oracle RAC 可減少修補或伺服器故障的停機時間。
下圖為設定範例。
圖表中的範例設定顯示在 us-west2 和 us-east4 區域中執行的 RAC 資料庫。複製作業會使用非同步 Data Guard 進行設定。Bare Metal 解決方案和 Google Cloud之間的所有流量都會透過合作夥伴互連網路傳輸，而跨區域的流量則會透過 Google 網路主幹傳輸。應用程式伺服器會在各個區域中設定，但通常會在災難復原區域中關閉，直到宣告容錯事件為止。
| 服務中斷 | 中斷類型 | RPO | RTO |
|---|---|---|---|
| 非預期 | 可復原的節點或執行個體失敗 | 0 | 重新啟動執行個體所需的時間 使用 RAC 時為幾秒 |
| 災難：資料毀損 | 不到 60 秒 | 數分鐘到數小時，視應用程式備援機制而定。 | |
| 災難：區域拓展失敗 | 不到 60 秒 | 數分鐘到數小時，視應用程式備援機制而定。 | |
| 預定 | 資料庫修補程式、OS / FW 更新 | 0 | 更新及重新啟動執行個體所需的時間。 使用 RAC 時為幾秒 |
| 重大資料庫升級 | 0 | 1 到 2 小時
使用 |
金級
如果您擔心銀級模式會導致資料遺失，可以選擇金級模式，該模式會使用遠端同步執行個體，為在 Google CloudCompute Engine 中執行的執行個體提供同步複製功能。
遠端同步處理執行個體包含資料庫控制檔案和一組備援重做記錄，這些記錄會在主要資料庫附近的地理位置執行。這個例項會同步接收重做作業，並以低延遲時間記錄所有變更，讓主要資料庫的區域擴充功能記錄所有變更。遠端同步執行個體隨後會將重做作業轉送至遠端地區的待命資料庫，以便非同步套用。
遠端同步處理執行個體並非資料庫的完整副本，因此無法處理應用程式流量。遠端同步處理例項可用於提供容錯位置，讓資料庫變更可同步寫入，進而提供零資料遺失的解決方案。在對遠端同步處理執行個體執行同步複製作業時，系統會先在遠端同步處理執行個體上接收及修訂變更，然後才會在主要資料庫上修訂交易。
通常會選取 Compute Engine 執行個體，做為遠端同步處理執行個體的候選項目。將遠端同步處理執行個體放置在與主要資料庫相近的 Compute Engine 區域，可減少延遲時間 (通常低於 1.5 毫秒)，並防範區域擴充功能中的失敗情形。
下圖為部署範例。
圖表中的範例設定顯示在 us-west2 中執行的主要 RAC 資料庫，以及在 Compute Engine 中執行的應用程式。us-west2 中的 Compute Engine 執行個體正在執行遠端同步處理執行個體，接收同步重做作業。遠端同步處理執行個體已設定為將重做作業以非同步方式傳送至在 us-east4 區域執行的 RAC 資料庫。應用程式執行個體會在 Compute Engine 的 us-east4 區域中設定，以便在發生災難時處理應用程式流量。
| 服務中斷 | 中斷類型 | RPO | RTO |
|---|---|---|---|
| 非預期 | 可復原的節點或執行個體失敗 | 0 | 重新啟動執行個體所需的時間 使用 RAC 時為幾秒 |
| 災難：資料毀損 | 0 | 數分鐘到數小時不等，取決於應用程式的區域復原功能。 | |
| 災難：區域拓展失敗 | 0 | 從數分鐘到數小時不等，取決於應用程式區域復原功能。 | |
| 預定 | 資料庫修補程式、OS / FW 更新 | 0 | 更新及重新啟動執行個體所需的時間。 使用 RAC 時為幾秒 |
| 重大資料庫升級 | 0 | 1 到 2 小時
使用 |
白金模式
Platinum 型提供兩種部署選項。每個部署選項都會使用不同的技術提供保護，並具有不同的 RTO 和 RPO 特性。
白金部署 1：搭配快速啟動容錯功能的 Data Guard
白金部署 1 會在金色模型部署上，在本地區域中新增第二個在 Compute Engine 執行個體上執行的 Data Guard 待命資料庫。這項設定會在主要資料庫和在 Compute Engine 中執行的待命資料庫之間使用同步複製，確保主要區域內的資料損失率為零。
建立區域內待命資料庫後，資料庫容錯移轉和切換作業就能在不影響應用程式的情況下進行。在資料庫角色變更期間，根據 Oracle 用戶端注意事項設定的應用程式會自動重新連線至新的主資料庫，無須手動介入。在容錯事件期間，正確設定的應用程式停機時間會少於 2 分鐘。
雖然 Compute Engine 中的待命資料庫不會執行 RAC，但在做為主要資料庫執行時，必須調整大小以支援正常的應用程式流量。這個執行個體可以以較小的形狀執行，並在備用狀態下運作，在備援事件期間進行擴充，或是隨時以完整容量執行。在容錯事件期間調整執行個體大小會對 RTO 造成負面影響，因為執行個體必須在調整大小作業期間重新啟動。
在執行 Data Guard 仲介服務並搭配觀察器的 Compute Engine 執行個體上，設定快速啟動容錯功能。觀察器會執行基本 Oracle 用戶端，並連線至所有主要和備援資料庫。如果觀察器偵測到主要資料庫發生故障，就會啟動至其中一個待命資料庫的容錯移轉。使用金級部署時，必須將在 Compute Engine 上執行的待命資料庫設為偏好的容錯目標。
Oracle 建議將觀察器放在與主要和待命資料庫分開的區域。這可提供最佳防護，避免區域故障和網路區隔事件。如果無法使用第三個區域，觀察器必須安裝在主要區域中，並在與就近待命服務不同的區域中執行。
下圖為部署範例。
下圖所示的部署範例包含以下項目：
- 在
us-west2區域的 Bare Metal 解決方案伺服器上執行 RAC 的主要資料庫。 - 在
us-west2區域的 Compute Engine 執行個體上執行的近端待命資料庫。 - 在
us-east4區域的 Bare Metal 解決方案伺服器上執行的遠端待命資料庫。 - 在
us-central1地區的 Compute Engine 執行個體上執行的 Data Guard 觀察器。
針對在 Compute Engine 執行個體上執行的區域內待命資料庫，設定同步複製功能，並將非同步複製功能設定為遠端區域。在每個情況下，重做作業都會從主要資料庫傳送至待命資料庫；重做作業不會從一個待命資料庫轉送至另一個待命資料庫。觀察器會在第三個區域中設定，並維持與設定中所有資料庫的連線。應用程式執行個體會在主要區域中設定，並連線至 Bare Metal Solution 伺服器上的主資料庫 (或在備援和切換作業期間，連線至 Compute Engine 執行個體上的資料庫)。應用程式執行個體會在 Compute Engine 的 us-east4 區域中設定，以便在發生災難時處理應用程式流量。
| 服務中斷 | 中斷類型 | RPO | RTO |
|---|---|---|---|
| 非預期 | 可復原的節點或執行個體失敗 | 0 | 重新啟動執行個體所需的時間 使用 RAC 時為幾秒 |
| 災難：資料毀損 | 0 | 不到 60 秒 | |
| 災難：區域拓展失敗 | 0 | 不到 60 秒 | |
| 預定 | 資料庫修補程式、OS / FW 更新 | 0 | 更新及重新啟動執行個體所需的時間。 使用 RAC 時為幾秒 |
| 重大資料庫升級 | 0 | 1 到 2 小時
使用 |
白金部署 2：用於複製的 GoldenGate
白金部署 2 會使用 Oracle GoldenGate 進行複製。由於 GoldenGate 不會在區塊層級複製，讓每個資料庫服務都能獨立讀取及寫入應用程式工作階段。這項服務會以雙向方式複製變更，允許主動/主動資料庫設定。
應用程式必須先經過徹底的驗證，才能提交至 active/active 部署作業，而且您必須考量衝突偵測和解決方案。
與 Data Guard 不同，GoldenGate 需要在 Oracle 資料庫伺服器上安裝及維護額外軟體。為了充分發揮多網站資料庫部署作業的優勢，通常需要採用複雜的結構定義和應用程式設計，才能進行主動/主動部署。許多預先封裝的應用程式不支援這類架構。
由於邏輯複製的非同步性質，因此依賴 GoldenGate 進行所有複製作業的部署無法支援零資料遺失的 RPO。您可以部署使用 Data Guard 在 Compute Engine 中執行的本機待命資料庫，透過同步備份提供零 RPO。
下圖為部署範例。
| 服務中斷 | 中斷類型 | RPO | RTO |
|---|---|---|---|
| 非預期 | 可復原的節點或執行個體失敗 | 0 | 重新啟動執行個體所需的時間 |
| 災難：資料毀損 | 秒轉換為分鐘 如果在每個位置都使用 Data Guard，則為 0 |
0 | |
| 災難：區域拓展失敗 | 秒轉換為分鐘 如果在每個位置都使用 Data Guard，則為 0 |
0 | |
| 預定 | 資料庫修補程式、OS / FW 更新 | 0 | 更新及重新啟動執行個體所需的時間。 使用 RAC 時為幾秒 |
| 重大資料庫升級 | 0 | 0 |