Azure NetApp Files 上多個磁碟區的 Oracle 資料庫效能

  • 發行項

將高效能的Exadata等級資料庫移轉至雲端，對於 Microsoft 客戶來說，正變得越來越勢在必行。 供應鏈軟體套件通常會將標準設定為高，因為記憶體 I/O 具有單一計算節點驅動之混合讀取和寫入工作負載的強烈需求。 Azure 基礎結構與 Azure NetApp Files 結合，能夠符合此高需求工作負載的需求。 本文提供一個客戶如何符合此需求的範例，以及 Azure 如何符合重要 Oracle 工作負載的需求。

企業級 Oracle 效能

探索效能的上限時，請務必識別和減少可能會造成誤差結果的條件約束。 例如，如果意圖是證明記憶體系統的效能功能，則最好設定用戶端，讓 CPU 不會在達到記憶體效能限制之前變成緩和因素。 為此，測試從 E104ids_v5 實例類型開始，因為此 VM 不僅配備了 100 Gbps 網路介面，而且具有同樣大 （100 Gbps） 的輸出限制。

測試發生在兩個階段：

  1. 第一個階段著重於使用 Kevin Closson 的業界標準 SLOB2 （Silly Little Oracle Benchmark） 工具 - 2.5.4 版的測試。 目標是盡可能將 Oracle I/O 從一部虛擬機（VM） 驅動至多個 Azure NetApp Files 磁碟區，然後使用更多資料庫相應放大，以示範線性調整。
  2. 測試調整限制之後，我們的測試會轉向成本較低，但幾乎能夠E96ds_v5使用真正的供應鏈應用程式工作負載和真實世界數據進行測試的客戶階段。

SLOB2 相應增加效能

下列圖表會針對具有八個記憶體端點的八個 Azure NetApp Files 磁碟區，擷取單一E104ids_v5執行單一 Oracle 19c 資料庫的 Azure VM 效能配置檔。 磁碟區會分散到三個 ASM 磁碟群組：數據、記錄和封存。 已將五個磁碟區配置給數據磁碟群組、兩個磁碟區到記錄磁碟群組，另一個磁碟區則配置至封存磁碟群組。 本文中擷取的所有結果都是使用生產 Azure 區域和作用中的生產 Azure 服務所收集。

若要在多個記憶體端點上使用多個 Azure NetApp Files 磁碟區在 Azure 虛擬機上部署 Oracle，請使用 Oracle 的應用程式磁碟區群組。

單一主機架構

下圖描述已完成測試的架構;請注意，Oracle 資料庫分散到多個 Azure NetApp Files 磁碟區和端點。

具有 Azure NetApp Files 容量集區的 Oracle 子網圖表。

單一主機記憶體 IO

下圖顯示 100% 隨機選取的工作負載，且資料庫緩衝區命中率約為 8%。 SLOB2 每秒可驅動大約 850,000 個 I/O 要求，同時維護子百萬 DB 檔案循序讀取事件延遲。 資料庫區塊大小為 8K，相當於大約 6,800 MiB/秒的記憶體輸送量。

顯示單一主機隨機記憶體 I/O 的圖表。

單一主機輸送量

下圖示範，對於頻寬密集的循序 IO 工作負載，例如完整表掃描或 RMAN 活動，Azure NetApp Files 可以提供E104ids_v5 VM 本身的完整頻寬功能。

顯示單一主機循序輸送量的條形圖。

注意

由於計算實例在頻寬的理論上上限，因此新增額外的應用程式並行只會增加客戶端延遲。 這會導致 SLOB2 工作負載超過目標完成時間範圍，因此線程計數上限為 6。

SLOB2 向外延展效能

下列圖表會擷取三個E104ids_v5 Azure VM 的效能配置檔，每個 VM 分別執行單一 Oracle 19c 資料庫，以及各自的一組 Azure NetApp Files 磁碟區，以及相同的 ASM 磁碟群組配置，如相應增加效能一節中所述。 圖形顯示，使用 Azure NetApp Files 多磁碟區/多端點，效能可透過一致性和可預測性輕鬆地相應放大。

多主機架構

下圖描述已完成測試的架構;請注意，這三個 Oracle 資料庫分散於多個 Azure NetApp Files 磁碟區和端點。 端點可以專用於單一主機，如 Oracle VM 1 所示，或在主機之間共用，如 Oracle VM2 和 Oracle VM 3 所示。

