Oracle 資料庫工作負載的災難復原選項
本指南說明在 Bare Metal 解決方案環境中執行重要業務 Oracle 資料庫工作負載時，使用者可用的災害復原選項。
本指南假設您執行的是 Oracle Enterprise Edition。本指南介紹的部分功能是透過 Enterprise 版授權以外的授權提供。部分功能包括但不限於：
- Oracle Real Application Clusters
- Oracle Active Data Guard
- Oracle Advanced Compression
- Oracle GoldenGate
請參閱 Oracle 授權合約，瞭解規劃災難復原和高可用性時，您有權使用的功能。
應用程式復原時間目標和復原點目標
Oracle 資料庫技術的災難復原機制，必須根據應用程式的復原時間目標 (RTO) 和復原點目標 (RPO) 決定。一般而言，RTO 是指系統可接受的停機時間，而 RPO 則是指可接受的資料遺失量。這些值越小，系統的成本和複雜度就越高。如要進一步瞭解 RTO 和 RPO，請參閱「災難復原規劃基本概念」。
標示為「RPO = 0」或「零資料遺失」的架構，必須先將資料寫入多個位置，才會視為「已提交」至資料庫。當 RPO 接近零時，延遲就會成為問題。
如果設計階段未妥善考量，實作零資料遺失架構可能會對整體應用程式效能造成負面影響。
高可用性與災難復原
設計可靠的資料庫架構時，高可用性和災難復原是互補的概念。在本指南中，高可用性是指系統在發生單一或連鎖故障時，自動復原的能力。另一方面，災難復原是整體業務持續性計畫的一部分，適用於可能導致整個系統群組無法使用的較大規模故障。災難復原的範圍較廣，因為發生災難時，必須復原許多整合元件。
設計可靠的系統時，高可用性必須視為「第一道防線」。高可用性資料庫架構必須能夠承受個別故障，並持續運作，不會導致應用程式停機。系統的高可用性元件必須包括但不限於下列項目：
- 伺服器、網路或儲存硬體中的備援電源
- 多個網路介面、交換器和纜線
- 備援儲存空間結構、控制器和磁碟裝置
- Google Cloud 與 Bare Metal Solution 區域擴充功能之間的容錯合作夥伴互連網路
- Oracle RAC，避免伺服器故障導致資料庫停用
災難復原設計必須包含從多個連鎖故障中復原的程序，這些故障會導致元件無法使用。災難復原計畫必須考量下列事項：
- 區域性服務中斷
- 天災
- 事件導致應用程式一或多個元件全面中斷
Oracle 災難復原和高可用性工具
以下是 Oracle 災難復原和高可用性工具：
Oracle Real Application Clusters
Oracle Real Application Clusters (RAC) 用於水平擴充資料庫工作負載，以便由多個資料庫伺服器提供服務。使用 RAC 的資料庫可在區域擴充功能內的伺服器之間，進行主動/主動設定。
RAC 通常用於為需要防範單一伺服器故障的系統提供高可用性。由於叢集採用「所有項目共用」方法 (共用儲存空間和共用網路)，因此在 Bare Metal 解決方案環境中執行的 RAC 叢集必須位於單一 Bare Metal 解決方案 Pod 中。因此 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 Enterprise Edition 的 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) 架構，為您提供部署應用程式和資料庫時建議使用的災難復原模型。
下列每個模型都提供特定的 RTO 和 RPO 目標：
這些模型會對應至特定部署模式，以符合預期和非預期中斷事件中的 RPO 和 RTO。您必須評估每個資料庫工作負載的可用性需求，並設計相應的模式。開發資料庫通常會使用保護等級較低的模型，與生產和 QA 對應項目不同。
Bronze 模型適用於不需要以分鐘為單位測量 RTO 的資料庫。Silver 以上的機型包含在遠端網站執行的待命資料庫。每個模型都包含較低層級模型的功能。舉例來說，即使部署了待命資料庫，仍須遵循 Bronze 模式的備份和復原概念。
Copper 模型
Copper 模型提供最少的部署項目，可將資料庫備份到本機儲存媒體，並複製到區域擴充功能外部的儲存空間。這項部署作業需要分兩階段進行，但可編寫指令碼，使用 Google Cloud SDK 自動傳輸備份資料。
由於需要兩階段復原，使用這項部署作業也會增加 RTO。RMAN 無法直接存取備份，因此必須先將備份移至 RMAN 可存取的位置，才能開始還原。
| 服務中斷 | 中斷類型 | RPO | RTO |
|---|---|---|---|
| 未規劃 | 可復原的節點或執行個體故障 | 0 | 重新啟動執行個體所需的時間 |
| 災害：損毀 | 從 RE 移出的最後一個封存記錄、增量或完整備份 | 數小時，視資料庫大小和指派給合作夥伴互連網路的頻寬而定 | |
| 災害：區域擴展失敗 | 從 RE 傳輸出的最後一個歸檔記錄、增量或完整備份 | 天數 / 週數，視區域擴充功能恢復上線所需時間而定 | |
| 預定 | 資料庫修補程式、作業系統 / 韌體更新 | 0 | 更新及重新啟動執行個體所需的時間 |
| 資料庫重大升級 | 0 | 1-2 小時 |
銅級模型
銅級模型提供兩種部署選項。兩者都使用 Google Cloud原生儲存空間保留資料庫備份。
銅級部署 1：備份至區域儲存空間
在此部署作業中，備份資料會直接寫入異地媒體。在大多數情況下，建議使用 Cloud Storage FUSE 將備份資料儲存到 Cloud Storage，因為這樣可將 Cloud Storage bucket 視為檔案系統。
如需使用 Cloud Storage FUSE 的建議，請參閱「Oracle Backups with NFS and Cloud Storage」(使用 NFS 和 Cloud Storage 備份 Oracle 資料庫) Google Cloud 。您也可以使用 Filestore，將 NFS 共用項目提供給 Bare Metal Solution 執行個體。
下圖顯示部署範例。
| 服務中斷 | 中斷類型 | RPO | RTO |
|---|---|---|---|
| 未規劃 | 可復原的節點或執行個體故障 | 0 | 重新啟動執行個體所需的時間 |
| 災害：損毀 | 上次的歸檔記錄、增量或完整備份 | 數小時，視資料庫大小和指派給合作夥伴互連網路的頻寬而定 | |
| 災害：區域擴展失敗 | 上次的歸檔記錄、增量或完整備份 | 天數 / 週數，視區域擴充功能恢復上線所需時間而定 | |
| 預定 | 資料庫修補程式、作業系統/韌體更新 | 0 | 更新及重新啟動執行個體所需的時間 |
| 資料庫重大升級 | 0 | 1-2 小時 |
銅級部署作業 2：使用備份和災難復原服務進行備份
在這個部署作業中，備份和災難復原服務會將備份資料儲存在Google Cloud。備份與 DR 採用永久增量備份方法，備份內容會儲存在高效能媒體上，並由 Cloud Storage 支援長期保留。
與將備份檔儲存在 Filestore 或 Cloud Storage 相比，Backup and DR 的 RTO 更快，因為這項服務可以立即將資料庫檔案映像檔提供給 Oracle 執行個體。掛接及遷移功能可快速將資料庫上線，同時複製回實際工作環境的儲存媒體，大幅縮短 RTO。
下圖顯示部署範例。
| 服務中斷 | 中斷類型 | RPO | RTO |
|---|---|---|---|
| 未規劃 | 可復原的節點或執行個體故障 | 0 | 重新啟動執行個體所需的時間
使用 RAC 時為秒 |
| 災害：損毀 | 上次的歸檔記錄、增量或完整備份 | 視效能需求、資料庫大小和指派給 Partner Interconnect 的頻寬而定，可能需要幾分鐘到幾小時 | |
| 災害：區域擴展失敗 | 上次的歸檔記錄、增量或完整備份 | 天 / 週，視區域擴充功能恢復上線所需時間，或客戶能否移至其他區域擴充功能而定。 | |
| 預定 | 資料庫修補程式、作業系統 / 韌體更新 | 0 | 更新及重新啟動執行個體所需的時間 |
| 資料庫重大升級 | 0 | 1-2 小時 |
銀色
銀級模型會使用 Oracle Data Guard 導入資料庫複製功能。 Data Guard 提供即時資料庫複製功能，可將一或多個資料庫做為待命資料庫。由於 Data Guard 會在資料庫發生異動時傳輸並套用異動，因此 RPO 接近於零。Silver 模型採用非同步複製；使用同步複製可確保資料零遺失，但區域間傳送資料所需的時間通常會導致應用程式回應時間超出可接受的範圍。
如果主要資料庫在使用者定義的時間內無法使用，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 秒 | 視應用程式容錯移轉而定，可能需要數分鐘到數小時。 | |
| 預定 | 資料庫修補程式、作業系統 / 韌體更新 | 0 | 更新及重新啟動執行個體所需的時間。
使用 RAC 時為秒 |
| 資料庫重大升級 | 0 | 1-2 小時
如果使用 |
黃金模型
如果您擔心 Silver 模型會造成資料遺失，可以選擇 Gold 模型，該模型會使用遠端同步執行個體，為在 Compute Engine 中執行的執行個體提供同步複製功能。 Google Cloud
遠端同步執行個體包含資料庫控制檔案和一組待命重做記錄，這些記錄會在主要資料庫附近執行。這個執行個體已設定為以低延遲時間同步接收重做，因此所有變更都會記錄在主要資料庫區域擴充功能之外。遠端同步執行個體接著會將重做作業轉送至遠端區域的待命資料庫，以非同步方式套用。
遠端同步執行個體並非資料庫的完整副本，因此無法處理應用程式流量。遠端同步執行個體可用於提供容錯位置，以同步寫入資料庫變更，進而實現零資料遺失解決方案。對遠端同步執行個體執行同步複製時，系統會等到遠端同步執行個體收到變更並完成修訂後，才會在主要資料庫上修訂交易。
通常會選取 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 | 數分鐘到數小時，視應用程式區域容錯移轉而定。 | |
| 預定 | 資料庫修補程式、作業系統 / 韌體更新 | 0 | 更新及重新啟動執行個體所需的時間。
使用 RAC 時為秒 |
| 資料庫重大升級 | 0 | 1-2 小時
如果使用 |
白金型號
白金版提供兩種部署選項。每種部署選項都使用不同的技術提供保護，並具有不同的 RTO 和 RPO 特性。
白金級部署 1：搭配快速啟動容錯移轉功能的 Data Guard
白金級部署 1 以黃金級模型部署為基礎，在本地區域新增第二個 Data Guard 待命資料庫，並在 Compute Engine 執行個體上執行。這項設定會在主要資料庫和 Compute Engine 中執行的待命資料庫之間使用同步複製，確保主要區域內不會遺失任何資料。
建立區域內待命資料庫後，資料庫容錯移轉和切換作業就不會影響應用程式。資料庫角色變更期間，根據 Oracle 用戶端注意事項設定的應用程式會自動重新連線至新的主要資料庫，不需手動介入。如果應用程式設定正確，容錯移轉事件期間的停機時間不會超過 2 分鐘。
雖然 Compute Engine 中的待命資料庫不會執行 RAC，但必須調整大小，以便在做為主要資料庫執行時，支援正常的應用程式流量。這個執行個體可以以較小的形狀執行，同時做為待命執行個體，並在容錯移轉事件期間擴大，也可以隨時以完整容量執行。在容錯移轉事件期間調整執行個體大小會對 RTO 造成負面影響，因為執行個體必須在調整大小作業期間重新啟動。
快速啟動容錯移轉功能是在執行 Data Guard 代理程式的 Compute Engine 執行個體上設定，並搭配觀察程式。觀察器會執行基本的 Oracle 用戶端，並連線至所有主要和待命資料庫。如果觀察器偵測到主要資料庫發生故障，就會啟動容錯移轉至其中一個待命資料庫。使用 Gold 層級部署時，必須將在 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 秒 | |
| 預定 | 資料庫修補程式、作業系統 / 韌體更新 | 0 | 更新及重新啟動執行個體所需的時間。
使用 RAC 時為秒 |
| 資料庫重大升級 | 0 | 1-2 小時
如果使用 |
白金級部署 2：GoldenGate 用於複製
白金級部署 2 依賴 Oracle GoldenGate 進行複製。由於 GoldenGate 不會在區塊層級複製，讓每個資料庫都能獨立讀取及寫入應用程式工作階段。雙向複製變更，因此可設定主動/主動資料庫。
應用程式必須經過全面驗證，才能部署為作用中/作用中，且您必須考量衝突偵測和解決。
與 Data Guard 不同，GoldenGate 需要在 Oracle 資料庫伺服器上安裝及維護額外軟體。如要充分運用多網站資料庫部署作業，通常需要複雜的結構定義和應用程式設計。許多預先封裝的應用程式不支援這類架構。
由於邏輯複製作業屬於非同步性質，因此凡是依賴 GoldenGate 進行所有複製作業的部署，都無法支援零資料遺失的 RPO。使用 Data Guard 在 Compute Engine 中執行的本機待命資料庫，可透過同步複製提供零 RPO。
下圖顯示部署範例。
| 服務中斷 | 中斷類型 | RPO | RTO |
|---|---|---|---|
| 未規劃 | 可復原的節點或執行個體故障 | 0 | 重新啟動執行個體所需的時間 |
| 災害：損毀 | 秒轉換為分鐘
0 (如果在每個位置使用 Data Guard) |
0 | |
| 災害：區域擴展失敗 | 秒轉換為分鐘
0 (如果在每個位置使用 Data Guard) |
0 | |
| 預定 | 資料庫修補程式、作業系統 / 韌體更新 | 0 | 更新及重新啟動執行個體所需的時間。
使用 RAC 時為秒 |
| 資料庫重大升級 | 0 | 0 |