《企业实战分享 · Druid 连接监控》

文章目录

---

写在前面的话

博主所在公司，后端的数据库连接池采用Druid，数据库采用Oracle，做过后端开发的都知道，生产环境出现数据库连接获取异常、连接池满等问题屡见不鲜，如何在出现此类问题的时候，更好的定位问题，是架构人员需要考虑的问题。
单纯依靠Zipkin、Prometheus、Grafana只能定位到连接数情况，具体的语法还是要依靠Oracle层面协助，本篇文章分享一下采用的解决思路。

---

SQL 查询阻塞信息

查询语法：

Select 'alter system kill session '''||a_s.sid || ',' || a_s.SERIAL# ||',@'||a_s.inst_id||''' immediate;' kill_sql,
       '节点 ' || a_s.INST_ID || ' session ' || a_s.sid || ',' || a_s.SERIAL# ||' 阻塞了 节点 ' || b_s.INST_ID || ' session ' || b_s.SID || ',' ||
       b_s.SERIAL# blockinfo,
       a_s.INST_ID,
       (select n.machine from gv$session n where n.sid = a_s.sid and n.serial# = a_s.serial# ) MACHINE,
       a_s.SID,
       a_s.SCHEMANAME,
       a_s.MODULE,
       a_s.STATUS,
       '后为被阻塞信息',
       b_s.INST_ID blocked_inst_id,
       b_s.SID blocked_sid,
       b_s.SCHEMANAME blocked_SCHEMANAME,
       b_s.EVENT blocked_event,
       b_s.MODULE blocked_module,
       b_s.STATUS blocked_status,
       b_s.SQL_ID blocked_sql_id,
       obj.owner blocked_owner,
       obj.object_name blocked_object_name,
       obj.OBJECT_TYPE blocked_OBJECT_TYPE,
       case
         when b_s.ROW_WAIT_OBJ# <> -1 then
          dbms_rowid.rowid_create(1,
                                  obj.DATA_OBJECT_ID,
                                  b_s.ROW_WAIT_FILE#,
                                  b_s.ROW_WAIT_BLOCK#,
                                  b_s.ROW_WAIT_ROW#)
         else
          '-1'
       end blocked_rowid, --被阻塞数据的rowid
       decode(obj.object_type,
              'TABLE',
              'select * from ' || obj.owner || '.' || obj.object_name ||
              ' where rowid=''' ||
              dbms_rowid.rowid_create(1,
                                      obj.DATA_OBJECT_ID,
                                      b_s.ROW_WAIT_FILE#,
                                      b_s.ROW_WAIT_BLOCK#,
                                      b_s.ROW_WAIT_ROW#) || '''',
              NULL) blocked_data_querysql  --被阻塞的SQL
  from gv$session a_s, 
       gv$session b_s, 
       dba_objects obj
 where b_s.BLOCKING_INSTANCE is not null
   and b_s.BLOCKING_SESSION is not null
   and a_s.INST_ID = b_s.BLOCKING_INSTANCE
   and a_s.SID = b_s.BLOCKING_SESSION
   and b_s.ROW_WAIT_OBJ# = obj.object_id(+)
 order by a_s.inst_id, a_s.sid;

结果分析：


某行记录代表某个会话阻塞了另外一个会话信息，具体字段分析如下：
KILL_SQL：alter system kill session ‘1609,56765,@1’ immediate;

BLOCK_INFO：节点 1 session 1609,56765 阻塞了 节点 1 session 836,27401

MODULE：PL/SQL Developer/JDBC Thin Client

BLOCKED_DATA_QUERYSQL：阻塞SQL

MACHINE：机器名

---

Druid 监听连接数

有了上面获取的数据，就可以考虑如何从程序层面做进一步的问题定位。
有两种思路：
1、自动监测，基于Druid的FilterEventAdapter，拦截重要事件，判定当前连接数大于一定阈值，则查询上述语法，组装结果后做出适当的响应；
2、主动查询，在统一日志界面，增加展示“连接视图”功能，主动获取某个服务的连接明细情况，展示给用户，很直观的看到占用的SQL情况；

---

总结陈词

上文分享若干企业实际开发中，Druid连接监控方案，希望对大家有帮助。
💗 后续会逐步分享企业实际开发中的实战经验，有需要交流的可以联系博主。