Azure NetApp Files 的 Oracle 自動記憶體管理圖表。

多主機記憶體 IO

下圖顯示 100% 隨機選取的工作負載，且資料庫緩衝區命中率約為 8%。 SLOB2 能夠個別跨這三部主機每秒驅動大約 850,000 個 I/O 要求。 SLOB2 能夠完成這項作業，同時以大約 2,500,000 個 I/O 要求的集體方式執行，而每個主機仍會維護子百萬資料庫檔案循序讀取事件延遲。 資料庫區塊大小為8K，這相當於三部主機之間的大約20,000 MiB/秒。

從 IO 的觀點來看，集體隨機記憶體的折線圖。

多主機輸送量

下圖示範，針對循序工作負載，Azure NetApp Files 仍然可以提供E104ids_v5 VM 本身的完整頻寬功能，即使其向外延展也一樣。 SLOB2 能夠在平行執行時，跨三部主機驅動 I/O 總計超過 30,000 MiB/秒。

集體循序輸送量的堆疊條形圖。

真實世界效能

使用 SLOB2 測試調整限制之後，會使用針對 Azure NetApp 檔案上的 Oracle 使用真實文字供應鏈應用程式套件來執行測試，結果非常出色。 Oracle 自動工作負載存放庫 （AWR） 報告的下列資料會醒目提示查看一個特定關鍵作業的執行方式。

除了應用程式工作負載之外，此資料庫還有顯著的額外IO，因為已啟用快閃，且資料庫區塊大小為16k。 從 AWR 報告的 IO 配置檔區段，很明顯，相較於讀取，寫入比例很大。

- 每秒讀取和寫入數 每秒讀取數 每秒寫入數
總計 （MB） 4,988.1 1,395.2 3,592.9

儘管 db 檔案循序讀取等候事件顯示延遲高於 SLOB2 測試的 2.2 毫秒，但此客戶還是看到作業運行時間從 Exadata 上的 RAC 資料庫減少到 Azure 中的單一實例資料庫。

Azure 資源條件約束

所有系統最終都會達到資源限制，傳統上稱為窒息點。 資料庫工作負載，尤其是需求很高的工作負載，例如供應鏈應用程式套件，都是資源密集型實體。 找出這些資源條件約束並加以處理，對於任何成功的部署都至關重要。 本節說明您可能預期在這類環境中遇到的各種條件約束，以及如何加以處理。 在每個小節中，期望瞭解最佳做法和其背後的原理。

虛擬機器

本節詳細說明選取 VM 以獲得最佳效能的準則，以及針對測試所做的選擇背後的理由。 Azure NetApp Files 是網路連接 儲存體 （NAS） 服務，因此適當的網路頻寬大小調整對於最佳效能至關重要。

晶片組

感興趣的第一個主題是晶元組選擇。 請確定您選取的任何 VM SKU 都是建立在單一晶元組上，因為一致性原因。 E_v5 VM 的 Intel 變體會在第三代 Intel Xeon Platinum 8370C （Ice Lake） 設定上執行。 此系列中的所有 VM 都配備了單一 100 Gbps 網路介面。 相反地，以範例方式提及的E_v3系列是以四個不同的晶元組為基礎，具有各種實體網路頻寬。 E_v3系列中使用的四個晶元組（Broadwell、Skylake、Cascade Lake、Haswell）有不同的處理器速度，這會影響機器的效能特性。

請仔細閱讀 Azure 計算檔，注意晶片組選項。 另請參閱 Azure NetApp Files 的 Azure VM SKU 最佳做法。 選取具有單一晶元組的 VM 最好是最佳一致性。

可用的網路頻寬

請務必瞭解 VM 網路介面的可用頻寬與針對相同套用計量頻寬之間的差異。 當 Azure 計算文件說明網路頻寬限制時，這些限制只會套用至輸出（寫入）。 輸入（讀取）流量不會計量，因此只會受限於 NIC 本身的實體頻寬。 大部分 VM 的網路頻寬超過針對電腦套用的輸出限制。

