ClustrixDB提供了几种机制来识别消耗大量系统资源的查询。这样的查询通常是应用程序索引不良或错误的结果。
ClustrixDB支持以下语法来杀死查询:
KILL [QUERY | CONNECTION] session_id
识别长时间运行的查询
下面的语句将输出系统中运行时间最长的查询。这通常是系统管理员识别行为不端的集群上可能出现的问题的第一步。会话虚拟关系提供了关于每个会话执行状态的大量细节。除了当前语句外，还将显示连接信息和事务状态。
sql> select * from system.sessions where statement_state = 'executing' order by time_in_state_s desc limit 1\G *************************** 1. row *************************** nodeid: 2 session_id: 99938306 source_ip: 10.2.2.243 source_port: 40758 local_ip: 10.2.14.15 local_port: 3306 user: 4099 database: system trx_state: open statement_state: executing xid: 5832691561615822852 cpu: 4 isolation: REPEATABLE-READ last_statement: select * from sessions where statement_state = 'executing' order by time_in_state_s desc limit 1 time_in_state_s: 0 created: 2016-01-12 22:01:40 heap_id: 288230379201751147 trx_age_s: 0 trx_mode: autocommit trx_counter_select: 1 trx_counter_insert: 0 trx_counter_update: 0 trx_counter_delete: 0 trx_is_writer: 0 1 row in set (0.00 sec)
识别长时间运行的写入事务
在ClustrixDB等完全关系的SQL数据库中，长时间运行的写事务可能会导致问题。通常，行为不端的应用程序会错误地关闭自动提交选项，让每个会话在一个非常长的事务中运行。当发生这种情况时，这些事务将积累大量的写锁，从而阻止其他试图修改相同数据的事务运行。为了识别这些情况，ClustrixDB在sessions关系中包含几个列，这些列跟踪事务的时间、当前事务中执行的语句的数量和类型，以及事务是否发出任何写操作(布尔值0,1)。
例如，要查找系统中最古老的写事务，发出以下命令:
sql> select * from system.sessions where trx_is_writer order by trx_age desc limit 1\G *************************** 1. row *************************** nodeid: 2 session_id: 99938306 source_ip: 10.2.2.243 source_port: 40758 local_ip: 10.2.14.15 local_port: 3306 user: 4099 database: sergei trx_state: open statement_state: executing xid: 5832694275126951940 cpu: 4 isolation: REPEATABLE-READ last_statement: select * from system.sessions where trx_is_writer order by trx_age desc limit 1 time_in_state_s: 0 created: 2016-01-12 22:01:40 heap_id: 288230379201751394 trx_age_s: 31 trx_mode: explicit trx_counter_select: 2 trx_counter_insert: 5 trx_counter_update: 1 trx_counter_delete: 3 trx_is_writer: 1 1 row in set (0.00 sec)