SQL実行中のセッションを強制的に終了する方法②

公開日: 公開日：2020年11月20日（金）
更新日: 更新日：2025年12月17日（水）
サブカテゴリー: 基本操作

タグ: #セッション

はじめに

通常、実行中のSQLは「SQL実行中のセッションを強制的に終了する方法(CLOSE_SESSION関数)」の手順で停止できますが、SQLがハングしてしまい、CLOSE_SESSION関数や INTERRUPT_STATEMENT関数を実行しても、停止できない場合があります。本稿では、これらの方法でSQLを停止できない場合の対処方法を解説します。

※注意事項
Management Consoleから、実行中のSQLに対して「Close Session」や「Cancel Query」の停止操作は可能です。しかし、この操作は CLOSE_SESSION関数または INTERRUPT_STATEMENT関数を実行するためのコマンドを発行しているだけなので、Management Consoleを利用した場合も同様にSQLは停止できません。

対処方法

SQLを強制的に停止する方法は、以下の2つがあります。

①SQLのメモリを割当てを無効にする

SQLの割当てメモリサイズが「0KB」、SQLの実行可能な最大時間が「0秒」に指定されたユーザ定義リソースプールを作成します。作成したユーザ定義リソースプールにSQLを強制的に移動させることで、メモリの割当てがされない状態となり、停止させることができます。

②SQLを受け付けたノードを再起動する

複数ノード構成の場合は、SQLを受け付けたノードを再起動することで、停止させることができます。

※注意事項
シングル構成の場合は、非冗長化のためVerticaデータベース自体の再起動が必要です。

実行結果

SQLを強制的に停止した結果は、以下のとおりです。

①SQLのメモリを割当てを無効にする

### 端末1 ###
・SQLを実行
[dbadmin@ ~]$ vsql -h xxx.xx.xx.22 -C -U dbadmin -w testdb -c 'INSERT INTO LINEORDER_NEW SELECT * FROM LINEORDER';

### 端末2 ###
・SQLの接続情報を確認
dbadmin=> select * from QUERY_REQUESTS where is_executing ='t';
     node_name     | user_name |           session_id             | request_id |  transaction_id     | statement_id   | request_type |                        request                        | request_label |                        search_path                        | memory_acquired_mb | success | error_count |        start_timestamp        | end_timestamp | request_duration | request_duration_ms | is_executing
-------------------+-----------+----------------------------------+------------+---------------------+----------------+--------------+-------------------------------------------------------+---------------+-----------------------------------------------------------+--------------------+---------+-------------+-------------------------------+---------------+------------------+---------------------+--------------
 v_testdb_node0002 | dbadmin   | v_testdb_node0002-186576:0x162★ |          1 | 49539595901076398★ |            1★ | QUERY        | INSERT INTO LINEORDER_NEW SELECT * FROM LINEORDER     |               | "$user", public, v_catalog, v_monitor, v_internal, v_func |            6475.49 |         |             | 2020-11-19 13:44:17.275381+09 |               |                  |                     | t
 v_testdb_node0001 | dbadmin   | v_testdb_node0001-155514:0xb5    |          4 | 45035996273709240   |            4   | QUERY        | select * from QUERY_REQUESTS where is_executing ='t'; |               | "$user", public, v_catalog, v_monitor, v_internal, v_func |             252.61 |         |             | 2020-11-19 13:44:59.721784+09 |               |                  |                     | t
(2 rows)
★「session_id」,「transaction_id」,「request_type」を確認
　上記例の場合は、以下のとおり
　「session_id = v_testdb_node0002-186576:0x162」
　「transaction_id = 49539595901076398」
　「statement_id = 1」

・ユーザ定義リソースプールを作成
dbadmin=> CREATE RESOURCE POOL cancel MEMORYSIZE '0K' MAXMEMORYSIZE '0K' RUNTIMECAP '0';
CREATE RESOURCE POOL
★cancelリソースプールが作成されたことを確認
「MEMORYSIZE：利用可能なメモリサイズ」
「MAXMEMORYSIZE：利用可能な最大メモリサイズ」
「RUNTIMECAP：SQLの最大実行時間」

