Azure 上 Oracle 資料庫的架構 虛擬機器
適用於：✔️ Linux VM
本文包含在 Azure 上部署高可用性 Oracle 資料庫的相關信息。 此外，本指南會深入探討災害復原考慮。 這些架構已根據客戶部署建立。 本指南僅適用於 Oracle Database Enterprise Edition。
如果您想要深入瞭解如何最大化 Oracle 資料庫的效能，請參閱 在 Azure 中設計和實作 Oracle 資料庫。
必要條件
- 瞭解 Azure 的不同概念，例如 可用性區域
- Oracle Database Enterprise Edition 12c 或更新版本
- 使用本文中的解決方案時，瞭解授權含意
Oracle 資料庫的高可用性
在雲端中實現高可用性是每個組織的規劃和設計的重要組成部分。 Azure 提供 可用性區域 和 可用性設定組 ，以用於可用性區域無法使用的區域。 如需如何為雲端設計的詳細資訊，請參閱 Azure 虛擬機器 的可用性選項。
除了雲端原生工具和供應專案之外，Oracle 還提供可在 Azure 上設定的高可用性解決方案：
本指南涵蓋每個解決方案的參考架構。
當您移轉或建立雲端的應用程式時，建議您使用雲端原生模式，例如 重試模式 和 斷路器模式。 如需可協助讓應用程式更具復原性的其他模式，請參閱 雲端設計模式指南。
雲端中的 Oracle RAC
Oracle Real Application Cluster （RAC） 是 Oracle 的解決方案，可藉由讓許多實例存取一個資料庫記憶體，協助客戶達到高輸送量。 此模式是共享的架構。 雖然 Oracle RAC 可用於內部部署的高可用性，但單獨使用 Oracle RAC 就不能用於雲端中的高可用性。 Oracle RAC 只會保護實例層級失敗，而不是針對機架層級或數據中心層級失敗。 基於這個理由，Oracle 建議搭配資料庫使用 Oracle Data Guard，無論是單一實例還是 RAC，以達到高可用性。
客戶通常需要高 SLA 才能執行任務關鍵性應用程式。 Oracle 目前不支援 Azure 上的 Oracle RAC。 不過，Azure 提供可用性區域和計劃性維護時段等功能，以協助防範實例層級失敗。 除了這些供應專案之外，您還可以使用 Oracle Data Guard、Oracle GoldenGate 和 Oracle 分區化，以達到高效能和復原能力。 這些技術可協助保護您的資料庫免於機架層級、數據中心層級和異地政治失敗。
當您使用 Oracle Data Guard 或 GoldenGate 在多個 可用性區域 上執行 Oracle 資料庫時，您可以取得 99.99% 的運行時間 SLA。 在尚未存在可用性區域的 Azure 區域中，您可以使用 可用性設定組 ，並達到 99.95% 的運行時間 SLA。
注意
您可以擁有比 Microsoft 所提供的執行時間 SLA 高得多的運行時間目標。
Oracle 資料庫的災害復原
在雲端中裝載任務關鍵性應用程式時，請務必設計高可用性和災害復原。
針對 Oracle Database Enterprise Edition，Oracle Data Guard 是災害復原的實用功能。 您可以在配對的 Azure 區域中設定待命資料庫實例，並設定 Data Guard 故障轉移以進行災害復原。 針對零數據遺失，除了Active Data Guard之外，建議您部署Oracle Data Guard Far Sync 實例。
如果您的應用程式允許延遲，請考慮在與 Oracle 主資料庫不同的可用性區域中設定 Data Guard Far Sync 實例。 徹底測試設定。 使用最大可用性模式，將重做檔案同步傳輸至 Far Sync 實例。 然後，這些檔案會以異步方式傳送至待命資料庫。
在最大可用性模式的另一個可用性區域中設定 Far Sync 實例時，您的應用程式可能不會允許效能遺失。 如果沒有，您可能會在與主資料庫相同的可用性區域中設定 Far Sync 實例。 針對新增的可用性，請考慮在角色轉換時，設定靠近主資料庫的多個 Far Sync 實例，以及至少一個接近待命資料庫的實例。 如需詳細資訊，請參閱 Oracle Active Data Guard Far Sync。
當您使用 Oracle Standard Edition 資料庫時，有 ISV 解決方案可讓您設定高可用性和災害復原，例如 DBVisit 待命。
參考架構
Oracle 資料保護
Oracle Data Guard 可確保企業數據的高可用性、數據保護和災害復原。 Data Guard 會將待命資料庫維護為主資料庫的交易一致複本。 根據主要資料庫與輔助資料庫與應用程式延遲容錯之間的距離，您可以設定同步或異步複寫。 如果主資料庫因計劃性或非計劃性中斷而無法使用，Data Guard 可以將任何待命資料庫切換至主要角色，將停機時間降至最低。
使用 Oracle Data Guard 時，您也可以針對唯讀用途開啟輔助資料庫。 此設定稱為 Active Data Guard。 Oracle Database 12c 引進了稱為 Data Guard Far Sync 實例的功能。 這個實例可讓您設定 Oracle 資料庫的零數據遺失設定，而不需要危害效能。
注意
Active Data Guard 需要額外的授權。 此授權也需要使用 Far Sync 功能。 請與您的 Oracle 代表連絡，討論授權含意。
具有快速啟動故障轉移的 Oracle Data Guard
使用快速啟動故障轉移的 Oracle Data Guard （FSFO） 可以在個別的電腦上設定訊息代理程式，以提供更多的復原能力。 Data Guard 訊息代理程式和輔助資料庫都會執行觀察者，並觀察主資料庫停機。 此方法也可讓您在 Data Guard 觀察者設定中備援。
使用 Oracle Database 12.2 版和更新版本時，也可以使用單一 Oracle Data Guard 訊息代理程式設定來設定多個觀察者。 此設定提供額外的可用性，以防有一個觀察者和輔助資料庫遇到停機時間。 Data Guard Broker 是輕量型的，而且可以裝載在相對較小的虛擬機上。 如需 Data Guard Broker 及其優點的詳細資訊，請參閱 Oracle Data Guard Broker 概念。
下圖是搭配可用性區域在 Azure 上使用 Oracle Data Guard 的建議架構。 此架構可讓您取得 VM 運行時間 SLA 99.99%。
在上圖中，客戶端系統會使用 Web 存取具有 Oracle 後端的自定義應用程式。 Web 前端是在負載平衡器中設定。 Web 前端會呼叫適當的應用程式伺服器來處理工作。 應用程式伺服器會查詢主要 Oracle 資料庫。 Oracle 資料庫已使用具有限制核心 vCPU 的超線程記憶體優化虛擬機來設定，以節省授權成本並最大化效能。 多個進階或 Ultra 磁碟（受控磁碟）用於效能和高可用性。
Oracle 資料庫會放在多個可用性區域中，以達到高可用性。 每個區域皆由一或多個配備獨立電源、冷卻系統及網路的資料中心組成。 為了確保復原能力，在所有已啟用的區域中至少設定三個不同的區域。 區域內可用性區域的實體區隔可保護數據免於數據中心失敗。 此外，兩個 FSFO 觀察者會跨兩個可用性區域設定，以在發生中斷時起始資料庫，並將資料庫故障轉移至輔助資料庫。
在此情況下，您可能會在不同的可用性區域 AZ 1 中設定其他觀察者或待命資料庫，而不是上述架構中顯示的區域。 最後，Oracle Enterprise Manager （OEM） 會監視 Oracle 資料庫以取得運行時間和效能。 OEM 也可讓您產生各種效能與使用方式報告。
在不支援可用性區域的區域中，您可以使用可用性設定組，以高可用性方式部署 Oracle 資料庫。 可用性設定組可讓您達到 99.95% 的 VM 執行時間。 下圖是此用途的參考架構：
注意
- 因為部署的 OEM 實例只有一個，因此您不需要將 Oracle Enterprise Manager VM 放在可用性設定組中。
- 可用性設定組組態目前不支援 Ultra 磁碟。
Oracle Data Guard Far Sync
Oracle Data Guard Far Sync 為 Oracle 資料庫提供零數據遺失保護功能。 這項功能可讓您在資料庫機器失敗時防止數據遺失。 Oracle Data Guard Far Sync 必須安裝在不同的 VM 上。 Far Sync 是輕量型 Oracle 實例，只有控制檔、密碼檔案、spfile 和待命記錄。 沒有資料檔或重做記錄檔。
針對零數據遺失保護，主資料庫與 Far Sync 實例之間必須有同步通訊。 Far Sync 實例會以同步方式從主要資料庫接收重做，並以異步方式將它立即轉送至所有待命資料庫。 此設定也會降低主資料庫的額外負荷，因為它只需要將重做傳送至 Far Sync 實例，而不是所有待命資料庫。 如果 Far Sync 實例失敗，Data Guard 會自動從主資料庫使用異步傳輸至輔助資料庫，以維護接近零的數據遺失保護。 為了增加復原能力，客戶可能會為每個資料庫實例部署多個 Far Sync 實例，包括主要和次要。
下圖是使用 Oracle Data Guard Far Sync 的高可用性架構：
在上述架構中，在與資料庫實例相同的可用性區域中部署了 Far Sync 實例，以減少兩者之間的延遲。 如果應用程式延遲敏感，請考慮在鄰近放置群組中部署您的資料庫和 Far Sync 實例或實例。
下圖是使用 Oracle Data Guard FSFO 和 Far Sync 來達成高可用性和災害復原的架構：
Oracle GoldenGate
GoldenGate 可跨企業中的多個異質平臺，在交易層級交換和操作數據。 它會移動具有交易完整性的認可交易，以及現有基礎結構的最小額外負荷。 其模組化架構可讓您彈性地跨各種拓撲擷取和複寫選取的數據記錄、交易變更，以及數據定義語言 （DDL） 的變更。
Oracle GoldenGate 可讓您藉由提供雙向複寫來設定資料庫的高可用性。 此方法可讓您設定 多宿主 或 主動-主動組態。 下圖是 Azure 上 Oracle GoldenGate 主動-主動設定的建議架構。 在下列架構中，Oracle 資料庫已使用具有限制核心 vCPU 的超線程記憶體優化虛擬機進行設定，以節省授權成本並最大化效能。 此架構會使用多個進階或 Ultra 磁碟（受控磁碟）來達到效能和可用性。
注意
在目前無法使用可用性區域的區域，可以使用可用性設定組來設定類似的架構。
Oracle GoldenGate 有擷 取、 幫浦和 複寫等 程式，可協助您以異步方式將數據從一部 Oracle 資料庫伺服器複寫到另一部。 這些程式可讓您設定雙向複寫，以確保如果可用性區域層級停機，資料庫的高可用性。
在上圖中，擷取進程會在與 Oracle 資料庫相同的伺服器上執行。 數據幫浦和複寫程式會在相同可用性區域中的個別伺服器上執行。 複寫程式可用來從其他可用性區域中的資料庫接收數據，並將數據認可至可用性區域中的 Oracle 資料庫。 同樣地，數據幫浦進程會將擷取進程擷取的數據傳送至其他可用性區域中的 Replicat 進程。
雖然上述架構圖顯示在不同的伺服器上設定的數據幫浦和複寫程式，但您可能會根據伺服器的容量和使用量，在同一部伺服器上設定所有 Oracle GoldenGate 進程。 請一律諮詢您的 AWR 報告和 Azure 中的計量，以了解伺服器的使用模式。
在不同的可用性區域或不同區域設定 Oracle GoldenGate 雙向複寫時，請務必確保應用程式可以接受不同元件之間的延遲。 可用性區域與區域之間的延遲可能會有所不同。 延遲取決於多個因素。 建議您在不同的可用性區域或區域中，設定應用層與資料庫層之間的效能測試。 測試可以確認組態符合您的應用程式效能需求。
應用層可以在自己的子網中設定，而資料庫層可以分成自己的子網。 可能的話，請考慮使用 Azure 應用程式閘道 來平衡應用程式伺服器之間的流量。 應用程式閘道 是健全的Web流量負載平衡器。 它提供以 Cookie 為基礎的工作階段親和性，可保留相同伺服器上的用戶會話，將資料庫的衝突降到最低。 應用程式閘道 的替代方法是 Azure Load Balancer 和 Azure 流量管理員。
Oracle 分區化
分區化是在 Oracle 12.2 中引進的數據層模式。 它可讓您跨獨立資料庫水準分割及調整數據。 這是一種無共享架構，其中每個資料庫都裝載在專用虛擬機上。 此模式除了恢復能力和提高可用性之外，還可啟用高讀取和寫入輸送量。
此模式可消除單一失敗點、提供錯誤隔離，並啟用滾動升級，而不需要停機。 一個分區或數據中心層級失敗的停機時間不會影響其他數據中心內其他分區的效能或可用性。
分區化適用於無法承受任何停機時間的高輸送量 OLTP 應用程式。 具有相同分區化索引鍵的所有數據列一律都保證位於相同的分區上。 這個事實會增加效能，以提供高一致性。 使用分區化的應用程式必須具有定義完善的數據模型和數據散發策略，例如一致的哈希、範圍、清單或複合。 此策略主要會使用分區化密鑰來存取數據，例如 customerId 或 accountNum。 分區化也可讓您將特定數據集儲存到更接近終端客戶，從而協助符合您的效能和合規性需求。
建議您復寫分區，以取得高可用性和災害復原。 此設定可以使用 Oracle Data Guard 或 Oracle GoldenGate 等 Oracle 技術來完成。 復寫單位可以是分區、分區的一部分或分區群組。 一或多個分區中斷或變慢不會影響分區化資料庫的可用性。
針對高可用性，待命分區可以放在放置主要分區的相同可用性區域中。 針對災害復原，待命分區可以位於另一個區域。 您也可以在多個區域中部署分區，以提供這些區域中的流量。 若要深入瞭解如何設定分區化資料庫的高可用性和複寫，請參閱 分區層級高可用性。
Oracle 分區化主要包含下列元件。 如需詳細資訊，請參閱 Oracle 分區化概觀：
分區目錄。 特殊用途的 Oracle 資料庫，是所有分區資料庫組態數據的永續性存放區。 分區資料庫中的所有設定變更，例如新增或移除分區、數據對應，以及分區資料庫中的 DDL 都會在分區目錄上起始。 分區目錄也包含 SDB 中所有重複資料表的主要複本。
分區目錄會使用具體化檢視自動複寫所有分區中重複數據表的變更。 分區目錄資料庫也會作為查詢協調器，用來處理未指定分區化索引鍵的多分區查詢和查詢。
我們建議將 Oracle Data Guard 與可用性區域或可用性設定組搭配使用，以達到分區目錄高可用性的最佳作法。 分區目錄的可用性不會影響分區化資料庫的可用性。 分區目錄中的停機時間只會影響Data Guard故障轉移完成的短暫期間內的維護作業和多分區查詢。 SDB 會繼續路由並執行在線交易。 目錄中斷不會影響它們。
分區主管。 需要在分區所在的每個區域/可用性區域中部署的輕量型服務。 分區主管是部署在 Oracle 分區化內容中的全域服務管理員。 針對高可用性，建議您在分區存在於每個可用性區域中部署至少一個分區導演。
一開始連接到資料庫時，分區導演會設定路由資訊，並快取後續要求的資訊，這會略過分區導演。 一旦使用分區建立會話，所有 SQL 查詢和 DML 都會在指定的分區範圍內受到支持和執行。 此路由快速且用於執行分區內交易的所有 OLTP 工作負載。 我們建議您針對需要最高效能和可用性的所有 OLTP 工作負載使用直接路由。 當分區變成無法使用或發生分區化拓撲變更時，路由快取會自動重新整理。
針對高效能的數據相依路由，Oracle 建議在存取分區化資料庫中的數據時使用聯機集區。 Oracle 連線集區、語言特定連結庫和驅動程序支援 Oracle 分區化。 如需詳細資訊，請參閱 Oracle 分區化概觀。
全域服務。 全域服務類似於一般資料庫服務。 除了資料庫服務的所有屬性之外，全域服務也有分區化資料庫的屬性。 這些屬性包括用戶端與分區與復寫延遲容錯之間的區域親和性。 只有一個全域服務需要建立，才能讀取/寫入分區化資料庫的數據。 使用 Active Data Guard 並設定分區的唯讀複本時，您可以為唯讀工作負載建立另一個全域服務。 用戶端可以使用這些全域服務來連線到資料庫。
分區資料庫。 分區資料庫是 Oracle 資料庫。 在啟用 FSFO 的 Broker 設定中，會使用 Oracle Data Guard 複寫每個資料庫。 您不需要在每個分區上設定 Data Guard 故障轉移和復寫。 建立共享資料庫時，會自動設定及部署這個層面。 如果特定分區失敗，Oracle 共用會將資料庫連線從主要復本故障轉移到待命。
您可以使用兩個介面來部署和管理 Oracle 分區化資料庫：Oracle Enterprise Manager 雲端控制 GUI 和 GDSCTL 命令行公用程式。 您甚至可以使用雲端控制監視不同的分區，以取得可用性和效能。 命令 GDSCTL DEPLOY 會自動建立分區及其各自的接聽程式。 此外，此命令會自動部署用於系統管理員所指定分區層級高可用性的複寫組態。
分區化資料庫的方式有不同：
- 系統管理的分區化：使用分割自動分散到分區
- 使用者定義的分區化：可讓您指定數據與分區的對應，這在法規或數據當地語系化需求時運作良好
- 複合分區化：不同 分區空間的系統管理和用戶定義分區化組合
- 數據表子數據分割：類似於一般數據分割數據表
如需詳細資訊，請參閱 分區化方法。
分區化資料庫看起來像是應用程式和開發人員的單一資料庫。 當您移轉至分區化資料庫時，請仔細規劃以瞭解哪些數據表重複與分區化。
重複的數據表會儲存在所有分區上，而分區化數據表則會分散到不同的分區。 建議您複製小型和維度數據表，並將事實數據表分散/分區。 數據可以使用分區目錄作為中央協調器，或在每個分區上執行 Data Pump，將數據載入分區化資料庫。 如需詳細資訊，請參閱 將數據遷移至分區化資料庫。
使用 Data Guard 進行 Oracle 分區化
Oracle Data Guard 可用於使用系統管理、使用者定義和複合分區化方法進行分區化。
下圖是 Oracle 分區化與 Oracle Data Guard 的參考架構，用於每個分區的高可用性。 架構圖顯示 複合分區化方法。 架構圖表可能會因數據位置、負載平衡、高可用性和災害復原的不同需求而有所不同。 應用程式可能會使用不同的方法進行分區化。 Oracle 分區化可讓您藉由提供這些選項，以水準且有效率地調整這些需求。 您也可以使用 Oracle GoldenGate 來部署類似的架構。
系統管理的分區化是設定和管理的最簡單方式。 用戶定義的分區化或複合分區化非常適合數據與應用程式分散在異地散發的案例，或您需要控制每個分區的複寫。
在上述架構中，複合分區化可用來異地散發數據，並水平相應放大應用層。 複合分區化是系統管理與用戶定義分區化的組合，因此提供這兩種方法的優點。 在上述案例中，數據會先分區化到以區域分隔的多個分區空間。 然後，數據會使用分區空間中多個分區的一致哈希進一步分割。
每個分區空間都包含多個分區群組。 每個分區群組都有多個分區，而且是複寫單位。 每個分區群組都包含shardspace中的所有數據。 分區群組 A1 和 B1 是主要分區群組，而分區群組 A2 和 B2 則是待命。 您可以選擇讓個別分區成為複寫單位，而不是分區群組。
在上述架構中，全域服務管理員（GSM）/分區主管會部署在每個可用性區域中，以達到高可用性。 建議您為每個資料中心/區域部署至少一個 GSM/分區主管。 此外，應用程式伺服器的實例會部署在包含分區群組的每個可用性區域中。 這個設定可讓應用程式在應用程式伺服器與資料庫/分區群組之間保持低延遲。 如果資料庫失敗，則與待命資料庫位於相同區域中的應用程式伺服器可以在資料庫角色轉換發生后處理要求。 Azure 應用程式閘道 和分區主管會追蹤要求和回應延遲，並據以路由傳送要求。
從應用程式的觀點來看，客戶端系統會向 Azure 中的 Azure 應用程式閘道 或其他負載平衡技術提出要求，以將要求重新導向至最接近客戶端的區域。 Azure 應用程式閘道 也支援黏性會話，因此來自相同用戶端的任何要求會路由傳送至相同的應用程式伺服器。 應用程式伺服器會在資料存取驅動程式中使用連線共用。 此功能適用於 JDBC、ODP.NET 和 OCI 等驅動程式。 驅動程式可以辨識指定為要求一部分的分區化索引鍵。 適用於 JDBC 用戶端的 Oracle 通用 連線 ion 集區 （UCP）可讓 Apache Tomcat 和 IIS 等非 Oracle 應用程式用戶端使用 Oracle 分區化。 如需詳細資訊，請參閱 資料庫分區化 UCP 共用集區概觀。
在初始要求期間，應用程式伺服器會連線到其區域中的分區 Director，以取得要求必須路由傳送至之分區的路由資訊。 根據傳遞的分區化密鑰，Director 會將應用程式伺服器路由至個別分區。 應用程式伺服器會藉由建置對應來快取這項資訊，並針對後續要求略過分區導演，並將要求直接路由傳送至分區。
使用 GoldenGate 進行 Oracle 分區化
下圖是 Oracle 分區化與 Oracle GoldenGate 的參考架構，適用於每個分區的區域高可用性。 與上述架構相反，此架構只會在具有多個可用性區域的單一 Azure 區域內描繪高可用性。 您可以使用 Oracle GoldenGate，部署類似上述範例的多區域高可用性分區化資料庫。
上述參考架構會使用 系統管理的 分區化方法來分割數據。 由於 Oracle GoldenGate 複寫是在區塊層級完成，一半的數據可以復寫至另一個分區。 另一半可以復寫至不同的分區。
數據復寫的方式取決於複寫因數。 複寫因數為 2，您在分區群組中的三個分區中，有兩個數據區塊複本。 同樣地，在分區群組中，複寫因數為三個和三個分區，每個分區中的所有數據都會復寫到分區群組中的每個其他分區。 分區群組中的每個分區都可以有不同的複寫因數。 此設定可協助您在分區群組和多個分區群組內有效率地定義高可用性和災害復原設計。
在上述架構中，分區群組 A 和分區群組 B 都包含相同的數據，但位於不同的可用性區域。 如果分區群組 A 和分區群組 B 具有相同的三個復寫因數，則分區化數據表的每個數據列/區塊都會在兩個分區群組之間復寫六次。 如果分區群組 A 的復寫因數為 3，而分區群組 B 的複寫因數為 2，則每個數據列/區塊會在兩個分區群組之間復寫五次。
如果實例層級或可用性區域層級失敗發生，此設定會防止數據遺失。 應用層能夠讀取和寫入每個分區。 為了將衝突降至最低，Oracle 分區化會為每個哈希值範圍指定主要 區塊 。 這項功能可確保特定區塊的寫入要求會導向至對應的區塊。 此外，Oracle GoldenGate 提供自動衝突偵測和解決，以處理可能發生的任何衝突。 如需使用 Oracle 分區化實作 GoldenGate 的詳細資訊和限制，請參閱 搭配分區化資料庫使用 Oracle GoldenGate。
在上述架構中，GSM/分區導演會部署在每個可用性區域中，以達到高可用性。 建議您為每個資料中心或區域部署至少一個 GSM/分區主管。 應用程式伺服器的實例會部署在包含分區群組的每個可用性區域中。 這個設定可讓應用程式在應用程式伺服器與資料庫/分區群組之間保持低延遲。 如果資料庫失敗，與待命資料庫位於相同區域中的應用程式伺服器可以在資料庫角色轉換后處理要求。 Azure 應用程式閘道 和分區主管會追蹤要求和回應延遲，並據以路由傳送要求。
從應用程式的觀點來看，客戶端系統會向 Azure 中的 Azure 應用程式閘道 或其他負載平衡技術提出要求，以將要求重新導向至最接近客戶端的區域。 Azure 應用程式閘道 也支援黏性會話，因此來自相同用戶端的任何要求會路由傳送至相同的應用程式伺服器。 應用程式伺服器會在資料存取驅動程式中使用連線共用。 此功能適用於 JDBC、ODP.NET 和 OCI 等驅動程式。 驅動程式可以辨識指定為要求一部分的分區化索引鍵。 適用於 JDBC 用戶端的 Oracle 通用 連線 ion 集區 （UCP）可讓 Apache Tomcat 和 IIS 等非 Oracle 應用程式用戶端使用 Oracle 分區化。
在初始要求期間，應用程式伺服器會連線到其區域中的分區 Director，以取得要求必須路由傳送至之分區的路由資訊。 根據傳遞的分區化密鑰，Director 會將應用程式伺服器路由至個別分區。 應用程式伺服器會藉由建置對應來快取這項資訊，並針對後續要求略過分區導演，並將要求直接路由傳送至分區。
修補和維護
當您將 Oracle 工作負載部署至 Azure 時，Microsoft 會負責所有主機操作系統層級修補。 Microsoft 會事先與客戶溝通任何計劃性操作系統層級維護。 來自兩個不同可用性區域的兩部伺服器永遠不會同時修補。 如需 VM 維護和修補的詳細資訊，請參閱 Azure 虛擬機器 的可用性選項。
您可以使用 Azure 自動化 更新管理來自動修補虛擬機作業系統。 您可以使用 Azure Pipelines 或 Azure 自動化 Update Management 來自動及排程修補和維護 Oracle 資料庫，以將停機時間降到最低。 如需持續傳遞和藍/綠部署的詳細資訊，請參閱 漸進式曝光技術。
架構與設計考慮
- 請考慮針對 Oracle 資料庫 VM 使用具有限制核心 vCPU 的超線程優化虛擬機，以節省授權成本並最大化效能。 使用多個進階或 Ultra 磁碟（受控磁碟）以達到效能和可用性。
- 當您使用受控磁碟時，磁碟/裝置名稱可能會在重新啟動時變更。 我們建議您使用裝置 UUID，而不是名稱，以確保掛接會保存在重新啟動的 Sprite 中。 如需詳細資訊，請參閱 將新的文件系統新增至 /etc/fstab。
- 使用可用性區域來達到區域中的高可用性。
- 當您的 Oracle 資料庫可用或進階磁碟時，請考慮使用 Ultra 磁碟。
- 請考慮使用 Oracle Data Guard 在另一個 Azure 區域中設定待命 Oracle 資料庫。
- 請考慮使用 鄰近放置群組 來減少應用程式與資料庫層之間的延遲。
- Azure VM 網路頻寬上限高於相同 SKU 上的最大磁碟輸送量。 您可以在相同的 VM SKU 上達到更高的輸送量，或使用較小的 VM SKU，方法是使用高效能、低延遲的網路記憶體，例如 Azure NetApp Files。 資料庫。
- 設定 Oracle Enterprise Manager 以進行管理、監視和記錄。
- 請考慮使用 Oracle 自動 儲存體 管理，以簡化資料庫的記憶體管理。
- 使用 Azure Pipelines 來管理資料庫的修補和更新，而不需要停機。
- 調整應用程式程式代碼以新增雲端原生模式，以協助您的應用程式更具復原性。 請考慮重試模式、斷路器模式，以及雲端設計模式指南中定義的其他模式。
下一步
檢閱下列適用於您案例的 Oracle 參考文章。