重新託管建議 - AWS 方案指引
Amazon EC2 執行個體類型考量事項Amazon EBS 磁碟區類型考量事項Oracle ASM 考量事項Oracle on Amazon EC2 最佳實務

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

重新託管建議

當您在 Amazon EC2 上重新託管 Oracle 時，您會安裝和設定 Oracle 資料庫並執行所有維護操作，包括次要 Oracle 升級、主要 Oracle 升級、作業系統修補、作業系統組態、資料庫組態、記憶體配置、儲存配置和儲存組態。

Amazon EC2 執行個體類型考量事項

EC2 執行個體必須有足夠的 CPU、記憶體和儲存空間來處理預期的資料庫工作負載。我們建議您為 Oracle 資料庫使用最新一代的 EC2 執行個體類別。這些執行個體類型，例如建置在 Nitro 系統的執行個體，支援硬體虛擬機器 (HVM)。HVM Amazon Machine Image (AMIs) 需要利用增強型聯網，而且也提供更高的安全性。

在 Nitro 系統上建置的虛擬化執行個體包括 R5b, X2idn 和 X2iedn。對於高 Amazon EBS 磁碟區輸送量，請考慮 Amazon EC2 R5b 和 X2 執行個體類型。這些執行個體支援高達 260，000 IOPS。Amazon EC2 R5b 執行個體的最大輸送量為 7，500 MBps。Amazon EC2 X2idn 和 X2iedn 執行個體的最大輸送量為 10，000 MBps。如需詳細資訊，請參閱 Amazon Amazon EC2 EBS 最佳化執行個體和最大 IOPS。

Amazon EBS 磁碟區類型考量事項

Amazon EBS 一般用途 (gp3) 磁碟區比 Amazon EBS 佈建 IOPS (io2) 磁碟區便宜。如果 gp3 磁碟區符合您的 I/O 和輸送量需求，它們應該是您偏好的解決方案。單一 gp3 磁碟區每個磁碟區不得超過 16，000 IOPS。您還必須考慮可指派給 EC2 執行個體的 EBS 磁碟區數量上限。此數量會根據 EC2 執行個體類型而有所不同；不過，Nitro 系統執行個體的 EBS 磁碟區數目上限為 28。一般而言，Oracle 資料庫不應專用超過 24 個 EBS 磁碟區。

如果您的磁碟 I/O 需求很高，請考慮 Amazon EBS io2 Block Express 磁碟區。這些旨在提供每個磁碟區高達 4，000 MBps 的輸送量、每個磁碟區 256，000 IOPS、64 TiB 儲存容量、低於毫秒的延遲，以及 99.999% 的耐用性。在下列情況下，我們建議您使用 Amazon EBS io2 Block Express 磁碟區：

  • 資料庫配置空間超過 384 TiB。這包括但不限於資料庫檔案、重做日誌、TEMP空間、UNDO空間、快閃記憶體復原區域空間和資料暫存區域。Amazon EBS io2 Block Express 磁碟區最多可支援具有單一 EC2 執行個體的 1.536 PiB。

  • 您需要低於毫秒範圍的儲存延遲。

  • 您需要專為 999% 耐用性設計的資料庫，相較於使用 Amazon EBS gp3 磁碟區的 99.9% 耐用性。

  • 您需要虛擬儲存陣列，才能將 100 萬 IOPS 或更高的 IOPS 交付至單一 EC2 執行個體。

  • Exadata Smart Flash 快取和 Exadata Smart Flash Logging 在 Exadata 內部部署系統中非常高。Exadata Smart Flash 快取的 I/O 延遲通常小於讀取操作的 400 微秒。Amazon EBS io2 Block Express 的 I/O 延遲通常介於 400 到 600 微秒之間。

Oracle ASM 考量事項

當您在 Amazon EC2 上使用 Oracle 時，Oracle 和 AWS 建議您實作 Oracle Automatic Storage Management (ASM) 外部備援，以避免 Amazon EBS 故障率。不過，如果 EBS 磁碟區在 ASM 外部備援模式中無法使用，相關聯的 ASM 磁碟群組會進入強制卸載。必須找到所有磁碟，才能成功掛載 ASM 磁碟群組。因此，資料庫會變成無法使用，直到所有 EBS 磁碟區都可用為止。ASM 外部備援有效地提供 RAID 層級 0 可靠性，因此每個新增的 EBS 磁碟區都會增加影響 ASM 磁碟群組的機率，整體故障率是每個個別 EBS 磁碟區故障率的倍數。