・cancelリソースプールにSQLを強制移動
dbadmin=> SELECT MOVE_STATEMENT_TO_RESOURCE_POOL ('v_testdb_node0002-186576:0x162', 49539595901076398, 1, 'cancel');
                                                                     MOVE_STATEMENT_TO_RESOURCE_POOL
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 MOV_REPLAN: Target pool does not have sufficient resources. See v_monitor.resource_pool_move for details. Vertica will attempt to replan the statement on target pool.
(1 row)
★SQLの「session_id」,「transaction_id」,「request_type」を指定/実行し、cancelリソースプールに移動されたことを確認

### 端末1 ###
・SQLの状態確認
[dbadmin@ ~]$ vsql -h xxx.xx.xx.22 -C -U dbadmin -w testdb -c 'INSERT INTO LINEORDER_NEW SELECT * FROM LINEORDER';
ERROR 3587: Insufficient resources to execute plan on pool cancel [Request Too Large:Threads Exceeded: Requested = 14, Free = 0 (Limit = 0, Used = 0); File Handles Exceeded: Requested = 99, Free = 0 (Limit = 0, Used = 0); Memory(KB) Exceeded: Requested = 129663, Free = 0 (Limit = 0, Used = 0)]
★SQLはメモリの割当てがされず、停止されたこと確認

②SQLを受け付けたノードを再起動する

### 端末1 ###
・SQLを実行
[dbadmin@ ~]$ vsql -h xxx.xx.xx.22 -C -U dbadmin -w testdb -c 'INSERT INTO LINEORDER_NEW SELECT * FROM LINEORDER';

### 端末2 ###
・SQLの接続情報
dbadmin=> select * from QUERY_REQUESTS where is_executing ='t';
     node_name     | user_name |           session_id              | request_id |  transaction_id   | statement_id | request_type |                        request                        | request_label |                        search_path                        | memory_acquired_mb | success | error_count |        start_timestamp        | end_timestamp | request_duration | request_duration_ms | is_executing
-------------------+-----------+-----------------------------------+------------+-------------------+--------------+--------------+-------------------------------------------------------+---------------+-----------------------------------------------------------+--------------------+---------+-------------+-------------------------------+---------------+------------------+---------------------+--------------
 v_testdb_node0002 | dbadmin   | v_testdb_node0002-100021:0x1a40★ |          1 | 49539595901076223 |            1 | QUERY        | INSERT INTO LINEORDER_NEW SELECT * FROM LINEORDER★   |               | "$user", public, v_catalog, v_monitor, v_internal, v_func |             6474.8 |         |             | 2020-11-19 13:34:25.266155+09 |               |                  |                     | t
 v_testdb_node0001 | dbadmin   | v_testdb_node0001-155514:0xb5     |          1 | 45035996273709240 |            1 | QUERY        | select * from QUERY_REQUESTS where is_executing ='t'; |               | "$user", public, v_catalog, v_monitor, v_internal, v_func |             252.61 |         |             | 2020-11-19 13:35:17.113162+09 |               |                  |                     | t
(2 rows)
★「session_id = v_testdb_node0002-100021:0x1a40」を確認
「session_id」にはSQLを受け付けたノード番号が出力されるので、ノード2で受け付けたことを確認

・SQLを受け付けたノードのIPアドレス
dbadmin=> select * from nodes;
     node_name     |      node_id      | node_state | is_primary | node_address | node_address_family | export_address | export_address_family |                      catalog_path                      | node_type | is_ephemeral | standing_in_for | subcluster_name |     last_msg_from_node_at     | node_down_since
