データベース テーブルのセグメント化

Data Aggregator のアップグレード時にテーブルのセグメント化警告を受信した場合は、Data Repository 上のデータベース テーブルをセグメント化します。 テーブルのセグメント化は 1 回限りのタスクであり、元のインストールがリリース 2.3.3 より前のシステムに必要です。 テーブルをセグメント化することにより、データベースに必要なディスク容量を減らすことができます。 テーブルをセグメント化すると一般にクエリのパフォーマンスも向上します。
capm280
Data Aggregator のアップグレード時にテーブルのセグメント化警告を受信した場合は、Data Repository 上のデータベース テーブルをセグメント化します。 テーブルのセグメント化は 1 回限りのタスクであり、元のインストールがリリース 2.3.3 より前のシステムに必要です。 テーブルをセグメント化することにより、データベースに必要なディスク容量を減らすことができます。 テーブルをセグメント化すると一般にクエリのパフォーマンスも向上します。
データベースにセグメント化が必要かどうかがわからない場合は、スクリプトをダウンロードし、セグメント化に必要なテーブルの識別を試行します。 セグメント化が完了済みまたは不要の場合、スクリプトはいずれのテーブルも返しません。
Data Aggregator および Data Collector が稼動または停止しているときにデータベース テーブルをセグメント化できます。
セグメント化はリソースを大量に消費するプロセスです。 データベース テーブルをセグメント化する場合は、Data Aggregator および Data Collector が停止しているときに行うことを強くお勧めします。
データベース内の大規模なテーブルのセグメント化には数時間かかる場合があります。 テスト中、100 GB を超えるテーブルの移行には 10 時間以上かかりました。 セグメント化の時間はテーブル サイズに対して一定ではありません。 行数、列数、データの圧縮、システムの仕様などの多くの要因によって時間は変わります。
Data Aggregator および Data Collector が停止している場合、インフラストラクチャ環境のアクティブな監視は発生しません。
Data Aggregator の稼動中にデータベース テーブルをセグメント化する場合は、以下の制限が適用されます。
  • Data Aggregator 管理機能を実行しないでください。
    • 監視プロファイルの変更
    • 監視プロファイルへのコレクションの関連付け
    • ポーリング レートの増加
    • 新しいディスカバリの実行
  • レポートの負荷を最小限に抑えます。
以下のプロセスを使用して、データベース テーブルをセグメント化します。
セグメント化が必要なテーブルの識別
テーブルのセグメント化を開始する前に、セグメント化が必要なテーブルを識別します。
以下の手順に従います。
  1. CA サポートから segment.py スクリプトをダウンロードします。この手順では、segment.py スクリプトが Vertica Linux データベース管理者ユーザのホーム ディレクトリにあると仮定します。
  2. Vertica Linux データベース管理者ユーザとして Data Repository クラスタ内の任意のホストにログインします。
  3. スクリプトを実行します。
    ./segment.py --task tables --pass
    database_admin_user_password
    [--name
    database_name
    ] [--port
    database_port
    ]
    • database_admin_user_password
      Vertica Linux データベース管理者ユーザ パスワード
    • database_name
      データベースの名前
      デフォルト:
      drdata
      このパラメータでは、大文字と小文字が区別されます。
    • database_port
      Vertica ポート
      デフォルト:
      5433
    例:
    ./segment.py --task tables --pass password
    -
    -name
    mydatabase
    現在セグメント化されていないすべてのテーブル予測値が、大きい順に並べられて返されます。 いずれかのテーブルにセグメント化が必要な場合は、このプロセスを続行します。