當 Azure NetApp Files 磁碟區已連結網路時，可以了解輸出限制是特別針對寫入套用，而輸入則定義為讀取和類似讀取的工作負載。 雖然大部分計算機的輸出限制大於 NIC 的網路頻寬，但本文中所使用的E104_v5則不能說這一點。 E104_v5具有 100 Gbps NIC，輸出限制也設定為 100 Gbps。 相較之下，E96_v5，其 100 Gbps NIC 的輸出限制為 35 Gbps，且輸入未限製為 100 Gbps。 當 VM 大小減少時，輸出限制會減少，但輸入仍不受邏輯限制限制的限制。

輸出限制是全 VM，因此會針對所有網路型工作負載套用。 使用 Oracle Data Guard 時，所有寫入都會加倍至封存記錄，且必須納入輸出限制考慮。 如果使用多目的地和 RMAN 封存記錄，也是如此。 選取 VM 時，請熟悉這類命令行工具 ethtool，這會公開 NIC 的組態，因為 Azure 不會記錄網路介面組態。

網路並行

Azure VM 和 Azure NetApp Files 磁碟區配備了特定頻寬量。 如先前所示，只要 VM 有足夠的 CPU 前端空間，工作負載理論上就可以取用提供給它的頻寬，也就是在套用網路卡和或輸出限制的限制內。 不過，在實務上，可達成的輸送量量是以網路工作負載的並行性為依據，也就是網路流量和網路端點的數目。

若要進一步瞭解，請閱讀 VM 網路頻寬檔的網路流量限制一節。 外賣：將用戶端連線到記憶體的網路流程越多，潛在效能就越豐富。

Oracle 支援兩個不同的 NFS 用戶端：Kernel NFS 和 Direct NFS （dNFS）。 核心 NFS 直到遲到為止，都支援兩個端點之間的單一網路流程（計算 – 記憶體）。 兩者效能較快的 NFS 支援可變數目的網路流程 – 測試顯示每個端點有數百個唯一連線 - 隨著負載需求增加或減少。 由於兩個端點之間的網路流程調整，因此直接 NFS 遠優先於核心 NFS，因此建議的設定。 Azure NetApp Files 產品群組不建議搭配 Oracle 工作負載使用 Kernel NFS。 如需詳細資訊，請參閱 搭配 Oracle 資料庫使用 Azure NetApp Files 的優點。

執行並行

使用 Direct NFS，單一晶片組來保持一致性，並了解網路頻寬限制只會帶您到目前為止。 最後，應用程式會驅動效能。 使用 SLOB2 的概念證明，以及針對實際客戶數據使用真實供應鏈應用程式套件的概念證明，只能驅動大量的輸送量，因為應用程式以高度並行方式執行：前者使用每個架構大量的線程，後者則使用多個應用程式伺服器的多個連線。 簡言之，並行磁碟驅動器工作負載、低並行-低輸送量、高並行-高輸送量，只要基礎結構已就緒以支援相同。

加速網路

加速網路可以對 VM 啟用 Single Root I/O Virtualization (SR-IOV)，大幅提升其網路效能。 這個高效能路徑會略過資料路徑中的主機，進而減少延遲、抖動和 CPU 使用率，供支援的 VM 類型中最嚴苛的網路工作負載使用。 透過 terraform 或命令行等組態管理公用程式部署 VM 時，請注意，預設不會啟用加速網路功能。 為了獲得最佳效能，請啟用加速網路。 請注意，以網路介面為基礎，在網路介面上啟用或停用加速網路。 加速網路功能是可以動態啟用或停用的加速網路功能。

注意

本文包含 Microsoft 不再使用之詞彙 SLAVE的參考。 從軟體中移除該字詞時，我們也會將其從本文中移除。

NIC 會透過Linux終端機啟用隨後加速網路的權威方法。 如果已啟用 NIC 的加速網路功能，則第二個虛擬 NIC 會與第一個 NIC 相關聯。 第二個 NIC 是由已啟用 SLAVE 旗標的系統所設定。 如果沒有具有 旗標的 SLAVE NIC，就不會針對該介面啟用加速網路功能。

在設定多個 NIC 的案例中，您必須判斷哪個 SLAVE 介面與用來掛接 NFS 磁碟區的 NIC 相關聯。 將網路適配器新增至 VM 不會影響效能。

