共用方式為

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

  • 發行項

對於 Microsoft 客戶來說，將高效能的 Exadata 等級資料庫移轉至雲端逐漸變得勢在必行。 由於單一計算節點驅動的混合讀寫工作負載對儲存體 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 版進行測試。 目標是盡可能驅動從一部虛擬機(VM) 對多個 Azure NetApp Files 磁碟區的 Oracle I/O，接著使用更多資料庫向外延展以展示線性縮放。
  2. 在測試縮放限制後，我們的測試會轉向成本較低但功能幾乎相當的 E96ds_v5，使用真正的供應鏈應用程式工作負載和現實資料進行客戶階段測試。

SLOB2 擴增效能

下列圖表會展示單一 E104ids_v5 Azure VM 的效能分析，其執行單一 Oracle 19c 資料庫，並連接至具有八個儲存體端點的八個 Azure NetApp Files 磁碟區。 磁碟區會分散至三個 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 要求，同時保持亞毫秒級的資料庫檔案循序讀取事件延遲。 資料庫區塊大小為 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 可在平行執行的情況下，驅動三部主機總計超過 30,000 MiB/秒的 I/O。

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

現實效能

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

除了應用程式工作負載之外，此資料庫還有顯著的額外 IO，因為已啟用快閃回復，且資料庫區塊大小為 16k。 在 AWR 報告的 IO 設定檔區段可明顯看到，相較於讀取，寫入的佔比更高。

- 每秒讀取和寫入 每秒讀取 每秒寫入
總計 (MB) 4,988.1 1,395.2 3,592.9

雖然資料庫檔案循序讀取等候事件顯示延遲高於 SLOB2 測試的 2.2 毫秒，但此客戶還是看到作業運行時間從 Exadata 上的 RAC 資料庫對於 Azure 中單一執行個體資料庫的作業執行時間降低 15 分鐘。

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 的封存記錄也是如此。 由於 Azure 不會記錄網路介面組態，在挑選 VM 時，請熟悉 ethtool 這類命令列工具，這些工具會公開 NIC 的組態。

網路並行

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

若想進一步了解，請參閱 VM 網路頻寬文件的網路流量限制一節。 重點：用戶端連線到儲存體的網路流越多，潛在效能就越充沛。

Oracle 支援兩個不同的 NFS 用戶端：Kernel NFS 和 Direct NFS (dNFS)。 核心 NFS 在最近開始支援兩個端點之間的單一網路流程 (計算 – 儲存體)。 Direct NFS (兩者中效能較快) 支援可變數目的網路流 (測試顯示每個端點有數百個唯一連線)，可隨著負載需求增加或減少。 有鑑於兩個端點之間的網路流調整功能，強烈推薦採用 Direct NFS 組態，而非使用 Kernel NFS。 Azure NetApp Files 產品群組不建議使用 Kernel NFS 搭配 Oracle 工作負載。 如需詳細資訊，請參閱使用 Azure NetApp Files 搭配 Oracle Database 的優點。

執行並行

使用 Direct NFS、採用單一晶片組保持一致性，並了解網路頻寬限制能為您提供幫助仍然有限。 效能驅動最終取決於應用程式。 使用 SLOB2 的概念證明，以及針對實際客戶資料使用真實供應鏈應用程式套件的概念證明，之所以能驅動大量的輸送量，是因為應用程式採用高度並行的執行方式：前者的每個結構描述使用大量的執行緒，後者則使用多個應用程式伺服器的多個連線。 換句話說，在基礎結構提供相同支援的情況下，並行數會決定驅動的工作負載、低並行則低輸送量、高並行則高輸送量。

加速網路

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

注意

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

確保 NIC 啟用加速網路的可靠方法是透過 Linux 終端機。 如果已啟用 NIC 的加速網路功能，則第二個虛擬 NIC 會關聯至第一個 NIC。 第二個 NIC 會由系統設定，並啟用 SLAVE 旗標。 如果沒有具有 SLAVE 旗標的 NIC，則該介面不會啟用加速網路功能。

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

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

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

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

