本繁體中文版使用機器翻譯，譯文僅供參考，若與英文版本牴觸，應以英文版本為準。

性能驗證和基準測試結果

08/18/2025 貢獻者

此次性能驗證的目的不是為了樹立任何標記。相反，如果您遵循本文檔中概述的部署流程和最佳實踐，您可以期望在公有雲中部署 Oracle 資料庫獲得類似的效能指標。

我們使用 Swingbench 銷售訂單輸入 (SOE) 模組來模擬 OLTP 類型的工作負載，並將工作負載應用於部署到具有 NFS 協定上的 FSx 儲存磁碟區的 M5 EC2 執行個體的 Oracle 資料庫。預設的 Swingbench SOE I/O 設定檔接近 80/20 讀/寫分割，這接近真實的 OLTP Oracle 工作負載設定檔。

隨著客戶端執行銷售訂單輸入、瀏覽、庫存查詢等操作的並髮使用者數量的增加，工作負載也會隨之增加。測試的數量分別為 8、16、32、64 和 128 個同時使用者。 Swingbench 使用的演算法在伺服器端很繁重，以推動合理的交易量並測試 Oracle 伺服器的極限。我們觀察到，當同時使用者數為 128 時，EC2 執行個體的 CPU 使用率達到容量的約 80-90%。

以下部分提供了設定和測試結果的詳細資訊。

測試環境設定

運算

我們部署了一個 EC2 M5 實例，它有 8vCPU、32G RAM 和 10Gps 的網路頻寬。

此圖顯示輸入/輸出對話框或表示書面內容

FSx 存儲

我們建立了三個資料庫卷，並使用 NFS 將捲掛載到 EC2 執行個體上，如下所示：

/u01——Oracle 二進位文件
/u02——Oracle資料檔、控製文件
/u03——Oracle日誌檔、控製文件

我們保留了關鍵控製文件的兩個副本以實現冗餘。

此圖顯示輸入/輸出對話框或表示書面內容

FSx 檔案系統配置了 80,000 IOPS 容量和 2GiBps I/O 吞吐量。

Oracle 配置

我們安裝了帶有 RU 補丁 19.8 的 Oracle 版本 19c。伺服器上啟用了 dNFS。

該資料庫被部署為具有三個 PDB 的容器化資料庫。我們使用一個 PDB 實例進行效能測試。下圖顯示了 NFS 掛載點上的 Oracle 儲存大小。

此圖顯示輸入/輸出對話框或表示書面內容

Swingbench 配置

我們在具有 8vCPU 和 32G RAM 的 Windows 主機上部署了 Swingbench 2.6（最新版本）。我們使用 SOE plsql 測試模組版本 2 作為基準。預設負載設定檔提供 80/20 的讀取/寫入比率來模擬現實世界的 OLTP 事務工作負載。

我們使用的模式比例因子為 50，它提供了 160G 的初始資料載入大小和 30G 的臨時空間分配。在這個規模因素下，SOE 模式提供了 1000 個倉庫和 5000 萬個客戶來模擬線上訂單處理。

以下螢幕截圖示範了 Swingbench Windows UI 中的工作負載設定檔和典型的交易運作指標。

此圖顯示輸入/輸出對話框或表示書面內容

如該圖所示，在整個測試運行過程中，交易水準一直保持在同一水準。

測試結果分析

我們捕獲了每次測試運行的 Swingbench 結果並獲得了相應的 Oracle AWR 報告以進行效能分析。

從最終用戶的角度，我們專注於交易量和用戶回應時間等關鍵指標。這兩個指標都顯示了在給定並發登入系統的使用者數量的情況下，使用者可以從銷售訂單輸入系統執行的交易數量，以及使用者輸入訂單後完成交易和收到回應的速度。

從 Oracle 伺服器端，我們解析了 Oracle AWR 報告，以確定可能減慢使用者事務速度的頂級等待事件。前 10 個 Oracle 等待事件表明，在 Swingbench 模擬事務測試運行期間，Oracle 伺服器主要受 I/O 限制，資料庫時間的 50%-60% 都花在 db file sequential read。 `log file sync`也是一個促成因素，因為事務提交會導致 Oracle 日誌記錄過程將日誌 I/O 從緩衝區快取刷新到磁碟上的日誌文件，儘管它在資料庫時間百分比層級上是一個較小的因素。

我們繪製了使用者交易量、使用者回應時間和 Oracle 頂部等待事件與事務運行期間的同時使用者數的圖表。結果如下圖所示：

此圖顯示輸入/輸出對話框或表示書面內容