使用下列程式來識別已設定網路介面與其相關聯虛擬介面之間的對應。 此程式會驗證 Linux 機器上特定 NIC 是否已啟用加速網路功能，並顯示 NIC 可能達成的實體輸入速度。

  1. ip a執行命令：ip a 命令輸出的螢幕快照。
  2. /sys/class/net/列出您要驗證的 NIC 識別碼目錄（eth0在範例中為 ），並grep針對下一個字列出：
    ls /sys/class/net/eth0 | grep lower lower_eth1
  3. ethtool針對在上一個步驟中識別為較低裝置的乙太網路裝置執行 命令。 eth1 設定輸出的螢幕快照。

Azure VM：網路與磁碟頻寬限制

閱讀 Azure VM 效能限制檔時，需要一定程度的專業知識。 請注意：

  • 暫存記憶體輸送量和 IOPS 號碼是指直接連結至 VM 之暫時內部記憶體的效能功能。
  • 未快取的磁碟輸送量和 I/O 號碼特別是指 Azure 磁碟（進階版、進階版 v2 和 Ultra），且不會影響網路鏈接記憶體，例如 Azure NetApp Files。
  • 將其他 NIC 附加至 VM 不會影響 VM 的效能限制或效能功能（記載並測試為 true）。
  • 網路頻寬上限是指針對 VM 網路頻寬套用的輸出限制（也就是，涉及 Azure NetApp Files 時寫入）。 未套用任何輸入限制（也就是涉及 Azure NetApp Files 時讀取）。 假設有足夠的 CPU、足夠的網路並行和足夠豐富的端點，VM 理論上可以將輸入流量導向 NIC 的限制。 如可用網路頻寬一節中所述，請使用這類ethtool工具來查看 NIC 的頻寬。

範例圖表會顯示以供參考：

顯示範例圖表數據的數據表螢幕快照。

Azure NetApp Files

Azure 第一方記憶體服務 Azure NetApp Files 提供高可用性的完全受控記憶體解決方案，可支援稍早引進的需求 Oracle 工作負載。

據瞭解 Oracle 資料庫中相應增加記憶體效能的限制，本文刻意著重於向外延展記憶體效能。 相應放大記憶體效能意指讓單一 Oracle 實例存取許多 Azure NetApp Files 磁碟區，這些磁碟區會分散到多個記憶體端點。

藉由以這種方式跨多個磁碟區調整資料庫工作負載，資料庫效能會從磁碟區與端點上限取消系結。 隨著記憶體不再施加效能限制，VM 架構（CPU、NIC 和 VM 輸出限制）會成為競爭的扼流點。 如 VM 區 段中所述，選取E104ids_v5和E96ds_v5實例時，請記住這一點。

資料庫是放在單一大型容量磁碟區上，還是分散在多個較小的磁碟區上，總財務成本都相同。 相較於單一磁碟區和端點，將 I/O 分散到多個磁碟區和端點的優點是避免頻寬限制-您完全可以使用您支付的費用。

重要

若要在設定中使用 multiple volume:multiple endpoint Azure NetApp Files 進行部署，請連絡您的 Azure NetApp Files 專家或雲端解決方案架構師以取得協助。

Database

Oracle 的資料庫版本 19c 是 Oracle 目前的 長期發行 版本，也是用來產生本文所討論之所有測試結果的資料庫版本。

為了達到最佳效能，所有資料庫磁碟區都已使用 Direct NFS 掛接，因此建議針對核心 NFS，因為效能限制。 如需兩個用戶端之間的效能比較，請參閱 Azure NetApp Files 單一磁碟區上的 Oracle 資料庫效能。 請注意，所有相關的 dNFS 修補程式（Oracle 支援標識符1495104）都已套用，如同使用 Azure NetApp Files 報告在 Microsoft Azure 上的 Oracle 資料庫中所述的最佳做法。

雖然 Oracle 和 Azure NetApp Files 同時支援 NFSv3 和 NFSv4.1，因為 NFSv3 是較成熟的通訊協定，它通常被視為具有最穩定性，而且對於對中斷高度敏感的環境而言，是更可靠的選項。 本文所述的測試已全部透過NFSv3完成。

重要

支持標識碼1495104中的 Oracle 檔對於在使用 dNFS 時維護數據完整性而言非常重要的一些建議修補程式。 強烈建議針對生產環境應用這類修補程式。