閱讀 Azure VM 效能限制文件需要一定程度的專業知識。 注意事項：

  • 暫存儲存體輸送量和 IOPS 數是指直接連結至 VM 暫時內部儲存體的效能。
  • 未快取的磁碟輸送量和 I/O 數是特指 Azure 磁碟 (進階、進階 v2 和 Ultra)，且不會影響網路連結儲存體，例如 Azure NetApp Files。
  • 為 VM 連結其他 NIC 不會影響 VM 的效能限制或效能功能 (已經記載及測試證實)。
  • 網路頻寬上限是指對 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 掛接，由於效能限制，建議不要使用 Kernel NFS。 如需兩種用戶端之間的效能比較，請參閱 Azure NetApp Files 單一磁碟區上的 Oracle 資料庫效能。 請注意，所有相關的 dNFS 修補程式(Oracle 支援識別碼 1495104) 都已套用，如同在 Microsoft Azure 上使用 Azure NetApp Files 報告的 Oracle 資料庫中所述的最佳做法。

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

重要

Oracle 文件在支援識別碼 1495104 提供的一些建議修補程式，對於在使用 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 專家或雲端解決方案架構師以深入了解這些考量事項。

綜合測試工具和可調參數

本節說明測試架構、可調參數和組態的具體詳細資料。 上一節著重於設定決策的原因，而本節將特別著重於設定決策的「內容」。

自動化部署

  • 資料庫 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 3g
pga_aggregate_limit 3g
sga_target 25g
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 版產生。

標準 Oracle 資料表空間已載入 14 個 SLOB2 架構並執行，搭配列出的 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 要求
  • 「AWR 前景等待事件」區段的資料庫檔案循序讀取等候事件平均等候時間

從為專門用途設計的系統移轉至雲端

Oracle Exadata 是一種經過設計調整的系統，結合硬體和軟體，被視為是執行 Oracle 工作負載最佳化解決方案。 雖然雲端在技術領域的各種方案中具有明顯優勢，但對於那些閱讀並查看過 Oracle 根據其特定工作負載建構最佳化功能的人員來說，這些專用系統看起來非常有吸引力。

在 Exadata 上執行 Oracle 時，選擇 Exadata 的常見原因包括：

  • 1-2 個原生適用於 Exadata 功能的高 IO 工作負載，由於這些工作負載需要大量的 Exadata 工程設計功能，因此與其一同執行的其餘資料庫已合併到 Exadata。
  • 複雜或困難的 OLTP 工作負載需要 RAC 進行擴展，且在未具備 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% 的資料庫時間)：
    • 儲存格智慧型資料表掃描 (最佳)
    • 儲存格多重封鎖實體讀取 (較不理想)
    • 儲存格單一區塊實體讀取 (最不理想)
  • 混合式分欄壓縮 (HCC/EHCC)：壓縮與未壓縮的比例為何：
    • 資料庫在壓縮和解壓縮資料的費時有超過 10% 的資料庫時間嗎？
    • 在查詢中使用壓縮來檢查述詞的效能提升：相較於壓縮節省的數量，獲得的價值是否值得？
  • 儲存格實體 IO：檢查下列功能所提供的節省：
    • 導向至資料庫節點以平衡 CPU 的數量。
    • 識別智慧型掃描傳回的位元組數目。 從 Exadata 移轉出來後，即可在 IO 中減去這些值，以獲得儲存格區塊實體讀取的百分比。
  • 請注意從快取讀取的邏輯數目。 判斷工作負載的雲端 IaaS 解決方案是否需要快閃快取。
  • 將實體讀取和寫入總位元組數與快取中執行的總計進行比較。 是否能提高記憶體以消除物理讀取需求 (有些人會習慣縮小 SGA 以強制卸除 Exadata)？
  • 在 [系統統計資料] 中，識別哪些物件受到哪些統計資料的影響。 如果微調 SQL、進一步編製索引、分割或其他實體微調可能會大幅最佳化工作負載。
  • 檢查 [初始化參數] 是否有底線 (_) 或已取代的參數，由於其可能對資料庫層級造成效能影響，因此應該進行調整。

Exadata 伺服器組態

在 Oracle 12.2 版和更新版本中，AWR 全域報表中將會包含 Exadata 特定新增項目。 此報表包含對於移轉自 Exadata 特別實用的區段。

  • Exadata 版本和系統詳細資料

  • 儲存格節點警示詳細資料

  • Exadata 非線上磁碟

  • 任何 Exadata OS 統計資料的極端值資料

    • 黃色/粉紅色：需要注意。 Exadata 未以最佳方式執行。

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

    • Exadata OS CPU 統計資料：熱門儲存格

      • 這些統計資料是由儲存格上的作業系統所收集，而且不限於此資料庫或執行個體
      • 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 資料庫工作負載的大小，便有機會節省移轉到雲端的成本。 此評量要求團隊中的資料庫專家改變自己過去執行容量規劃的思維方式，但可提升專案關係人對雲端和企業雲端策略的投資價值。

下一步