在 Bare Metal 解決方案中調整 Oracle 效能

目標

本文件提供使用 Oracle 專用的 Bare Metal 解決方案時，如何處理效能相關問題的指南。

步驟 1：收集診斷資料

盡可能詳細瞭解問題。請盡可能收集相關資訊，包括：

  • 資料庫環境資訊 - 機器 ID/IP、資料中心位置、Oracle 環境詳細資料等等
  • 問題說明，包括時間軸。
  • 影響程度：例如，問題是否只影響單一工作階段或伺服器，或是一組相關工作階段和伺服器，或是資料庫的所有使用者？
  • 說明目前的調查進度。是否有任何因應做法？
  • 問題是否會隨時重現？如果是，請說明詳細情況。
  • 是否有任何可用來比較的良好基準資料？
  • 資料庫、主機、網路、儲存空間或應用程式層的設定最近是否有任何變更，包括工作負載的任何變更？
  • 收集所有相關記錄和追蹤記錄，包括 ASH、AWR、警示記錄、追蹤檔案和 TFA/OS 監控器記錄。
# TFA command to generate a bundled package containing files like
# the AWR report, ADDM report, ASH report, OSWatcher and ORAchk performance
# related checks.

tfactl diagcollect -srdc dbperf

步驟 2：分析並建立推薦內容

您可以根據上述收集到的資料，略過這裡的部分部分。

2.1 資料庫主機健康狀態

建議您先對資料庫主機執行快速健康狀態檢查。您應該可以使用 TFA/OSWatcher 檔案來查看問題期間的資料。您基本上會在這裡尋找資源飽和、使用率和/或錯誤的跡象。您也可以使用 BMS Infrascope，透過機器 ID、LUN ID 等資訊，深入瞭解環境。

2.2.1 系統記錄

  • /var/log/messages 或 dmesg 可用於找出系統在儲存空間和網路層級的潛在問題。

    # System messages

cat /var/log/messages
Or
dmesg -T

2.2.2 CPU

  • 您可以使用「uptime」/「top」查看過去 1/5/15 分鐘的系統負載平均值。查看這些數字時，請考量 CPU 核心數量。在 Linux 上，這些數字包括 CPU 上/等待 CPU 的程序數量，以及不可中斷的睡眠狀態(通常是磁碟 I/O) 中的程序數量。以下提供一些實用指令。

    # To find load average

"w"
Or
"uptime"
Or
"top"

[root@svr001 ~]# uptime
 21:32:09 up 12 days,  1:04,  3 users,  load average: 0.31, 0.44, 0.64

# To find CPU Usage over time

"sar -u 5"

[root@svr001 ~]# sar -u 5
Linux 4.14.35-2025.401.4.el7uek.x86_64 (svr001)      12/16/2020           _x86_64_        (16 CPU)
09:52:20 PM     CPU     %user     %nice   %system   %iowait    %steal     %idle
09:52:25 PM     all      0.63      0.00      0.73      0.11      0.00     98.52
09:52:30 PM     all      1.10      0.00      0.82      0.15      0.00     97.93

# To list the no. of processes in Runnable (R) and in Uninterruptible sleep (D) states

"ps -eo s,user,cmd | grep ^[RD] | sort | uniq -c | sort -nbr | head -20"

2.2.3 記憶體

  • 使用「free」找出「可用」的記憶體空間，正常運作的系統應有足夠的空間。

    # Find system memory usage

"free -m"

[root@svr001 ~]# free -m
              total       used       free        shared      buff/cache  available
Mem:         385423       16603      188217      153744      180602      211778
Swap:         16383           0       16383

  • 您可以使用「vmstat」查看換頁統計資料 (si、so)。正常系統的值應為零。也提供其他有趣的資料欄，可用於 procs/memory/cpu 等，視問題而定。

    # Virtual Mem stats 5 snapshots 5 secs apart

"vmstat 5 5"