NFS 磁碟區支援自動 儲存體 管理 （ASM）。 雖然通常與區塊式記憶體相關聯，其中 ASM 會取代邏輯磁碟區管理 （LVM） 和文件系統，但 ASM 在多磁碟區 NFS 案例中扮演了寶貴的角色，值得考慮。 ASM、新增和重新平衡新新增的 NFS 磁碟區和端點的動態在線新增和重新平衡等優點，可簡化管理，以便同時擴充效能和容量。 雖然 ASM 本身並未增加資料庫的效能，但其使用可避免經常性檔案，而且需要手動維護檔案散發-這是容易看到的優點。

透過 dNFS 設定的 ASM 可用來產生本文所討論的所有測試結果。 下圖說明 Azure NetApp Files 磁碟區內的 ASM 檔案配置，以及 ASM 磁碟群組的檔案配置。

使用 Azure NetApp Files 進行 Oracle 自動 儲存體 管理的圖表。

透過 Azure NetApp Files NFS 掛接的磁碟區使用 ASM 有一些限制，因為記憶體快照集可透過特定架構考慮加以克服。 請連絡 Azure NetApp Files 專家或雲端解決方案架構設計人員，以深入瞭解這些考慮。

綜合測試工具和 Tunables

本節說明特定項目的測試架構、Tunables 和組態詳細數據。 雖然上一節著重於設定決策的原因，但本節特別著重於設定決策的「內容」。

自動化部署

  • 資料庫 VM 是使用 GitHub 上提供的 bash 腳本來部署。
  • 手動完成多個 Azure NetApp Files 磁碟區和端點的配置。 您必須與 Azure NetApp Files 專家或雲端解決方案架構師合作，以取得協助。
  • 每部電腦上的方格安裝、ASM 組態、資料庫建立和設定，以及 SLOB2 環境都是使用 Ansible 來設定的一致性。
  • 多個主機之間的平行 SLOB2 測試執行也會使用 Ansible 來完成，以便一致性和同時執行。

VM 設定

組態 值
Azure 區域 西歐
VM SKU E104ids_v5
NIC 計數 1 注意：新增 vNIC 對係統計數沒有任何影響
輸出網路頻寬上限 （Mbps） 100,000
暫存儲存體 (SSD) GiB 3,800

系統設定

根據 Oracle 文件實作 19c 版的所有 Oracle 必要系統組態設定。

下列參數已新增至 /etc/sysctl.conf Linux系統檔案：

  • sunrpc.max_tcp_slot_table_entries: 128
  • sunrpc.tcp_slot_table_entries = 128

Azure NetApp Files

所有 Azure NetApp Files 磁碟區都已掛接下列 NFS 掛接選項。

nfs rw,hard,rsize=262144,wsize=262144,sec=sys,vers=3,tcp

資料庫參數

參數 值
db_cache_size 2g
large_pool_size 2g
pga_aggregate_target 3 g
pga_aggregate_limit 3 g
sga_target 25 克
shared_io_pool_size 500m
shared_pool_size 5g
db_files 500
filesystemio_options SETALL
job_queue_processes 0
db_flash_cache_size 0
_cursor_obsolete_threshold 130
_db_block_prefetch_limit 0
_db_block_prefetch_quota 0
_db_file_noncontig_mblock_read_count 0

SLOB2 組態

使用 SLOB2 工具 2.5.4 版完成測試的所有工作負載產生。

14 個 SLOB2 架構已載入標準 Oracle 資料表空間，並對其執行，其結合列出的 slob 組態檔設定，將 SLOB2 數據集放在 7 TiB。 下列設定會反映 SLOB2 的隨機讀取執行。 在循序測試期間，組態參數 SCAN_PCT=0 已變更為 SCAN_PCT=100 。

  • UPDATE_PCT=0
  • SCAN_PCT=0
  • RUN_TIME=600
  • SCALE=450G
  • SCAN_TABLE_SZ=50G
  • WORK_UNIT=32
  • REDO_STRESS=LITE
  • THREADS_PER_SCHEMA=1
  • DATABASE_STATISTICS_TYPE=awr

針對隨機讀取測試，已執行九個 SLOB2 執行。 每次測試反覆專案從一個開始，線程計數都會增加六個。

