gbase8a慢sql原因排查

在使用GBase 8a MPP数据库时，若遇到迟迟无法执行完成的SQL时，通常有以下几种常见情况：

1. 锁堵塞

1）先通过show processlist命令，查看SQL的状态，观察其是否为”checking permission“，如果是，则大概率是锁堵塞。如果不是，

2）当是时，通过gcadmin showlock命令，查看当前集群的锁信息。则不是锁堵塞。

      a. 记录processlist中，该SQL的会话ID

     b.在showlock信息中，通过会话ID，确认该SQL在等待哪个锁。比如下图，就查出了ID=269的SQL在等待哪个锁

        c.在showlock信息中，搜索该锁在被哪条SQL持有。

d.回到processlist信息，确认ID=342的SQL的执行情况。判断其是否在正常执行，是否可以kill掉以释放锁。

2. 笛卡尔积

1）扫描各节点的磁盘情况，观察是否存在磁盘突然增长的情况。因为笛卡尔积SQL会导致出现大量的临时数据占用磁盘。

        a.在各节点上du -sh ../gnode/tmpdata，用c3执行df命令找到磁盘空间快满了的节点。

         b.若出现某节点空间明显高于其他节点的情况，则为异常

2）前往异常节点的tmpdata目录下，查看文件名称，文件最多的文件名称开头即为会话ID。登录该节点，cd /opt/GBaseMpp/gnode/tmpdata/cache_gbase/下，执行du ，找到生成临时文件较多的session id ，记录为 gnode_sid ，这个id是子任务的id ，通过子任务可以查到父任务id。
3）gncli登录该节点，通过会话ID，关联到其在gcluster层的会话id。在GNode层SQL语句的hint中会带有其在gcluster层的会话id

4）登录gcluster节点，根据gcluster层的会话id查看SQL并分析SQL。

3. 慢节点堵塞

1）通过gcluster层的会话ID，前往各GNode节点，查看该SQL在各GNode层的执行情况。

2）若该SQL，目前只有一个节点在执行，则可能因为木桶理论导致SQL被堵塞

3）观察该GNode节点的SQL情况，判断其积压的SQL数量是不是明显高于其他节点

4）观察该节点的资源历史占用情况

5）分析慢节点原因并考虑是否重启该节点