[root@svr001 ~]# vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r  b   swpd   free   buff  cache         si   so    bi    bo   in   cs   us sy id wa st
1  0      0 192717472 497132 184439376    0    0    82    35    2    0    1  1 98  0  0
1  0      0 192717520 497132 184439616    0    0  3225   719 15118 29594  1  1 98  0  0

  • 如果尚未啟用 hugepages，請考慮啟用，以便充分利用較大的頁面大小，並在系統記憶體中鎖定 SGA。

    • 在 awr 報表的 init.ora 部分 (use_large_pages 設為 only) 或 alert.log 的執行個體啟動部分中，確認 hugepage 用量。
    • 不使用 hugepages 也可能導致系統換頁，並且每個與資料庫的連線都會使用更多記憶體。

2.2.4 儲存空間

  • 您可以使用「iostat」查看區塊裝置統計資料，例如 await、avgqu-sz、%util，這些資料可能會指出儲存空間已達飽和狀態、效能不佳等。

    # IO Stats with extended per-disk statistics

"iostat -x 5 5"
Or
"sar -dp"

# For devices with 90% utilization and above

"sar -dp | awk '/%util/ || ($11 > 90)'"

[root@svr001 ~]# iostat -x 5 5
Linux 4.14.35-2025.401.4.el7uek.x86_64 (svr001)      12/16/2020      _x86_64_        (16 CPU)
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
       1.05    0.01    0.77    0.09    0.00   98.08
Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sde               0.00     0.00    0.17    0.83     7.10    20.12    54.46     0.04   41.10   18.91   45.57   1.12   0.11
sdf               0.00     0.00    0.00    0.00     0.00     0.00    43.50     0.00    1.03    1.03    0.00   0.75   0.00
sdc               0.00     0.00    0.00    0.00     0.00     0.00    40.15     0.00    0.40    0.40    0.00   0.22   0.00
sda               0.00     0.00    1.16   20.80     7.76   177.15    16.84     0.02    0.82    0.73    0.83   0.14   0.31
sdd               0.00     0.00   43.24    8.03   639.16    97.67    28.75     0.01    0.20    0.18    0.31   0.18   0.92

  • 如果您發現 IO 飽和，以下是一些不錯的起點：

    • SSD 磁碟區塊的 IOPS 數量 (8K 區塊) 的 QOS 為每 TB 6,000。Google 不會為 HDD 提供 QoS。請使用這些數字設定正確的預期值。
    • 如果您沒有看到上述預期的服務品質，下一步可以確認您是否已遵循儲存空間設定的最佳做法。

    • 每個 BMS 伺服器都有 4 個 NIC (每個 25 Gbps)，並使用 802.3ad 動態連結匯集 (active-active) 技術，與兩個 50 Gb NIC 綁定。

      # Interface Transfer Speed
# bond0 is the primary interface in this case.

[root@svr001 ~]# ethtool bond0 | grep -i speed
Speed: 50000Mb/s

      這表示 ( 50000Mb/s = 6250MB/s = 6,400,000KB/s) 是主要網路介面的飽和點。

      # Interface stats

"sar -n DEV | head -3 && sar -n DEV | grep bond0"

[root@svr001 ~]# sar -n DEV | head -3 && sar -n DEV | grep bond0
12:00:01 AM     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
12:10:01 AM bond0.118     87.30     49.94     69.45     24.93      0.00      0.00      0.00
12:10:01 AM     bond0     89.31     52.26     71.58     25.59      0.00      0.00      2.00
12:20:01 AM bond0.118     21.91     13.21     18.92      8.02      0.00      0.00      0.00
12:20:01 AM     bond0     23.94     15.55     19.65      8.39      0.00      0.00      2.00

  • 使用 ping、traceroute、tnsping 等常見工具，找出可能的網路問題，例如使用者/應用程式機器與資料庫伺服器之間的封包遺失/延遲。詳情請參閱這個教學課程。

    # Quick check for 9000 mtu.
# If not configured correctly, we will see "Message too long" errors

ping -c 5 -s 8972 -M do <IP>

  • 查看 awr 報表中的互連統計資料，並與良好基準進行比較，以及使用「netstat -s」指令 (IP 統計資料計數器) 找出分割/重組失敗、緩衝區溢位問題等，這些都能提供私人網路健康狀態的線索。

    