針對循序測試，已執行七個 SLOB2 執行。 每次測試反覆專案從一個開始，線程計數都會增加兩個。 線程計數上限為六，因為達到網路頻寬上限。

AWR 計量

所有效能計量都是透過 Oracle 自動工作負載存放庫報告（AWR）。 以下是結果中顯示的計量：

  • 輸送量：AWR 負載配置檔區段中的平均讀取輸送量和寫入輸送量總和
  • AWR 負載配置檔區段中的平均讀取 IO 要求
  • DB 檔案循序讀取等候事件平均等候時間來自 AWR Foreground Wait Events 區段

從用途建置的工程系統移轉至雲端

Oracle Exadata 是一種經過工程的系統，其結合硬體和軟體被認為是執行 Oracle 工作負載的最優化解決方案。 雖然雲端在技術世界的整體配置中具有顯著優勢，但這些特製化系統對於閱讀和檢視 Oracle 在其特定工作負載周圍建置的優化人員看起來非常有吸引力。

在 Exadata 上執行 Oracle 時，選擇 Exadata 有一些常見原因：

  • 1-2 個自然適合 Exadata 功能的高 IO 工作負載，因為這些工作負載需要大量的 Exadata 工程功能，因此執行的資料庫其餘部分會合併到 Exadata。
  • 需要 RAC 調整且難以使用專屬硬體來建構複雜或困難的 OLTP 工作負載，而不需要深入瞭解 Oracle 優化，或是無法優化技術債務。
  • 使用不足的現有 Exadata 與各種工作負載：這可能是因為先前的移轉、先前 Exadata 的生命週期結束，或是因為想要在內部工作/測試 Exadata。

從 Exadata 系統的任何移轉，都必須從工作負載的觀點瞭解，以及移轉的簡單或複雜程度。 次要需求是從狀態觀點瞭解 Exadata 購買的原因。 Exadata 和 RAC 技能的需求較高，可能已推動技術專案關係人購買其中一項的建議。

重要

無論案例為何，對於來自 Exadata 的任何資料庫工作負載而言，使用 Exadata 的專屬功能越多，移轉和規劃就越複雜。 未大量使用 Exadata 專屬功能的環境有機會進行更簡單的移轉和規劃程式。

有數個工具可用來評估這些工作負載機會：

  • 自動工作負載存放庫 （AWR）：
    • 所有 Exadata 資料庫都獲得授權，可使用 AWR 報告和連線的效能和診斷功能。
    • 一律開啟並收集可用來檢視歷程記錄工作負載資訊及評估使用量的數據。 尖峰值可以評估系統上的高使用量，
    • 較大的視窗 AWR 報告可以評估整體工作負載，提供對功能使用量的寶貴見解，以及如何有效地將工作負載移轉至非 Exadata。 相反地，尖峰 AWR 報告最適合效能優化和疑難解答。
  • Exadata 的全域 （RAC 感知） AWR 報告也包含 Exadata 特定區段，其向下切入至特定的 Exadata 功能使用方式，並提供寶貴的深入解析資訊快取、快閃記錄、IO 和其他資料庫和數據格節點的功能使用方式。

與 Exadata 分離

識別要遷移至雲端的 Oracle Exadata 工作負載時，請考慮下列問題和數據點：

  • 工作負載是否在硬體優點之外耗用多個 Exadata 功能？
    • 智能掃描
    • 儲存體 索引
    • 快閃快取
    • 快閃記錄
    • 混合式單欄式壓縮
  • 工作負載是否使用 Exadata 卸除有效率？ 在最上層時間前景事件中，使用下列專案，工作負載的比例 （超過 10% 的 DB 時間） ：
    • 儲存格智慧型表格掃描（最佳）
    • 儲存格多重封鎖實體讀取 （較不理想）
    • 儲存格單一區塊實體讀取（最不理想）
  • 混合式單欄式壓縮 （HCC/EHCC）：壓縮與未壓縮的比例為何：
    • 資料庫在壓縮和解壓縮數據時花費超過 10% 的資料庫時間嗎？
    • 在查詢中使用壓縮來檢查述詞的效能提升：值是否值得，而不是使用壓縮所儲存的數量？
  • 資料格實體 IO：檢查下列專案所提供的節省：
    • 導向至 DB 節點以平衡 CPU 的數量。
    • 識別智慧掃描傳回的位元組數目。 這些值可以在 IO 中減去，一旦從 Exadata 移轉，數據格單一區塊實體讀取的百分比。
  • 請注意從快取讀取的邏輯數目。 判斷工作負載的雲端 IaaS 解決方案中是否需要快取快取。
  • 比較實體讀取和寫入總位元組數與快取中執行的總計。 可以引發記憶體來消除實體讀取需求（有些人通常會縮小 SGA 以強制卸除 Exadata）嗎？
  • 在 [系統統計數據] 中，識別哪些物件受到哪些統計數據的影響。 如果微調 SQL，進一步編製索引、分割或其他實體微調可能會大幅優化工作負載。
  • 檢查 初始化參數 是否有底線 （_） 或已被取代的參數，因為資料庫層級對效能造成的影響，因此應該合理。