Data Repository のバックアップ
テーブルをセグメント化する前に、Data Repository をバックアップします。
セグメント化後に、バックアップのディスク領域が、新しいセグメント化されたテーブル予測のデータの量によって増加します。 セグメント化が完了した後、バックアップが実行される前に、バックアップ システムに使用可能なディスク領域が十分にあることを確認してください。
古いセグメント化されていないテーブル予測のデータは、restorePointLimit の時間後の 1 日にバックアップ データから削除されます。 このデータをすぐに削除するには、バックアップ設定ファイル内のスナップショット名を変更し、フル バックアップを実行します。 次に、古いバックアップをアーカイブし、バックアップ ディスクからバックアップを削除できます。 セグメント化が完了した後に作成されたバックアップを使用できない場合にのみ、セグメント化前のバックアップを使用してください。 セグメント化前のバックアップを使用する場合、テーブルにはセグメント化が再度必要になります。
詳細については、「Data Repository のバックアップ」を参照してください。
データのないテーブルのセグメント化
日付なしのテーブルが迅速にセグメント化されますが、セグメント化はパフォーマンスに悪影響を及ぼしません。 Data Aggregator を停止せず、これらのテーブルをセグメント化できます。
以下の手順に従います。
  1. Vertica Linux データベース管理者ユーザとして Data Repository クラスタ内の任意のホストにログインします。
  2. スクリプトを実行します。
    ./segment.py --task segment --zerotables --pass
    database_admin_user_password
    [--name
    database_name
    ] [--port
    database_port
    ]
    • database_admin_user_password
      Vertica Linux データベース管理者ユーザ パスワード
    • database_name
      データベースの名前
      デフォルト:
      drdata
      このパラメータでは、大文字と小文字が区別されます。
    • database_port
      Vertica ポート
      デフォルト:
      5433
    このスクリプトは、データのないデータベース テーブルをセグメント化します。
テーブルのセグメント化の時間を決定する
Data Aggregator が稼動中か停止中にテーブルをセグメント化するかどうかを決定するには、セグメント化に必要な時間を計算します。
以下の手順に従います。
  1. セグメント化が必要なテーブルのリストを取得します。
    ./segment.py --task tables --pass
    database_admin_user_password
    [--name
    database_name
    ] [--port
    database_port
    ]
    database_name
    パラメータでは大文字と小文字が区別されます。
    リストはテーブルが大きい順に並べられます。
  2. セグメント化が完了するまで、スケジュールされた Data Repository バックアップを無効にします。 バックアップはセグメント化プロセスの邪魔になる可能性があります。
  3. サイズが約 5 GB のテーブルを手順 1 から選択し、そのテーブルをセグメント化します。
    ./segment.py --task segment --table
    rate_table_name
    --pass
    database_admin_user_password
    [--name
    database_name
    ] [--port
    database_port
    ]
    database_name
    パラメータでは大文字と小文字が区別されます。
    このコマンドは Data Aggregator の実行中に実行できますが、2 ~ 3 時間の保守ウィンドウ中にこのコマンドを実行することをお勧めします。
  4. スケジュールされた Data Repository のバックアップを再度有効にします。
  5. 5 GB のテーブルのセグメント化に要した時間から、100 GB 未満のすべてのテーブルをセグメント化するために要する時間を判断します。
    データベース テーブルのセグメント化にかかる実際の時間は、テーブル内のデータのタイプおよび圧縮に基づいて変わる可能性があります。 ここで計算されるのは概算の値です。 スケジュールされた保守ウィンドウを計画する場合は、10 ~ 15 GB のデータベース テーブルごとに、1 時間追加してください。 大規模なデータベースについては、データベース全体をセグメント化するために十分な長さの保守ウィンドウを 1 回ではスケジュールできない可能性があります。 この場合、複数の保守ウィンドウにわたってデータベース テーブルをセグメント化することができます。