Amazon EBS 磁碟區會在 AWS 可用區域內複寫。不過，EBS 磁碟區仍然可能遇到故障。例如，gp3 磁碟區年失敗率為 0.1–0.2%，而 io2 磁碟區年失敗率為 0.001%。您可以實作具有正常備援或高備援的 ASM 磁碟群組，以減少因單一 EBS 磁碟區故障所造成的中斷。不過，這不是最佳實務，因為 EBS 磁碟區是在可用區域內複寫，而 ASM 失敗群組 EBS 磁碟區也可以與 ASM 主要群組 EBS 磁碟區位於相同的實體主機上。

其他 ASM 考量事項：

  • 使用 Oracle ASM Filter Driver (ASMFD) 實作 ASM。

  • 確定磁碟群組中的所有 Oracle ASM 磁碟具有類似的儲存效能和可用性特性。在具有混合速度磁碟機的儲存組態中，例如快閃記憶體和硬碟 (HDD)，I/O 效能會受到最慢速度磁碟機的限制。

  • 確定磁碟群組中的 Oracle ASM 磁碟具有相同的容量來維持平衡。

  • Oracle ASM 會將資料隨機分配到選取的 ASM 磁碟集。當您設定系統的儲存體時，請考慮系統的初始容量，並規劃未來成長。Oracle ASM 簡化了適應成長的任務。如前所述，Amazon EC2 Nitro System 執行個體最多支援 28 個磁碟區。如果 DATA ASM 磁碟群組需要 96 TiB，則四個 24 TiB Amazon EBS io2 Block Express 磁碟區會比十六個 6 TiB Amazon EBS io2 Block Express 磁碟區更好的選擇。

  • 在兩個 ASM 磁碟群組中設定至少兩個控制檔案。

Oracle on Amazon EC2 最佳實務

