Amazon Redshift の VACUUM 操作でディスク容量が再利用されない理由を知りたいです。

簡単な説明

テーブル行を削除すると、非表示のメタデータ ID 列 (DELETE_XID) には、行を削除したトランザクションの ID が付与されます。

削除前に開始された、アクティブで長時間実行されているトランザクションがある場合は、VACUUM は行をクリーンアップできず、ディスク容量を再利用することはできません。

DELETE_XID 列の詳細については、「ナローテーブルでストレージを最適化する」を参照してください。

解決策

Amazon Redshift クラスターで長時間実行されているトランザクションがないかを確認するには、次のクエリを実行します。

rsdb=# select *,datediff(s,txn_start,getdate())/86400||' days '||datediff(s,txn_start,getdate())%86400/3600||' hrs '||datediff(s,txn_start,getdate())%3600/60||' mins '||datediff(s,txn_start,getdate())%60||' secs' duration from svv_transactions where lockable_object_type='transactionid' and  pid<>pg_backend_pid() order by 3;

次の出力は、xid 50341 が 19 分 37 秒間アクティブであることを示しています。

txn_owner  | txn_db |  xid  |  pid  |         txn_start          |   lock_mode   | lockable_object_type | relation | granted |           duration
-----------+--------+-------+-------+----------------------------+---------------+----------------------+----------+---------+------------------------------
 superuser | rsdb   | 50341 | 21612 | 2019-08-19 20:20:33.147622 | ExclusiveLock | transactionid        |          | t       | 0 days 0 hrs 19 mins 37 secs
(1 row)

Amazon Redshift テーブルから行が削除されたことを確認するには、次のクエリを実行します。

select a.query, a.xid, trim(c.name) tablename, b.deleted_rows, a.starttime, a.endtime
from stl_query a
join (select query, tbl, sum(rows) deleted_rows from stl_delete group by 1,2) b
on a.query = b.query
join (select id, name from stv_tbl_perm group by 1,2) c
on c.id = b.tbl
where a.xid in (select distinct xid from stl_commit_stats)
and trim(c.name) = 'tablename'
order by a.starttime;

次の出力は、行削除対象としてマークされたトランザクション (xid 50350) が、長時間実行するトランザクション (xid 50341) の後に開始されたことを示しています。

query  |  xid  | tablename | deleted_rows |         starttime          |          endtime
-------+-------+-----------+--------------+----------------------------+----------------------------
 18026 | 50350 | test      |            5 | 2019-08-19 20:20:48.137594 | 2019-08-19 20:20:50.125609
(1 rows)

次のいずれかの方法で、VACUUM DELETE がこれらの削除された行を再利用できるようにします。

• 長時間実行されているトランザクションが完了するまで待機します。
• PG_TERMINATE_BACKEND ステートメントを使用し、長時間実行されているトランザクションを保持しているセッションを終了します。

上記のアクションが完了した後、VACUUM 操作を再実行します。

長時間実行されているトランザクションを調査する

長時間実行されているトランザクションのアクティビティを確認するには、SVL_STATEMENTTEXT ビューをクエリします。

rsdb=# select pid, xid, trim(label), starttime, endtime, trim(text) from svl_statementtext where xid = 50341 order by starttime , sequence;

出力例

pid  |  xid  |  btrim  |         starttime          |          endtime           |          btrim
-------+-------+---------+----------------------------+----------------------------+--------------------------
 21612 | 50341 | default | 2019-08-19 20:20:31.733843 | 2019-08-19 20:20:31.733844 | begin;
 21612 | 50341 | default | 2019-08-19 20:20:33.146937 | 2019-08-19 20:20:35.020556 | select * from sometable;
(2 rows)

クエリがトランザクションで実行されていることを確認するにはSTV_INFLIGHT ビューをクエリします。

rsdb=# select query, xid, pid, starttime, trim(text) from stv_inflight where xid = 50341;

出力例

query | xid | pid | starttime | btrim
-------+-----+-----+-----------+-------
(0 rows)

トランザクションの実行が長くなる一般的な原因

次の動作により、トランザクションの実行時間が長くなる可能性があります。

• 自動コミットが無効であるクライアントから、ユーザーが明示的なトランザクションを開始した場合。トランザクションは、ユーザーが COMMIT または ROLLBACK コマンドでトランザクションを閉じるか、セッションが終了するまではアクティブ状態を維持します。
• ユーザーがトランザクションを開始し、BEGIN を使用しても、COMMIT コマンドまたは ROLLBACK コマンドでトランザクションが終了することはありません。

関連情報

テーブルにバキュームを実行する

バキュームの所要時間を最小化する