テーブルクリーナー

  • リリースバージョン: Washingtondc
  • 更新日 2024年02月01日
  • 読む3読むのに数分

    • テーブルクリーナーは、レコードを古い順から自動的に削除して、データが急激に増加するのを防ぎます。

    テーブルクリーナーは、テーブルから古いレコード、期限切れのレコード、または不要なレコードを削除するために (デフォルトでは) 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 です)。したがって、ビジネスルールとワークフローの削除はトリガーされません。