Skip to main content

履歴テーブルの消去

開発やテストの際には、頻繁にデータをロード、クリアし、再ロードすることが一般的です。 Incentives テーブルは生産量よりもかなり多い。 履歴追跡は無効になっていませんこれらのアクションにより、関連する履歴テーブルが過度に大きくなり、大量のストレージ領域が消費されることになります。

パフォーマンスとソリューションへの影響

  • 履歴テーブルが長すぎると、インポート時間に悪影響が及び、実行速度が遅くなる可能性があります。

    • この問題を軽減するには、履歴消去機能を使用できます。

履歴消去ツールを使用するシナリオ

監査履歴は不要

  • 全ての Incentives テーブルは、非本番環境では一般的です。

  • 具体的には Incentives テーブルは、非本番環境でもよく使用されます。

復元されたモデル

  • 別の環境のデータベース バックアップから復元されたモデルで監査履歴が必要ない場合。

アーカイブされたデータ

  • 監査履歴が特定の日付より前の場合、その時点でモデルがアーカイブされているため、監査履歴は不要です。

機密データ

  • 機密データをマスクする必要がある場合、監査履歴を消去すると、履歴テーブルの不要なマスクを防ぐことができます。

パージ後の最適化

履歴を消去した後は、履歴テーブルの統計を更新して空になったことを反映するために、モデル最適化機能を実行することをお勧めします。

スケジュールとメンテナンス

パージのスケジュール設定

  • 履歴の消去は任意の指定期間にスケジュール設定可能 Incentives テーブル。

データベースのメンテナンス

  • 履歴を消去すると実行時のデータベース フットプリントが削減されますが、履歴テーブルは時間の経過とともに徐々に大きくなるため、データベース メンテナンス ジョブも推奨されます。

  • 断片化が激しい場合は、メンテナンス ジョブでインデックスを再構築する必要があります。

    • インデックスの再編成: 断片化が 5% ~ 30% の場合に実行します。

    • インデックスの再構築: 断片化が 30% を超える場合に実行します。

  • インデックスの再編成と再構築はスケジューラの一部ですが、断片化の割合は管理ウェブアプリケーションではまだ表示されません。詳細については、 インデックスの再編成と再構築 セクション。