-------------------+-------------------+------------+------------+--------------+---------------------+----------------+-----------------------+--------------------------------------------------------+-----------+--------------+-----------------+-----------------+-------------------------------+-----------------
 v_testdb_node0001 | 45035996273704978 | UP         | t          | 10.0.0.22    | ipv4                | 10.0.0.22      | ipv4                  | /home/dbadmin/testdb/v_testdb_node0001_catalog/Catalog | PERMANENT | f            |                 |                 | 2020-11-19 13:38:55.007371+09 |
 v_testdb_node0002 | 45035996273705090 | UP         | t          | 10.0.0.23★  | ipv4                | 10.0.0.23      | ipv4                  | /home/dbadmin/testdb/v_testdb_node0002_catalog/Catalog | PERMANENT | f            |                 |                 | 2020-11-19 13:38:55.006693+09 |
 v_testdb_node0003 | 45035996273705094 | UP         | t          | 10.0.0.24    | ipv4                | 10.0.0.24      | ipv4                  | /home/dbadmin/testdb/v_testdb_node0003_catalog/Catalog | PERMANENT | f            |                 |                 | 2020-11-19 13:38:55.006995+09 |
(3 rows)
★「v_testdb_node0002」が「node_address = 10.0.0.23」であることを確認

### 端末3 ###
・対象ノードのステータス
[dbadmin@ ~]$ admintools -t list_allnodes
 Node              | Host      | State | Version          | DB
-------------------+-----------+-------+------------------+--------
 v_testdb_node0001 | 10.0.0.22 | UP    | vertica-10.0.1.0 | testdb
 v_testdb_node0002 | 10.0.0.23 | UP★  | vertica-10.0.1.0 | testdb
 v_testdb_node0003 | 10.0.0.24 | UP    | vertica-10.0.1.0 | testdb
★ノード2がUPであることを確認

・対象ノードを停止
[dbadmin@ ~]$ admintools -t stop_node -s  10.0.0.23;
*** Forcing host shutdown ***
        Sending host shutdown command to '10.0.0.23'
★ノード2が停止されたことを確認

・対象ノードを起動
[dbadmin@ ~]$ admintools -t restart_node -d testdb -s 10.0.0.23
Info: no password specified, using none
*** Restarting nodes for database testdb ***
        Restarting host [10.0.0.23] with catalog [v_testdb_node0002_catalog]
        Issuing multi-node restart
        Starting nodes:
                v_testdb_node0002 (10.0.0.23)
        Starting Vertica on all nodes. Please wait, databases with a large catalog may take a while to initialize.
        Node Status: v_testdb_node0002: (DOWN)
        Node Status: v_testdb_node0002: (DOWN)
        Node Status: v_testdb_node0002: (DOWN)
        Node Status: v_testdb_node0002: (INITIALIZING)
        Node Status: v_testdb_node0002: (UP)
★ノード2が起動されたことを確認

・対象ノードのステータス
[dbadmin@ ~]$ admintools -t list_allnodes
 Node              | Host      | State | Version          | DB
-------------------+-----------+-------+------------------+--------
 v_testdb_node0001 | 10.0.0.22 | UP    | vertica-10.0.1.0 | testdb
 v_testdb_node0002 | 10.0.0.23 | UP★  | vertica-10.0.1.0 | testdb
 v_testdb_node0003 | 10.0.0.24 | UP    | vertica-10.0.1.0 | testdb
★ノード2がUPであることを確認

### 端末1 ###
・SQLの状態確認
[dbadmin@ ~]$ vsql -h xxx.xx.xx.22 -C -U dbadmin -w testdb -c 'INSERT INTO LINEORDER_NEW SELECT * FROM LINEORDER';

server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
connection to server was lost
★SQLはノード2から切断されて停止されたことを確認

参考情報

Management Consoleから特定のセッションをクローズする方法
https://www.ashisuto.co.jp/cm/analytics-database/mc_close_session.html

検証バージョンについて

この記事の内容はVertica 10.0で確認しています。

更新履歴

2020/11/20　本記事を公開

Analytics Database

SQL実行中のセッションを強制的に終了する方法②

はじめに

対処方法

①SQLのメモリを割当てを無効にする

②SQLを受け付けたノードを再起動する

実行結果

①SQLのメモリを割当てを無効にする

②SQLを受け付けたノードを再起動する

参考情報

検証バージョンについて

更新履歴