17.00 - 17.05 - システム ログの除去操作について - Advanced SQL Engine - Teradata Database

Teradata Vantage™ - データベースの管理

Product
Advanced SQL Engine
Teradata Database
Release Number
17.00
17.05
Release Date
2020年6月
Content Type
管理
Publication ID
B035-1093-170K-JPN
Language
日本語 (日本)
ログや、AccessLogV、LogOnOffV、Software_Event_LogVなどの各ビューの基礎となる各テーブルは、システムによって自動的にパージされることはありません。Teradata Viewpoint Performance Data Collectionポートレットを使用するか、データをDBCテーブルから別のデータベースにコピーし、(必要に応じて)データをアーカイブして、DBCテーブルから情報を削除することを推奨します。Viewpointパフォーマンス データの収集ポートレットの詳細については、PDCRログの自動メンテナンスの設定を参照してください。以下のDBCオブジェクトのパージを検討します。
  • ロギングを有効にしたリソース使用利用情報(ResUsage)テーブル
  • DBQLログ(ログを有効にしたすべてのDBQLテーブルを含む)

    (テーブルのDBC.DBQLRuleTblとDBC.DBQLRuleCountTblはログ保守リストには含まれません。これらのテーブルはTeradata SQLのBEGIN/END QUERY LOGGING文によって自動的に保守されるため、それらの内容を削除しようとするとエラーが戻されます。)

  • DBC.SW_Event_Log
  • QCD.DataDemographics (SQL COLLECT DEMOGRAPHICS文とともにQuery Capture Facility [QCF]を使用している場合は、ユーザー定義のQCDデータベース内のこのテーブルDataDemographicsから行を明示的に削除する必要があります)。
    DataDemographics内の項目は、INSERT EXPLAIN WITH STATISTICS AND DEMOGRAPHICS文を使用すると自動的に削除されます。詳細については、<Teradata Vantage™- SQLリクエストおよびトランザクション処理、B035-1142>の「Query Capture Facility(クエリー キャプチャ機能)」および<Teradata Vantage™ - SQLデータ操作言語、B035-1146>の「COLLECT DEMOGRAPHICS」を参照してください。
    Teradata Viewpointパフォーマンス データの収集ポートレットでは、このテーブルはアーカイブされません。
また、セキュリティ管理者は、必要に応じて、その他のセキュリティ関連ビューとともに、アクセス ロギングに関連するログを除去する必要があります。システム テーブルとログのサイズの保守に加え、次のようにログ ファイル サイズを減らすことができます。
  • 複数のResUsageテーブルのロギングを活動化する代わりに、DBC.ResUsageSpmaのみを使用する。ResUsageSpmaは、通常必要なすべての情報を提供できる。
  • ロールを使用して、DBC.AccessRightsのサイズを減らすために役立つ権限を管理する。DBC.AccessRightsテーブルのサイズを小さくするためのその他のヒントについては、不定期のハウスキーピングを参照してください。
  • DBQLに必要な情報のみを追跡させる。DBQLogTblは、通常必要なすべての情報を提供できる。
  • アカウンティングに必要な情報のみを追跡させる。
  • ResUsageテーブルに対して、できる限りアクティブな行フィルタ モードを使用する。

例えば、DBC.Acctgテーブルが大きくなり過ぎないようにする場合、必要レベルに応じて情報を報告するASE変数を調整します。ASEアカウンティングに&Tまたは&Iを使用すると、DBC.Acctgテーブルが非常に大きくなる傾向がありますが、&Dまたは&Lを使用すれば、通常ディスク領域への影響は比較的少なく、また十分な詳細レベルを維持できます。詳細については、拡張アカウント列の有効化を参照してください。