Exadata 伺服器組態

在 Oracle 12.2 版和更新版本中，AWR 全域報表中將會包含 Exadata 特定新增專案。 此報表有區段，可提供從 Exadata 移轉的特殊價值。

  • Exadata 版本和系統詳細數據

  • 數據格節點警示詳細數據

  • Exadata 非在線磁碟

  • 任何 Exadata OS 統計數據的極端數據

    • 黃色/粉紅色：令人擔心。 Exadata 未以最佳方式執行。

    • 紅色：Exadata 效能會大幅受到影響。

    • Exadata OS CPU 統計數據：頂端數據格

      • 這些統計數據是由數據格上的OS所收集，而且不限於此資料庫或實例
      • v和深黃色背景表示低於低範圍的極端值
      • ^和淺黃色背景表示高於高範圍的極端值
      • 依 CPU 百分比排列的頂端數據格會顯示，並以百分比 CPU 的遞減順序排列
      • 平均：39.34% CPU、28.57% 使用者、10.77% sys

      數據表的螢幕快照，其中依CPU百分比顯示頂端儲存格。

  • 單一儲存格實體區塊讀取

  • 快取使用量

  • 暫存IO

  • 單欄快取效率

依 IO 輸送量排序的前一個資料庫

雖然可以執行重設大小評估，但對於大型工作負載，有一些關於平均值和模擬尖峰的相關問題。 本節位於 AWR 報表結尾處，非常有價值，因為它會顯示 Exadata 上前 10 個資料庫的平均快閃和磁碟使用量。 雖然許多人可能假設他們想要調整資料庫的大小，以達到雲端的尖峰效能，但對於大多數部署來說，這並不合理（超過95%是平均範圍;仿真的尖峰計算在內，平均範圍大於98%）。 請務必支付所需的費用，即使是 Oracle 需求最高的工作負載，以及檢查 IO 輸送量 最高的資料庫，也可以啟發瞭解資料庫的資源需求。

在 Exadata 上使用 AWR 調整 Oracle 大小

針對內部部署系統執行容量規劃時，只有硬體內建大量額外負荷才很自然。 無論因數據成長、程式代碼變更或升級而新增的工作負載，過度布建的硬體都必須在未來幾年內為 Oracle 工作負載提供服務。

雲端的優點之一是調整 VM 主機中的資源，而且記憶體可以隨著需求增加而執行。 這有助於節省附加至處理器使用量的雲端成本和授權成本（與 Oracle 相關）。

適當重設大小牽涉到從傳統的隨即轉移移轉中移除硬體，並使用 Oracle 自動工作負載存放庫 （AWR） 所提供的工作負載資訊，將工作負載隨即轉移至專為在客戶選擇的雲端中支援它而設計的計算和記憶體。 正確的重設大小程式可確保未來架構會移除基礎結構技術債務、如果內部部署系統重複復寫到雲端，並盡可能實作雲端服務，則會發生的架構備援。

Microsoft Oracle 主題專家估計，超過 80% 的 Oracle 資料庫已過度布建，如果移轉至雲端之前，需要時間來調整 Oracle 資料庫工作負載的大小，就會節省相同的成本或節省成本。 此評估需要小組的資料庫專家來改變他們過去可能執行容量規劃的方式的思維，但值得項目關係人對雲端和企業雲端策略的投資。

下一步