- 通过慢SQL诊断,从dbe_perf.statement_history中获取sql的debug_query_id
如下脚本和图所示,通过配置log_duration和log_min_duration_statement开启和配置当前慢SQL诊断的门限。然后查询没有索引的大表(pg_tracing_test),构造慢SQL,就能从dbe_perf.statement_history中获得慢SQL的debug_query_id、unique_query_id和trace_id,为后续使用其他工具继续定位、定界提供输入。
openGauss=# set log_duration=on;
SET
openGauss=# set log_min_duration_statement=1000;
SET
openGauss=# select * from pg_tracing_test where a>=9000001;
a | b
---+---
(0 rows)
openGauss=# select unique_query_id,debug_query_id,query,start_time,finish_time from dbe_perf.statement_history where debug_query_id not in (9851624184873210,9288674231451710) order by debug_query_id desc;
unique_query_id | debug_query_id | query | start_time | finish_time
-----------------+-------------------+-------------------------------------------+-------------------------------+-------------------------------
2326677094 | 10696049115005721 | select * from pg_tracing_test where a>=?; | 2024-05-23 03:51:10.673514-07 | 2024-05-23 03:51:13.27177-07
3609497940 | 10696049115005643 | select * from pg_tracing_test where a>?; | 2024-05-23 03:41:22.235723-07 | 2024-05-23 03:41:25.208227-07
117913964 | 10696049115005414 | select * from pg_tracing_test where a=?; | 2024-05-23 03:14:06.669046-07 | 2024-05-23 03:14:09.355701-07
117913964 | 10696049115005403 | select * from pg_tracing_test where a=?; | 2024-05-23 03:13:46.636182-07 | 2024-05-23 03:13:49.339781-07
117913964 | 10696049115005402 | select * from pg_tracing_test where a=?; | 2024-05-23 03:13:17.637719-07 | 2024-05-23 03:13:34.145655-07
(5 rows)
2. dbe_perf.statement_history中debug_query_id与pg_stat_activity中的query_id是一致的。
在慢SQL诊断的同时,查询pg_stat_activity,能看到下图的结果:dbe_perf.statement_history中debug_query_id与pg_stat_activity中的query_id是一致的。
3.pg_stat_activity中的sessionid就是openGauss中数据库连接池中连接对应的线程id,是重复使用的。
关闭会话后,再立刻打开,sessionid高概率与之前分配的sessionid相同。所以sessionid当前会话具有唯一性,但历史上不具有唯一性。
(................待进一步补充完善)