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 提供 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 之外，也部署 Data Guard Far Sync 執行個體。
如果您的應用程式允許延遲，請考慮在 Oracle 主要資料庫以外的可用性區域中設定 Data Guard Far Sync 執行個體。 需要進行完整測試。 使用最大可用性模式，設定將重做檔案同步傳輸至 Far Sync 執行個體。 接下來這些檔案便會以非同步的方式傳送至待命資料庫。
在最大可用性模式 (同步) 的另一個可用性區域中設定 Far Sync 執行個體時，您的應用程式可能不會允許效能遺失。 如果不允許，則您可能要在與主資料庫相同的可用性區域中設定 Far Sync 執行個體。 為了增加可用性，請考慮在主要資料庫附近設定多個 Far Sync 執行個體，並在待命資料庫附近設定至少一個執行個體，以防角色轉換。
當您使用 Oracle Standard Edition 資料庫時，有幾項 ISV 解決方案，能讓您設定高可用性和災害復原，例如 DBVisit Standby。
參考架構
Oracle 資料保護
Oracle Data Guard 能確保企業資料的高可用性、資料保護和災害復原。 Data Guard 會將待命資料庫維護為主要資料庫的交易一致性複本。 根據主要和次要資料庫與應用程式延遲容錯之間的距離，您可以設定同步或非同步複寫。 如果因為計劃性或非計劃性中斷而無法使用主要資料庫，Data Guard 可以將任何待命資料庫切換至主要角色，進而將停機時間降到最低。
使用 Oracle Data Guard 時，您也可以開啟次要資料庫供唯獨使用。 此設定稱為 Active Data Guard。 Oracle Database 12c 引進了名為 Data Guard Far Sync Instance 的功能。 這個執行個體可讓您在不影響效能的情況下為 Oracle 資料庫設定零資料遺失設定。
注意
Active Data Guard 需要額外的授權。 此授權也需要使用 Far Sync 功能。 聯繫您的 Oracle 代表，以討論授權意涵。
具有快速啟動容錯移轉的 Oracle Data Guard
具備快速啟動容錯移轉 (FSFO) 的 Oracle Data Guard 可以在個別電腦上設定訊息代理程式，提供更多的復原能力。 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 Database。 可用性設定組讓您能達到 99.95% 的 VM 執行時間。 下圖為此用途的參考架構：
注意
- 由於只部署一個 OEM 執行個體，您無需在可用性設定組中放置 Oracle Enterprise Manager VM。
- 可用性設定組設定目前並未支援 Ultra 磁碟。
Oracle Data Guard Far Sync
Oracle Data Guard Far Sync 為 Oracle Database 提供零資料遺失保護功能。 此功能可讓您在資料庫機器故障時防止資料遺失。 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 實例或實例。
下圖是使用 Oracle Data Guard FSFO 和 Far Sync 的架構，以達成高可用性和災害復原：
Oracle GoldenGate
GoldenGate 支援在跨企業多個異質平台之間，進行交易等級的資料交換和操作。 GoldenGate 會以具有交易完整性及對現有基礎結構最低額外負荷的方式，來移動已認可的交易。 其模組化架構可讓您靈活地在各種拓樸架構中擷取和複寫選取的資料記錄、交易變更，及資料定義語言 (DDL) 變更。
Oracle GoldenGate 可讓您藉由提供雙向複寫，來設定資料庫以實現高可用性。 此方法可讓您設定多重主機或主動-主動設定。 下圖為 Azure 上 Oracle GoldenGate 主動-主動設定的建議架構。 在下列架構中，Oracle 資料庫是使用具有限制核心 vCPU 的超線程記憶體優化虛擬機來設定，以節省授權成本並最大化效能。 為了提供效能和可用性，此架構使用了多個進階或 Ultra 磁碟 (受控磁碟)。
注意
您可以在目前無法使用可用性區域的區域，使用可用性設定組來設定類似的架構。
Oracle GoldenGate 具有 Extract、Pump 和 Replicat 等程序，可協助您以非同步方式將資料從一部 Oracle 資料庫伺服器複寫到另一部。 這些程序可讓您設定雙向複寫，若出現可用性區域層級停機時，能確保資料庫的高可用性。
在上圖中，會在與 Oracle 資料庫相同的伺服器上執行擷取流程。 資料幫浦和複寫流程會在相同可用性區域中的個別伺服器上執行。 複寫程序可用於從其他可用性區域中的資料庫接收資料，並將資料認可至其可用性區域中的 Oracle 資料庫。 同樣地，資料幫浦程序會將擷取程序所擷取的資料傳送至其他可用性區域中的複寫程序。
雖然上述架構圖顯示在另一部伺服器上設定的資料幫浦和複寫程序，但您也可以根據伺服器的容量和使用方式，在同一部伺服器上設定所有的 Oracle GoldenGate 程序。 請隨時參閱您的 AWR 報告和 Azure 中的計量，以了解伺服器的使用模式。
在不同可用性區域或不同區域中設定 Oracle GoldenGate 雙向複寫時，請務必確保應用程式可接受不同元件之間的延遲。 可用性區域與區域之間的延遲可能會有所不同。 延遲取決於多個因素。 我們建議您在不同的可用性區域或區域中設定應用程式層與資料庫層之間的效能測試。 測試可以確認組態符合您的應用程式效能需求。
應用程式層可以在自己的子網路中設定，資料庫層則可以分隔為至自己的子網路中。 可能的話，請考慮使用 Azure 應用程式閘道，使應用程式伺服器之間達到流量負載平衡。 應用程式閘道為強大的網路流量負載平衡器。 提供以 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 Cloud Control GUI 和 GDSCTL 命令列公用程式。 您甚至可以使用雲端控制，以監視不同分區的可用性和效能。 此 GDSCTL DEPLOY 命令會自動建立分區及其各自的接聽程式。 此外，此命令會自動部署用於系統管理員所指定分區層級高可用性的複寫設定。
將資料庫分區化有許多不同的方式：
- 系統管理的分區化：使用資料分割自動分散到分區
- 使用者定義的分區化：可讓您指定資料與分區的對應，在有法規或資料當地語系化需求時，這個功能會很實用
- 複合分區化：不同分區空間的系統管理與使用者定義分區化組合
- 資料表子分割：類似於一般的資料分割資料表
如需詳細資訊，請參閱分區化方式。
分區化資料庫看起來像是應用程式和開發人員的單一資料庫。 當您移轉至分區化資料庫時，請仔細規劃以了解哪些資料表重複與分區化。
複製的資料表會儲存在所有分區上，而分區化資料表則會分散至不同的分區。 我們建議您複製小型和維度資料表，並分散/分區事實資料表。 您可以使用分區目錄作為中央協調器，或在每個分區上執行資料幫浦，將資料載入分區化資料庫。 如需詳細資訊，請參閱將資料遷移至分區化資料庫。
使用 Data Guard 進行 Oracle 分區化
Oracle Data Guard 能使用系統管理、使用者定義和複合分區化方法進行分區化。
下圖是使用 Oracle Data Guard 進行 Oracle 分區化的參考架構，以達成每個分區的高可用性。 架構圖示範的是複合分區化方法。 針對資料位置、負載平衡、高可用性和災害復原，圖可能會有所不同，並且可能會使用不同的方法進行分區化。 應用程式可能會使用不同的方法進行分區化。 Oracle 分區化提供這些選項，讓您能符合這些需求，並進行水平且有效率的縮放。 甚至可以使用 Oracle GoldenGate 部署類似的架構。
系統受控分區化是最簡單的設定和管理方式。 資料與應用程式分散在不同地理位置，或您需要控制每個分區複寫的情況下，則適合採用使用者定義的分區化或複合分區化。
在上述架構中，複合分區化可用來異地分散數據，並水準向外延展應用層。 複合分區化結合了系統管理和使用者定義分區化，因此能提供這兩種方法的優點。 在上述案例中，資料會先在以區域分隔的多個分區空間中分區化。 然後，資料會使用分區空間中多個分區的一致雜湊進一步分割。
每個分區空間都包含多個分區群組。 每個分區群組都有多個分區，並且是複寫的一個單位。 每個分區群組都包含分區空間中的所有資料。 分區群組 A1 和 B1 是主要分區群組，而分區群組 A2 和 B2 則為待命。 您可以選擇讓個別分區成為複寫單位，而非分區群組。
在上述架構中，Global Service Manager (GSM)/分區導向器會部署在每個可用性區域中，以取得高可用性。 我們建議您為每個資料中心/區域都部署至少一個 GSM/分區導向器。 此外，應用程式伺服器的執行個體會部署在每個包含分區群組的可用性區域中。 此設定可讓應用程式將應用程式伺服器與資料庫/分區群組之間保持在低延遲。 如果資料庫失敗，在發生資料庫角色轉換時，與待命資料庫位於相同區域的應用程式伺服器便能處理要求。 Azure 應用程式閘道和分區導向器會追蹤要求和回應延遲，並據此路由要求。
就應用程式的觀點而言，用戶端系統會向 Azure 應用程式閘道發出要求或其他 Azure 負載平衡技術，其便會將要求重新導向至最接近用戶端的區域。 Azure 應用程式閘道也支援黏性工作階段，因此來自相同用戶端的任何要求皆會路由至相同的應用程式伺服器。 應用程式伺服器會在資料存取驅動程式中使用連線共用。 此功能可用於 JDBC、ODP.NET 和 OCI 等驅動程式。 驅動程式可以辨識指定為要求一部分的分區金鑰。 適用於 JDBC 用戶端的 Oracle 通用連線集區 (UCP) 可以使非 Oracle 應用程式客戶端 (例如 Apache Tomcat 和 IIS) 與 Oracle 分區化一起運作。 如需詳細資訊，請參閱 資料庫分區化的 UCP 共用集區概觀。
在初始要求期間，應用程式伺服器會連線至其區域中的分區導向器，以取得要求所需要路由的分區路由資訊。 根據傳遞的分區金鑰，導向器會將應用程式伺服器路由至對應的分區。 應用程式伺服器會藉由建置一個對應 (map) 來快取這項資訊，對於後續的要求，則略過分區導向器，並將要求直接路由至分區。
使用 GoldenGate 進行 Oracle 分區化
下圖是使用 GoldenGate 進行 Oracle 分區化的參考架構，以實現每個分區的區域內高可用性。 相對於上述架構，此架構僅於單一 Azure 區域內，有多個可用性區域，提供高可用性。 您能夠使用 Oracle GoldenGate 部署多區域的高可用性分區資料庫，類似於先前範例。
上述參考架構會使用「系統管理的」分區化方法將資料分區。 由於 Oracle GoldenGate 複寫在區塊層級完成，所以複寫至一個分區的一半資料可以複寫至另一個分區。 另一半資料則可以複寫至不同的分區。
複寫資料的方式取決於複寫因數。 複寫因數為 2 時，在分區群組的三個分區中會各有兩個資料區塊複本。 同樣地，複寫因數為 3 且在分區群組中有三個分區時，每個分區中的所有資料都會複寫至分區群組中的其他每個分區。 分區群組中的每個分區都能有不同的複寫因數。 此設定可協助您在分區群組和多個分區群組內，有效率地定義高可用性和災害復原設計。
在上述架構中，分區群組 A 和分區群組 B 都包含相同的資料，但位於不同的可用性區域中。 如果分區群組 A 和分區群組 B 都有相同的複寫因數 3，則分區資料表的每個資料列/區塊都會在兩個分區群組之間複寫 6 次。 如果分區群組 A 的複寫因數為 3，而分區群組 B 的複寫因數為 2，則每個資料列/區塊會在兩個分區群組之間複寫 5 次。
如果發生執行個體層級或可用性區域層級失敗，此設定能防止資料遺失。 應用程式層能夠讀取和寫入每個分區。 為了將衝突最小化，Oracle 分區化會為每個雜湊值範圍指定主要區塊。 此功能可確保特定區塊的寫入要求會導向對應的區塊。 此外，Oracle GoldenGate 提供自動衝突偵測和解決，以處理任何可能發生的衝突。 如需使用 Oracle 分區化實作 GoldenGate 的詳細資訊和限制，請參閱搭配分區資料庫使用 Oracle GoldenGate。
在上述架構中，GSM/分區導向器會部署在每個可用性區域中，以取得高可用性。 我們建議您為每個資料中心或區域都部署至少一個 GSM/分區導向器。 應用程式伺服器的執行個體會部署在每個包含分區群組的可用性區域中。 此設定可讓應用程式將應用程式伺服器與資料庫/分區群組之間保持在低延遲。 如果資料庫失敗，當資料庫角色轉換時，與待命資料庫位於相同區域的應用程式伺服器便能處理要求。 Azure 應用程式閘道和分區導向器會追蹤要求和回應延遲，並據此路由要求。
就應用程式的觀點而言，用戶端系統會向 Azure 應用程式閘道發出要求或其他 Azure 負載平衡技術，其便會將要求重新導向至最接近用戶端的區域。 Azure 應用程式閘道也支援黏性工作階段，因此來自相同用戶端的任何要求皆會路由至相同的應用程式伺服器。 應用程式伺服器會在資料存取驅動程式中使用連線共用。 此功能可用於 JDBC、ODP.NET 和 OCI 等驅動程式。 驅動程式可以辨識指定為要求一部分的分區金鑰。 適用於 JDBC 用戶端的 Oracle 通用連線集區 (UCP) 可以使非 Oracle 應用程式客戶端 (例如 Apache Tomcat 和 IIS) 與 Oracle 分區化一起運作。
在初始要求期間，應用程式伺服器會連線至其區域中的分區導向器，以取得要求所需要路由的分區路由資訊。 根據傳遞的分區金鑰，導向器會將應用程式伺服器路由至對應的分區。 應用程式伺服器會藉由建置一個對應 (map) 來快取這項資訊，對於後續的要求，則略過分區導向器，並將要求直接路由至分區。
修補和維護
當您將 Oracle 工作負載部署至 Azure 時，Microsoft 會負責所有主機作業系統層級的修補。 Microsoft 會事先與客戶溝通任何計劃性操作系統層級維護。 來自不同可用性區域的兩部伺服器永遠不會同時進行修補。 如需 VM 維護和修補的詳細資訊，請參閱 Azure 虛擬機器的可用性選項。
您可以使用 Azure 自動化更新管理，將修補虛擬機器作業系統自動化執行。 您可以使用 Azure Pipelines 或 Azure 自動化更新管理，將修補和維護 Oracle 資料庫自動化並進行排程，以盡量降低停機時間。 如需持續傳遞和藍/綠部署的詳細資訊，請參閱漸進式曝光技術。
架構與設計考量
- 請考慮為 Oracle Database VM 使用具有限制核心 vCPU 的超執行緒記憶體最佳化虛擬機器，以節省授權成本並將效能最大化。 為了提供效能和可用性，使用了多個進階或 Ultra 磁碟 (受控磁碟)。
- 當您使用受控磁碟時，磁碟/裝置名稱可能會在重新啟動時變更。 我們建議您使用裝置 UUID 而非名稱，以確保您的裝載在重新啟動仍會存在。 如需詳細資訊，請參閱 將新的檔案系統新增至 /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 參考文章。