# Interface errors:

[root@svr001 ~]netstat -s |
egrep       "IP|Ip|ip:|TCP|Tcp|tcp:|UDP|Udp|udp:|ICMP|Icmp|icmp:|IGMP|igmp:|icmpv6:|ipv6:|drop|Drop|dropped|Dropped|error|Error|discard|Discard|timeout|Timeout|fail|Fail|Receive|receive"

Ip:
168848352 total packets received
0 incoming packets discarded
701 outgoing packets dropped
3265322 fragments received ok

2.3 資料庫健康狀態

您現在已瞭解整體系統健康狀態，並做出實用的觀察，因此可以進一步查看資料庫層。視問題性質而定，請務必收集所有相關報表 (AWR、ASH 等) 和記錄檔 (tfa、警示記錄、追蹤記錄等)，以利診斷問題。

在 AWR 報表中，您可以查看以下幾個重點：

  • 報表頂端

    • 環境摘要會提供 Oracle s/w 資訊、主機資訊 (例如核心、記憶體、經過時間與資料庫時間等) 的相關資訊。
    • 負載設定檔會提供資料庫時間與資料庫 CPU、剖析統計資料、I/O 統計資料等資訊。
    • DB 時間 = DB CPU + 等待時間 + 等待 CPU (執行佇列)
    • DB CPU = CPU 執行時間 (不含執行佇列)
    • 平均活躍工作階段 = db 時間 / 經過時間
    • db cpu per second / (num_cpus * elapsed seconds) 可提供資料庫 CPU 飽和度的相關資訊

  • Init.ora

    • 請在這裡找出任何可能會觸發的參數 (底線、資料保護相關等)。

  • 前景定時事件

    • 調查資料庫時間分配，找出最有可能改善的部分。
    • 請查看該部分顯示的等待時間，以及 DBTime%、等待時間類別、平均時間等效能特徵。
    • 視這個部分顯示的事件而定，我們可能會進一步深入分析 AWR 報表的其他部分。

  • 時間模型統計資料

    • 在本節中，您可以查看一些重要的統計資料，包括解析相關、背景 CPU 時間、SQL 執行經過時間、資料庫 CPU。
    • 一般來說，SQL 處理時間越長，剖析時間越短越好。如果 SQL 執行經過的時間比資料庫 CPU 還要高，可能表示 I/O 等待時間過長。

  • 同步處理記錄檔：

    • 記錄檔案同步問題可能源自於基礎結構問題，也可能源自於應用程式設計。以下提供幾項準則，可用來判斷是否為基礎架構降級導致等待事件。
      • 如果涉及資料保護，本機儲存空間、遠端儲存空間和/或網路效能不佳，都可能導致記錄檔同步作業失敗。
      • 記錄檔平行寫入效能是本機儲存空間存在延遲的良好指標，這會直接影響記錄檔同步處理效能。您可以查看等待事件直方圖，並與良好基準比較，找出最近的變化。一般來說，寫入磁碟的最佳時間應接近 10 毫秒。
      • 設定最高可用性/防護資料防護功能也是造成這項問題的另一個原因。您可以查看資料保護相關的等待時間，而相關的直方圖可協助指出備用站點的網路延遲和/或 I/O 問題。
      • 另一個原因是由於提交次數過多或 CPU 飢餓，導致 lgwr 處於忙碌狀態。請檢查「背景 CPU 時間」統計資料，確認這不是資料庫時間的大部分。

  • Cloud Storage 相關等待時間：

    • 除了建議調整會造成大量通訊的應用程式或熱點問題之外，您也應檢查並排除可能的連結效能瓶頸。
    • GLOBAL CACHE BLOCKS LOST/CORRUPT 應盡可能趨近於零。
      • LOST - 在轉移期間阻止損失。可能表示網路發生問題
      • CORRUPT：高值表示 IPC、網路或硬體問題。
  • 網路疑難排解： 連結
  • Oracle 效能調整指南：連結