3. 数据库工作负载分析

为数据库设计 ONTAP 存储，第一步不是选盘或配 RAID，而是把数据库真实的 I/O 行为量化出来。数据库工作负载分析的目标，是把"业务卡顿"这类模糊感受，转换成 IOPS、吞吐量、延迟、读写比例、队列深度这五个可测量、可比较、可建模的指标。只有拿到这些数字，才能判断该用 AFF 全闪还是 FAS 混合、该配多少块盘、该不该开压缩与去重、卷的 QoS 上限设多少。

五个核心指标分别说明什么

IOPS（每秒 I/O 次数）衡量单位时间内完成的读写请求数量，反映存储控制器和磁盘的"处理频次"能力。数据库的 IOPS 通常由小随机 I/O 主导，例如 OLTP 的 8 KB 随机读、redo 的顺序写。注意 IOPS 必须与块大小绑定才有意义——同样是 50000 IOPS，8 KB 与 64 KB 对后端带宽的压力相差 8 倍。

吞吐量（MB/s）衡量单位时间传输的数据量，等于 IOPS × 平均块大小。数据仓库的全表扫描、备份、日志归档属于大块顺序 I/O，吞吐量是主要瓶颈；而 OLTP 往往 IOPS 高、吞吐量低。

延迟（ms）是单个 I/O 从提交到完成的时间，是用户体验最直接的指标。ONTAP 中要区分几个层次：应用侧端到端延迟、卷/ LUN 的读延迟与写延迟、以及节点内部的处理延迟。写延迟还受 NVRAM 与写合并影响，通常低于读延迟。

读写比例决定缓存命中率与后端负载结构。读多写少（如 90:10）的工作负载能从 ONTAP 读缓存中获益明显；写密集（如 50:50 或更高）则更依赖 NVRAM 与写优化，且对快照、SnapMirror 的带宽占用更敏感。

队列深度（Queue Depth）是同一时刻未完成的 I/O 请求数，反映并发压力。队列深度上升而 IOPS 不再增长，说明已达到设备饱和点，此时延迟会急剧上升——这就是判断"是否过载"的关键拐点。

采集方式与工具选择

ONTAP 侧最直接的采集工具是 statit，它按秒级采样卷、LUN、聚合的 IOPS、吞吐量、延迟与队列深度。典型用法是先启动采集，运行一段时间后停止并生成报告：

# 在 ONTAP 集群 CLI 上采集 60 秒
statit -b
# 等待 60 秒后
statit -e /vol/vol_db/statit_db.txt

# 查看卷级实时指标
statistics show -object volume -instance vol_db \
  -counter read_ops,write_ops,read_latency,write_latency \
  -interval 5

对于长期趋势，应使用 Active IQ Unified Manager 或 ONTAP REST API 按 5 分钟粒度持续采集，避免只靠一次 statit 快照下结论。数据库侧则要同步取 Oracle AWR、SQL Server DMV 或 MySQL performance_schema 的 I/O 统计，两边对照才能定位瓶颈在存储还是在数据库层。

如何解读：从数字到判断

拿到指标后，关键不是看绝对值，而是看它们之间的关系。第一，把 IOPS 与块大小相乘得到吞吐量，验证是否与实测吞吐量一致；若不一致，说明存在大量小块 I/O 或元数据操作。第二，观察队列深度与延迟的曲线：当队列深度从 8 升到 32 而 IOPS 几乎不变、延迟却从 1 ms 升到 8 ms，说明后端已饱和，此时加盘或换全闪比调数据库参数更有效。第三，区分读延迟与写延迟：读延迟高通常意味着缓存命中率低或后端盘寻道多；写延迟高则要检查 NVRAM 是否成为瓶颈或快照是否过于频繁。

读写比例同样影响设计。若实测读:写为 85:15，且读以 8 KB 随机为主，那么 ONTAP 的读缓存能覆盖大部分热点，后端压力较小；若写比例超过 40%，就要重点评估 NVRAM 容量、写合并效率以及 SnapMirror 复制对带宽的额外占用。

一个可复用的采集记录表

为了让分析可比较、可追溯，建议按下面的字段记录每次采集结果。表中数值为示例，实际应以现场采集为准。

把上述五维指标采集清楚、判读准确，后续的磁盘选型、聚合规划、QoS 策略和缓存配置才有依据。工作负载分析不是一次性动作，而应在业务变化、版本升级或容量扩展后重新执行，形成持续校准的闭环。