在您將資料從內部部署的 Exadata 遷移至 Amazon EC2 上的 Oracle 之後，以及提供存取權給最終使用者之前，請考慮下列最佳實務：

  • 啟用 EC2 執行個體終止保護。這可防止 EC2 執行個體意外終止，方法是要求使用者在終止執行個體之前停用保護。

  • 啟用 Amazon EC2 自動復原功能，可在託管 EC2 執行個體的硬體受損時解決問題。此功能會復原不同基礎硬體上的執行個體，並減少手動介入的需求。

  • Amazon EC2 提供的執行個體具有高達 24 TiB 的記憶體。這些執行個體支援非常大型SGAs，如果您使用的是多 TiB Oracle SGAs則應該是您的首選。不過，許多 EC2 執行個體和 Amazon RDS for Oracle 執行個體也支援本機執行個體儲存。如果您使用 Amazon EC2 或 Amazon RDS for Oracle 執行個體搭配 NVMe SSD 執行個體儲存，您可以使用暫時性儲存來擴展 Oracle SGA 資料庫區塊緩衝區。此方法可讓您使用執行個體儲存體快取物件，並為讀取操作提供 100 微秒的平均 I/O 延遲。智慧快閃記憶體快取和/第 2 級快閃記憶體快取僅適用於使用執行個體儲存體且需要 Oracle Linux 作業系統的執行個體。OLTP 和資料倉儲環境可以從此技術中受益。設定 Oracle 初始化參數DB_FLASH_CACHE_FILE和 DB_FLASH_CACHE_SIZE以使用 Smart Flash 快取。

  • 使用 Oracle Linux 做為執行個體的作業系統。如果 Oracle Linux 不是選項，請考慮 Red Hat Enterprise Linux (RHEL)。以 Graviton 處理器為基礎的 EC2 執行個體不支援 Oracle 資料庫，因為 Oracle 尚未發行針對 ARM 處理器編譯的 Oracle 資料庫二進位檔。此外，Oracle 資料庫不支援 Amazon Linux。

  • 使用最新版 Oracle 軟體來安裝 Oracle Grid Infrastructure。您可以使用舊版 Oracle 資料庫部署最新版的 Oracle Grid Infrastructure。例如，Oracle Grid Infrastructure 21c 支援 Oracle Database 19c。

  • 如果您使用 Oracle RMAN 或 Oracle Data Guard 從舊版 Oracle Database on Exadata 遷移，請考慮在遷移後將資料庫版本升級至最新版本。如果您使用 Oracle Data Pump，請在遷移 AWS 之前在 上安裝最新的 Oracle 資料庫版本。

  • 使用 Oracle 快閃記憶體復原區域 (FRA) 快速還原資料庫，而無需使用 RMAN 備份。如果可能，請將 FRA 設定為至少一天。您必須設定 Oracle 初始化參數 DB_RECOVERY_FILE_DEST_SIZE、 DB_RECOVERY_FILE_DEST和 DB_FLASHBACK_RETENTION_TARGET（表示以分鐘為單位的時間量）。

  • 如果您將多個資料庫工作負載遷移至單一 EC2 執行個體，請考慮實作 Oracle Database Resource Manager 來管理資料庫資源配置。

  • 實作 Oracle SPFILE而非獨立 PFILE。SPFILE 是一個二進位檔案，允許動態修改，而不需要重新啟動執行個體。如果 正在使用中，則不要在使用 STARTUP命令PFILE時指定 SPFILE 。

  • 啟用 Oracle Automatic Shared Memory Manager (ASMM)，可簡化 SGA 記憶體管理。Oracle Database 會在 SGA 元件之間自動分配記憶體，以確保最有效的記憶體使用率。

  • 使用資料庫寫入器程序 (DBWR) 時，您可能會遇到 Oracle db 檔案平行寫入等待事件。此等待表示 DBWR 等待 I/O 完成所花費的時間。若要解決此問題，請確認已啟用非同步 I/O (Oracle 初始化參數 DISK_ASYNCH_IO)、增加 EBS 磁碟區的 IOPS，並確認資料庫緩衝區快取夠大，以防止當機。

  • 針對 EC2 執行個體定期執行掃描 （至少每兩週一次），並驗證合規性。您可以使用 Amazon Inspector 進行此掃描。Amazon Inspector 是一種自動化安全評估服務，可協助改善所部署應用程式的安全性和合規性 AWS。它會自動評估應用程式是否有暴露、漏洞和與最佳實務的偏差。執行評估之後，它會產生依嚴重性層級排定優先順序的安全調查結果詳細清單。您可以直接檢閱這些調查結果，或在 Amazon Inspector 主控台或 API 提供的詳細評估報告中檢閱。

  • 設定 的 Amazon CloudWatch 警示AWS CloudTrail。例如，當安全群組發生組態變更時，應該啟動 CloudWatch 警示。這會在有人嘗試存取 EC2 執行個體時提醒操作團隊。

  • 如果您的組織需要零或接近零的復原點目標 (RPO)，請在最大可用性模式中使用 Oracle Data Guard 或 Oracle Active Data Guard。待命資料庫應位於與主要資料庫不同的可用區域中。最大保護和最大可用性模式提供自動容錯移轉環境，專為避免資料遺失而設計。最大效能模式提供自動容錯移轉環境，其設計會損失不超過FastStartFailoverLagLimit組態屬性指定的資料量 （以秒為單位）。我們也建議您使用 Oracle Data Guard 或 Oracle Active Data Guard 實作 Data Guard Broker。Data Guard Broker 會自動執行 Data Guard 的組態和監控任務。Active Data Guard 需要 Oracle 授權。

  • 請考慮使用 Oracle Active Data Guard 自動區塊媒體復原。如果在存取主要資料庫時遇到損毀的資料區塊，該區塊會自動取代為實體待命資料庫中該區塊的未損毀副本。不過，若要使用此功能，Active Data Guard 必須以最大可用性模式執行，並將 Oracle 初始化參數LOG_ARCHIVE_DEST_n設定為SYNC重做傳輸模式。最大效能模式不支援此功能。

  • 如果您的組織需要跨區域災難復原，請考慮實作 Oracle Far Sync。Far Sync 需要 Oracle Active Data Guard 授權。

  • 使用 Oracle 安全備份 (OSB)，透過 Oracle RMAN 將資料庫備份至 Amazon S3。OSB 需要 Oracle 授權。OSB 定價是根據使用中的 Oracle RMAN 頻道數量。您也可以使用 AWS Storage Gateway 將資料庫直接備份到 Amazon S3。您可以將生命週期政策套用至 Amazon S3 中的備份，將較舊的備份移至 Amazon Glacier 進行封存。