残りのデータベース テーブルのセグメント化
残りのテーブルをセグメント化します。
データベース内のテーブルのセグメント化では、Data Aggregator が実行されている場合、使用可能なディスク領域の少なくとも 40 パーセントはクエリ処理および他のデータベース アクティビティ用に空いている必要があります。 Data Aggregator が実行されていない場合でも、セグメント化時のディスク使用率の合計が使用可能なディスク領域の 90 パーセントを超えることはできません。 セグメント化の間にディスク使用率がこの制限を超える場合、それ以上テーブルはセグメント化されません。
以下の手順に従います。
  1. Vertica Linux データベース管理者ユーザとしてData Repository がインストールされているクラスタ内のコンピュータの 1 つにログインします。
  2. 前の手順でのテーブル予測セグメント化の検証中に、10 を超えるゼロ レングス テーブル予測が検出された場合は、以下のコマンドを入力してそれらをセグメント化します。
    ./segment.py --task segment --pass database_admin_user_password --zerotables [--name database_name] [--port database_port]
    • database_admin_user_password
      Vertica Linux データベース管理者ユーザ パスワード
    • database_name
      データベースの名前
      デフォルト:
      drdata
      このパラメータでは、大文字と小文字が区別されます。
    • database_port
      Vertica ポート
      デフォルト:
      5433
    例:
    ./segment.py --task segment --pass password --zerotables --name mydatabase --port 1122
  3. サイズが 100 GB を超えるテーブル予測がある場合は、以下のコマンドを入力し、最初に 100 GB 未満であるテーブル予測をセグメント化するスクリプトを作成します。
    ./segment.py --task script --pass database_admin_user_password --lt100G [--name database_name] [--port database_port]
    • database_admin_user_password
      Vertica Linux データベース管理者ユーザ パスワード
    • database_name
      データベースの名前
      デフォルト:
      drdata
      このパラメータでは、大文字と小文字が区別されます。
    • database_port
      Vertica ポート
      デフォルト:
      5433
    例:
    ./segment.py --task script --pass password --lt100G --name mydatabase --port 1122
  4. セグメント化が完了するまで、スケジュールされたバックアップを無効にします。 バックアップはセグメント化プロセスの邪魔になる可能性があります。
  5. segment-script.sh スクリプトを実行するには、以下のコマンドを入力します。
    nohup ./segment-script.sh
    このスクリプトは、セグメント化されていない 100 GB 未満のテーブル予測をセグメント化し、小さい順に並べます。 出力は nohup.out に送信されます。 シェルが予期せず閉じられた場合、スクリプトは引き続き実行されます。
    保守ウィンドウのサイズおよびすべての 100 GB 未満のテーブルの合計サイズに応じて、保守ウィンドウでセグメント化されるテーブルを判断します。 保守ウィンドウ内に適合しないテーブルを削除することによって生成されたスクリプトを変更します。 生成された segment-script.sh を保守ウィンドウ内で実行します。 100 GB 未満のテーブルのすべてを保守ウィンドウ内でセグメント化できなかった場合は、スクリプトを再生成し、テーブルがすべてセグメント化されるまで次の保守ウィンドウ内で segment-script.sh を実行します。
    スクリプトを実行すると、ディスク使用率が 90 パーセントを超える原因となるすべてのテーブルにエラー メッセージが表示されます。 これらのテーブルはセグメント化されません。 これらのテーブルをセグメント化するには、使用可能なディスク容量を増やす必要があります。
    ディスク使用率が 60 パーセントを超える原因となる可能性のある各テーブルごとにプロンプトが示されます。 これらのテーブルをセグメント化する前に、Data Aggregator を停止させることを強くお勧めします。
    このスクリプトの実行には数時間かかる場合があります。 いったん開始されたら、データベースの破損を回避するためにスクリプトの実行を中断しないでください。
  6. さらにセグメント化が必要で、今後の保守ウィンドウで実行される場合にのみ、スケジュールされたバックアップを再度有効にします。
  7. 100 GB を超える残りのテーブル予測をセグメント化する、segment-script.sh スクリプトを生成します。
    ./segment.py --task script --pass database_admin_user_password [--name database_name] [--port database_port]
    • database_admin_user_password
      Vertica Linux データベース管理者ユーザ パスワード
    • database_name
      データベースの名前
      デフォルト:
      drdata
      このパラメータでは、大文字と小文字が区別されます。
    • database_port
      Vertica ポート
      デフォルト:
      5433
    例:
    ./segment.py --task script --pass password --name mydatabase --port 1122
    スクリプトが生成されると、ディスク使用率が 60 パーセントおよび 90 パーセントを超える原因となる可能性があるすべてのテーブルが示されます。
  8. スケジュールされたバックアップを無効にします(まだの場合)。
  9. segment-script.sh スクリプトを実行するには、以下のコマンドを入力します。
    nohup ./segment-script.sh
    このスクリプトは、未分割のテーブルをすべてセグメント化し、小さい順に並べます。
  10. すべてのテーブルがセグメント化できるようになったことを確認します。
    ./segment.py --task tables --pass
    database_admin_user_password
    [--name
    database_name
    ] [--port
    database_port
    ]
    database_name
    パラメータでは大文字と小文字が区別されます。
    次のメッセージが表示されます。
    No tables found with unsegmented projections.
  11. スケジュールされたバックアップを再度有効にします。
  12. Data Aggregator および Data Collector が停止しているときにデータベース テーブルをセグメント化した場合は、これらのコンポーネントを起動します。