南大通用GBase 8s数据库（gbase database）在日常运维中，业务突然卡顿、接口超时、锁等待告警是比较高频的问题。很多时候我们需要快速抓到现场正在运行的 SQL，判断是否存在长事务、慢查询、资源抢占。onstat -g sql 就是运维人手必备的现场排查命令。本文即给大家介绍其用法、示例和风险边界。
排查命令：onstat -g sql
配套联动排查命令（组合拳）
# 查看会话详情、事务状态onstat -u # 查看该会话持有的锁信息，判断锁阻塞源头onstat -g locks # 查看会话等待事件，看是IO等待还是锁等待onstat -g wait
✅ 思路：
- 业务卡顿告警，先执行 onstat -g sql，快速扫一遍有没有执行很久的大查询、批量 DML；
- 找到可疑会话 sid；
- 使用 onstat -g locks 确认是否持有排他锁，造成其他会话阻塞；
- 确认风险后，必要时杀会话：
onmode -z
⚠️ 杀会话会回滚当前事务，务必先和业务确认，禁止随意在线上执行。
踩坑避雷：oncheck -cD
很多同学在需要校验数据一致性时，会直接执行 oncheck -cD，这里重点提醒风险：
# 校验数据页一致性oncheck -cD :
oncheck -cD 的行为：读取表的数据页做一致性校验， 运行期间会产生大量 IO，并且会对访问的表加共享锁。
- ❌ 禁止业务高峰直接执行，极易阻塞写入业务，引发大面积超时；
- ✅ 正确方案：只在业务低峰窗口执行；优先使用备份校验代替在线 oncheck；
- 补充：oncheck -cI 是校验索引页，同样有 IO 和锁影响，遵循同样规范。
补充小结 & 区分建议
- 排查卡顿、锁等待、抓 SQL：优先 onstat -g sql，轻量、无锁、对业务影响极小，可以在紧急故障时直接使用；
- 数据页 / 索引页一致性检查：oncheck 系列属于侵入式检查，属于故障事后校验、定期巡检动作，不属于实时排查命令。
GBase 8s 运维讲究 “先抓现场，再谨慎校验”，用好onstat -g sql这套组合排查命令，可以帮我们快速定位大部分业务阻塞问题；同时牢记 oncheck 的锁和 IO 风险，避开线上重大故障。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/69979120/viewspace-3187831/ ，如需转载，请注明出处，否则将追究法律责任。
下一篇：
没有了~
请登录后发表评论
登录
全部评论
最新文章
- GBase 8s数据库排查命令onstat -g sql基础用法讲解
- 2026年11月南大通用GBase 8s认证培训开始报名
- DB-Engines 数据库排行榜11月榜单：全球榜单与国产数据库排名
- 南大通用GBase 8c数据库HTAP让报表实时可查（三）
- 南大通用GBase 8c数据库HTAP让报表实时可查（二）
- 南大通用GBase 8c数据库HTAP让报表实时可查（一）
- GBase 8c数据库HyBench登顶技术解析
- 2026十月南大通用GBase 8a MPP Cluster认证培训圆满结束
- 相约广州！GBase数据库喊你来打卡2026移动网络大会
- GBase 8s数据库备份双雄之ontape适用场景
