Amazon Redshift の VACUUM 操作がディスク容量を再利用しないのはなぜですか ?

最終更新日: 2019 年 12 月 9 日

削除対象としてマークされた行を含む Amazon Redshift テーブルで VACUUM FULL または VACUUM DELETE ONLY 操作を実行しています。操作は正常に完了しているように表示されます。ディスク容量が再利用されないのはなぜですか ?

簡単な説明

この問題は、通常、長時間実行されるアクティブなトランザクションがある場合に発生します。VACUUM は、クラスターで最も古いアクティブな xid より小さいトランザクション ID(xid) を持つ行でのみ実行されます。削除対象としてマークされた行が長時間実行されているトランザクションの後に開始され、VACUUM 操作の実行時に長時間実行されているトランザクションがまだアクティブである場合、削除対象としてマークされた行は再利用されません。

解決方法

1.    クラスターで長時間実行されるアクティブなトランザクションを確認するには、次のようなクエリを実行します。

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 が 2019-08-19 20:20:33 に開始され、19 分 37 秒間アクティブになっていることが分かります。

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

2.    テーブルから行が削除された日時を確認するには、次のようなクエリを実行します。

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 50341) の後に xid 50350 (行が削除対象としてマークされたトランザクション) が開始されたことが分かります。

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 がこれらの削除された行を再利用できるようにするには、次のいずれかのオプションを選択し、VACUUM 操作を再実行します。

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

長時間実行されるトランザクションの調査

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 でトランザクションを閉じることはありません。

この記事はお役に立ちましたか?

改善できることはありますか?


さらにサポートが必要な場合