新手onstat 尝鲜记

作为一名新手 DBA，当你第一次面对数据库卡顿、业务报错、领导催命的三重夹击时，手里如果没有趁手的诊断工具，就像医生没有听诊器、电工没有万用表——完全无从下手。

今天，我们就来认识两位数据库界的"听诊器"：Informix/GBase 8s 家族的 onstat，和 DB2 家族的 db2pd。它们名字不同、语法不同，但骨子里却是"亲兄弟"。搞懂它们的共通逻辑，你就掌握了数据库急救的通用心法。

---

一、先搞清楚：它们到底是干嘛的？

想象你的数据库是一个繁忙的工厂：

• SQL 查询是工厂的生产流水线
• 缓冲池是仓库
• 锁是仓库门口的门禁
• 日志是工厂的账本

当工厂运转正常时，你可以通过 SQL 语句（比如 select * from sysmaster 或 db2 "select ..."）去查看生产情况。但如果工厂本身已经卡死了——流水线停工、仓库门被反锁、账本翻不开——你再去走流水线查问题，只会一起卡住。

这时候就需要 onstat 和 db2pd 登场了。

它们不走 SQL 流水线，而是直接翻墙进入工厂的控制室，读取数据库引擎放在共享内存里的"实时监控大屏"。即使数据库忙到连 SQL 都执行不了，它们也能瞬间告诉你：现在到底卡在哪儿了？

这就是两者的第一个共同点：绕过 SQL，直读内存，快、准、狠。

---

二、新手最常用的"三板斧"

作为新手，你不需要记住所有参数。先记住这三板斧，能解决 80% 的突发问题：

第一板斧：看"死活"——数据库还在喘气吗？

Informix / GBase 8s：

onstat -

输出第一行会告诉你状态：

• On-Line = 正常运行，别怕
• Blocked:CKPT = 被检查点卡住了，等等就好
• Blocked:LONGTX = 有个长事务把大家堵住了，要人命

DB2：

db2pd -

看 Instance Status，如果是 Active，说明引擎还活着。再配合：

db2pd -db yourdb -applications

如果看到好多 Lock-wait（锁等待），那就是"活着，但被自己人掐住了脖子"。

新手口诀： 先执行 onstat - 或 db2pd -，确认数据库没死透，再决定下一步。

---

第二板斧：看"堵车"——谁在锁我的表？

数据库最常见的"命案"就是锁冲突：A 用户占了门不让 B 用户进，B 用户又占了窗不让 C 用户过，最后全厂死锁。

Informix / GBase 8s：

onstat -k   # 看锁
onstat -u   # 看用户

onstat -k 会输出一张锁表，找到 owner（持有者）和 waiter（等待者）的 ID，再去 onstat -u 里查这个 ID 对应的是哪个用户、哪条连接。

DB2：

db2pd -db yourdb -locks -transactions -applications -dynamic

DB2 更贴心，这一条命令直接给你"全景图"：谁拿着锁、谁在等、对应哪个事务、甚至当时正在执行哪条 SQL 语句，一目了然。

新手口诀： 业务说"卡了"，先查锁。有锁找持有者，持有者往往是罪魁祸首。

---

第三板斧：看"仓库"——缓冲池是不是满了？

数据库的**缓冲池（Buffer Pool）**是内存里的数据缓存区。如果仓库满了，或者里面的货（数据页）管理混乱，数据库就会狂读磁盘，性能暴跌。

Informix / GBase 8s：

onstat -B   # 看缓冲池整体
onstat -R   # 看 LRU 队列（仓库的货架整理情况）

DB2：

db2pd -db yourdb -bufferpools

看 Dirty（脏页，改完没写回磁盘的数据）和 TotalHits（命中率）。命中率太低，说明内存没利用好，数据老是从磁盘读。

新手口诀： 系统 IO 高、查询慢，先看缓冲池命中率。命中率高是内存英雄，低就是磁盘狗熊。

---

三、它们为啥说像"亲兄弟"？

刚才讲的是用法，现在讲讲底层逻辑。理解了逻辑，你学任何数据库诊断工具都快。

共同点 1：都是"内存快照型"工具

普通 SQL 监控是"问前台"：select 一下，数据库得先停下手里的事，组织语言回答你。而 onstat 和 db2pd 是"翻监控录像"：直接读取数据库引擎写在内存里的状态信息，不打扰数据库干活。

类比：SQL 监控像打电话问司机"你到哪儿了"，onstat/db2pd 像直接看 GPS 定位。

共同点 2：都是"模块化积木"

两者都不是一个孤零零的命令，而是一个主命令 + 无数可选模块，像拼乐高：

我想看...	Informix 怎么拼	DB2 怎么拼
锁	onstat -k	db2pd -db xxx -locks
用户连接	onstat -u	db2pd -db xxx -applications
事务	onstat -x	db2pd -db xxx -transactions
缓冲池	onstat -B	db2pd -db xxx -bufferpools
日志	onstat -l	db2pd -db xxx -logs
线程/工人	onstat -g ath	db2pd -edus

你只需要把关心的模块"拼"在一起，就能得到定制化的诊断报告。

共同点 3：都支持"盯梢模式"

问题往往是间歇性的，看一次不够，得持续观察：

# Informix：每 5 秒刷新一次
onstat -r 5

# DB2：每 2 秒刷新，共看 5 次
db2pd -repeat 2 5

就像医院的监护仪，持续盯着你关心的指标波动。

---

四、给新手的"避坑指南"

1. 不要迷信"一个命令解决所有问题"

onstat 和 db2pd 输出的是某一瞬间的快照。如果问题只在凌晨 3 点出现一次，你 9 点上班执行命令，可能啥也看不到。这时候要配合持续盯梢（-r 或 -repeat），或者把输出重定向到文件：

# Informix
onstat -kux > /tmp/db_diag.txt

# DB2
db2pd -db sample -locks -applications file=/tmp/db_diag.txt

2. 权限问题

这两个命令通常需要数据库实例的属主权限（比如 informix 用户或 db2inst1 用户）才能读取共享内存。用普通用户执行可能会报错或输出为空。

3. 不要只看数字，要看"关系"

新手容易陷入"这个数字好大/好小"的焦虑。其实更重要的是关联分析：

• onstat -k 看到锁很多 → 结合 onstat -u 看是谁持有的 → 结合 onstat -g sql 看他在执行什么 SQL
• db2pd -locks 看到等待多 → 结合 -applications 看应用状态 → 结合 -dynamic 看 SQL

孤立的数据是数字，关联的数据才是线索。

---

五、一句话总结

onstat 和 db2pd 就像是 Informix 和 DB2 这两个不同门派，各自打造的**"急救听诊器"**。它们名字不同、参数不同，但设计思路完全一致：

绕过 SQL 层，直读内存，低侵入、高时效、模块化，让 DBA 在数据库最脆弱的时候，依然能看清真相。

作为新手，你不需要背下所有参数。记住本文的"三板斧"（看死活、看堵车、看仓库），理解它们"拼积木"式的模块化思维，你就已经迈出了从"菜鸟"到"救火队员"的关键一步。

毕竟，工欲善其事，必先利其器——而你现在，手里已经有器了。