Replay Delete

DELETEの情報を管理するデリートベクターはROSコンテナ毎に存在しています。
ROSコンテナが複数存在する場合は、Mergeoutによって定期的にひとつのROSコンテナにまとめられますが、
その際にまとめれたROSコンテナ用にデリートベクターが再作成されます。

Verticaはこの処理を実行する際に内部的に旧デリートベクターで記憶しているDELETEを再度行うことで、
新しいデリートベクターへDELETEの情報を登録し直しています。このような内部的な再DELETE処理を
Replay Deleteといいます。



Replay Delete中は、通常のDELETEと同様に該当テーブルに対するテーブルロックが発生します。そのため、大量のDELETEを行った場合などは、MergeoutのタイミングでReplay Deleteによる長時間のテーブルロックが発生し、その間に該当テーブルに対するDML処理はロックの解放待ちになります。
その場合、ロックのタイムアウト(デフォルトでは5分)が発生し、後続のDML処理はエラー終了する可能性があります。

下記参考情報と同様に、大量のDELETE処理は夜間帯等アクセスの少ない時間に実施することをお薦めします。

参考情報

・DELETEの注意点(１)
　http://vertica-tech.ashisuto.co.jp/delete-notice-1/

・DELETEの注意点(３)
　http://vertica-tech.ashisuto.co.jp/delete-notice-3/

Understanding the Vertica Replay Delete Algorithms
https://www.vertica.com/kb/Replay-Deletes/Content/BestPractices/Replay-Deletes.htm

検証バージョンについて

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

更新履歴

2019/04/12　検証バージョンを9.2に変更
2015/8/6　　本記事を公開