テーブルクリーナー
テーブルクリーナーは、レコードを古い順から自動的に削除して、データが急激に増加するのを防ぎます。
テーブルクリーナーは、テーブルから古いレコード、期限切れのレコード、または不要なレコードを削除するために (デフォルトでは) 1 時間に 1 回実行されるスケジュール設定済みジョブです。テーブルクリーナーは、テーブルが管理不能なサイズまで拡大するのを防ぎ、クエリのパフォーマンスを向上させます。
フィルターナビゲーターで「sys_auto_flush.list」と入力すると、自動フラッシュ [sys_auto_flush] テーブルのテーブルクリーナールールのリストを表示できます。自動フラッシュテーブルには、ベースシステムテーブルのルールと、それに対応するレコードの経過時間が表示されます。各ルールに一意の条件が定義されている場合は、1 つのテーブルに複数のルールを表示できます。
削除されるレコード
各テーブルクリーナールールでは以下を指定します。
- (レコードを削除する) ターゲットテーブル。
- ターゲットテーブルの [日付/時刻] 列に対応する [一致フィールド] 値。理想的には、[一致フィールド] は、レコードがアクティブになっている期間を表す日付フィールドです (sys_created_on など)。
- 削除がトリガーされるタイミングを決定する [経過時間 (秒)] の値。
- 周辺機器または監査テーブルの関連レコードをクリーニングするためのオプション。
- 削除するレコードをフィルタリングする 1 つ以上のオプションの条件。たとえば、「active = false AND state =closed」のレコードのみを削除するように指定できます。
[一致フィールド] が [経過時間 (秒)] の値よりも過去の日付を示している場合、テーブルクリーナージョブはレコードを削除します。
遅いルール処理
テーブルクリーナージョブが実行されると、各テーブルクリーナールールはプロセスの一部としていくつかのクエリを実行します。ルールの一致フィールドまたはその条件の重要な部分にインデックスがない場合、大量のデータに対してクエリが非効率的に実行されるため、ルールの処理が遅くなる可能性があります。
テーブルクリーナールールに、完了までに 30 秒以上かかるクエリがある場合、テーブルクリーナージョブ全体が停止します。デフォルトでは、テーブルクリーナーは 2 日間待機してからそのルールを再度テーブルクリーナージョブに含めるため、その間にテーブルクリーナージョブを中断することなく実行できます。システムのプロパティを追加することで、待機期間の長さを設定できます。「テーブルクリーナーのプロパティ」を参照してください。
テーブルクリーナーの無効化
テーブルの辞書レコードに [テーブルクリーナーの無効化] 属性を追加することで、管理者がテーブルクリーナールールを作成したり、特定のテーブルでテーブルクリーナーを実行したりできないようにすることができます。一部の内部システムテーブルには、デフォルトで [テーブルクリーナーの無効化] 属性が追加されています。
テーブルクリーナーの制限
次の制限に注意してください。
- テーブルローテーションまたはテーブル拡張を使用するように構成されたテーブルでは、テーブルクリーナーはサポートされていません。
- パフォーマンスは、テーブルのサイズと指定した条件によって異なります。たとえば、インデックスのない大きなテーブルでカスタム列を使用すると、パフォーマンスが大幅に低下します。パフォーマンスは、削除する行の数にも依存します。
- テーブルクリーナーは、1 つのテーブルからレコードを削除するのに最大 20 分かかります。クエリが遅い場合は、20 分間に削除されたレコードの量が少ない可能性があります。
- テーブルクリーナーは
DBDelete.setWorkflow()を呼び出しません。これは、DBDeleteオブジェクトがworkflow=falseで実行されることを意味します (Java ブール型のデフォルト値は false です)。したがって、ビジネスルールとワークフローの削除はトリガーされません。