南大通用数据库如何查看当前死锁信息及定位阻塞会话？

Question

在南大通用GBase 8a/8s数据库中，如何实时查看当前发生的死锁信息并准确定位阻塞会话？常见场景下，业务出现响应缓慢或事务超时，但系统未报明确死锁错误；管理员需快速判断是否存在死锁或长事务阻塞。GBase 8a（MPP架构）默认不自动记录死锁详情，需依赖`show processlist`、`information_schema.PROCESSLIST`及`gbase.waiting_threads`等视图识别等待链；而GBase 8s（类Oracle单机/HA架构）则可通过`v$lock`、`v$session_wait`、`v$transaction`关联分析锁持有与等待关系，并结合`dbms_monitor.lock_trace_on()`开启锁跟踪。但官方未提供类似Oracle的`v$deadlock`视图或MySQL的`INFORMATION_SCHEMA.INNODB_TRX`一站式死锁快照。因此，实际运维中常因缺乏直观死锁报告、等待链解析复杂、历史死锁不可追溯等问题，导致根因定位耗时过长。如何构建标准化脚本实现“一键识别死锁+阻塞源头+被阻塞SQL”？这是DBA高频痛点。

Answer 1

```html

一、现象识别：从“业务慢”到“疑似阻塞”的初步诊断

当应用出现事务超时（如 JDBC timeout=30s）、接口响应延迟突增、批量作业卡顿，但数据库未抛出 ERROR 1213 (40001): Deadlock found 时，需启动阻塞链排查。GBase 8a/8s 均不默认记录死锁事件日志（gbase.log 中无结构化死锁堆栈），故必须依赖实时会话状态推断。关键信号包括：
• SHOW PROCESSLIST 中大量会话状态为 Waiting for lock 或 Locked（8s）/ waiting（8a）；
• information_schema.PROCESSLIST 中 TIME 字段持续增长且 STATE 长期非空；
• GBase 8a 的 gbase.waiting_threads 视图中存在循环等待路径（如 A→B→C→A）。

二、架构分治：8a（MPP）与 8s（OLTP）的监控范式差异

维度	GBase 8a（MPP）	GBase 8s（类Oracle）
核心视图	information_schema.PROCESSLIST, gbase.waiting_threads, gbase.cluster_status	v$session, v$lock, v$session_wait, v$transaction
锁跟踪能力	仅支持节点级等待关系快照，无事务级锁粒度	支持 dbms_monitor.lock_trace_on(sid) 实时捕获锁请求/持有链
死锁检测机制	由 coordinator 节点周期性扫描 waiting_threads 构建等待图，超时后 Kill 任一参与者（无日志记录）	基于 v$lock 的 blocker/waiter 关系实时检测，但不自动写入 v$deadlock

三、深度解析：构建等待链拓扑的SQL逻辑

以 GBase 8s 为例，以下SQL可递归识别阻塞源头（支持 Oracle 风格 CONNECT BY）：

SELECT 
  level AS depth,
  s.sid,
  s.username,
  s.osuser,
  s.machine,
  s.program,
  s.status,
  l.type,
  l.lmode,
  l.request,
  s.sql_id,
  q.sql_text
FROM v$session s
JOIN v$lock l ON s.sid = l.sid
LEFT JOIN v$sql q ON s.sql_id = q.sql_id
START WITH s.sid IN (
  SELECT sid FROM v$lock WHERE block = 1
)
CONNECT BY PRIOR l.sid = (
  SELECT sid FROM v$lock l2 WHERE l2.id1 = l.id1 AND l2.id2 = l.id2 AND l2.request > 0
)
ORDER BY level, s.sid;

四、标准化脚本：一键式死锁与阻塞分析工具（gbase-deadlock-analyzer.sh）

该脚本适配双平台，自动判断实例类型并执行对应逻辑：

• 步骤1：探测实例版本（SELECT @@version 匹配 8a 或 8s）
• 步骤2：采集基础会话快照（含 PROCESSLIST / v$session）
• 步骤3：构建等待图并检测环路（8a 使用 gbase.waiting_threads JOIN 自关联；8s 使用 v$lock 生成 blocker-waiter 映射）
• 步骤4：提取被阻塞会话的完整 SQL（通过 INFORMATION_SCHEMA.PROCESSLIST.INFO 或 v$sqltext 拼接）
• 步骤5：输出结构化报告（含阻塞根因 SID、持锁事务开始时间、被阻塞 SQL 片段、建议 Kill 命令）

五、可视化增强：阻塞关系 Mermaid 流程图生成

脚本可选输出 Mermaid 格式依赖图，便于快速定位瓶颈节点：

flowchart LR
  A[SID=1023
UPDATE t1 SET x=1] -->|holds TX-7F2A| B[SID=1025
DELETE FROM t2]
  B -->|waits on TX-7F2A| C[SID=1027
SELECT * FROM t1]
  C -->|waits on TX-7F2A| A
  style A fill:#ff9999,stroke:#333
  style B fill:#99ccff,stroke:#333
  style C fill:#99ff99,stroke:#333

六、历史追溯：补全死锁审计缺口的三大实践

1. 启用锁跟踪日志：8s 环境定期执行 dbms_monitor.lock_trace_on(ALL) 并定向输出至独立 trace 文件，配合 logrotate 控制体积；
2. 建立阻塞快照表：每日定时将 v$lock + v$session 关联结果存入 DBA_BLOCKING_HISTORY，添加 SNAPSHOT_TIME 和 IS_DEADLOCK_CANDIDATE 标记；
3. 集成 Prometheus+Grafana：通过自定义 exporter 抓取 gbase.waiting_threads.count / v$lock.block_count 指标，设置告警阈值（如 waiting_threads > 5 持续60s）。

七、避坑指南：高频误判场景与验证方法

常见伪死锁场景需人工排除：
✓ 长事务未提交：检查 v$transaction.start_time 是否早于当前时间 10 分钟；
✓ DDL 锁竞争：8s 中 v$lock.type='TM' 且 lmode=6 表示 DDL 排他锁；
✓ 网络延迟假象：对比 PROCESSLIST.TIME 与客户端连接建立时间（CREATE_TIME 字段）；
✗ 错误认为所有 Waiting for table metadata lock 均为死锁——实际多为 ALTER TABLE 阻塞后续 DML。

```