アップグレード中に、またはアップグレード後の任意の時点で、すべてのデータベース テーブルがセグメント化されていることを確認します（まだの場合）。 セグメント化されていないデータベース テーブル予測が返される場合は、それらをセグメント化します。 また、アップグレードの後にいつでもデータベース テーブルをセグメント化することができます。
重要： データベース テーブルをセグメント化しない場合、Data Aggregator コンポーネントのアップグレード中に警告メッセージが表示されます。
テーブルをセグメント化することにより、データベースに必要なディスク容量を減らすことができます。 テーブルをセグメント化すると一般にクエリのパフォーマンスも向上します。 Data Aggregator および Data Collector が稼働している場合、またはこれらのコンポーネントがダウンしている場合のいずれもデータベース テーブルをセグメント化できます。
注： セグメント化はリソースを大量に消費するプロセスです。 Data Aggregator コンポーネントをアップグレードする前に、Data Aggregator および Data Collector がダウンしているときにデータベース テーブルをセグメント化することを強くお勧めします。 Data Aggregator および Data Collector の実行中にデータベース テーブルをセグメント化することはできますが、推奨していません。
Data Aggregator および Data Collector がダウンしている間にデータベース テーブルをセグメント化する場合、Data Aggregator コンポーネントをアップグレードする前に以下の情報を考慮してください。
重要： Data Aggregator が実行されていない場合でも、セグメント化のディスク使用率の合計が使用可能なディスク容量の 90 パーセントを超えることはできません。 セグメント化の間にディスク使用率が 90 パーセントを超える場合、それ以上テーブルは処理されません。
Data Aggregator コンポーネントをアップグレードした後、Data Aggregator および Data Collector の実行中にデータベース テーブルをセグメント化する場合は、以下の情報を考慮してください。
注： ここに記述したものがすべてではありません。
重要： データベース内のテーブルのセグメント化では、Data Aggregator が実行されている場合、使用可能なディスク容量の少なくとも 40 パーセントはクエリ処理および他のデータベース アクティビティ用に空いている必要があります。
セグメント化が完了した後、バックアップ用のディスク容量は、作成された新しいセグメント化テーブル予測でのデータ量の分だけ増加します。 セグメント化が完了した後、バックアップが実行される前に、使用可能なディスク容量が十分にあることを確認してください。
セグメント化されていない古いテーブル予測に対するバックアップ領域内のデータは、restorePointLimit （このエントリはバックアップ設定ファイル内にあります）の時間プラス 1 日が経過した後に削除されます。
古いデータが削除されるのにかかる時間を回避するには、バックアップ設定ファイル内のスナップショット名を変更し、セグメント化が完了した後にフル バックアップを実行します。 次に、古いバックアップをアーカイブし、バックアップ ディスクからバックアップを削除できます。 セグメント化が完了した後に作成されたバックアップを使用できない場合にのみ、セグメント化前のバックアップを使用してください。 セグメント化前のバックアップを使用する必要がある場合、テーブル予測を再度セグメント化する必要があります。
データベース テーブルのセグメント化の準備
データベース テーブルのセグメント化を準備するには、以下の手順に従います。
Data Repository をバックアップするには、以下の手順に従います。
backup_script_directory_location/backup_script.sh >/backup_directory_location/backup.log 2>&1
以下に例を示します。
/home/vertica/backup_script.sh >/tmp/backup.log 2>&1
注： Data Repository を自動的にバックアップするためにこのスクリプトを作成していた場合の詳細については、「CA Performance Management 管理者ガイド」を参照してください。
データのないデータベース テーブルをセグメント化するには、以下の手順に従います。
./segment.py --task zerotables --pass database_admin_user_password [--name database_name] [--port database_port]
Vertica Linux データベース管理者ユーザ パスワードを設定します。
データベースの名前を示します。 データベース名がデフォルトの drdata でない場合のオプションです。
Vertica に接続するために使用するポートを示します。 ポート番号がデフォルトの 5433 でない場合のオプションです。
データのないデータベース テーブルがセグメント化されました。
残りのデータベース テーブルをセグメント化するために必要な時間の量を判断するには、ベースラインを計算します。
./segment.py --task tables --pass database_admin_user_password [--name database_name] [--port database_port]
./segment.py --task segment --table rate_table_name --pass database_admin_user_password [--name database_name] [--port database_port]
注： このコマンドは、Data Aggregator の実行中に実行できますが、2 ～ 3 時間の保守ウィンドウ中にこのコマンドを実行することをお勧めします。
注： データベース テーブルをセグメント化するために必要となる実際の時間は、テーブル内のデータのタイプおよび圧縮に基づいて変わる可能性があります。 ここで計算されるのは概算の値です。 定期的な保守ウィンドウを計画する場合は、セグメント化される 10 ～ 15 GB のデータベース テーブルごとに余分な時間を追加してください。
大きなデータベースについては、データベース全体をセグメント化するために十分な長さのある保守ウィンドウを 1 回ではスケジュールできない可能性があります。 この場合、複数の保守ウィンドウにわたってデータベース テーブルをセグメント化することができます。
データベース テーブルのセグメント化
次の手順に従ってください：
./segment.py --task segment --pass database_admin_user_password --zerotables [--name database_name] [--port database_port]
Vertica Linux データベース管理者ユーザ パスワードを設定します。
データベースの名前を示します。 データベース名がデフォルトの drdata でない場合のオプションです。
Vertica に接続するために使用するポートを示します。 ポート番号がデフォルトの 5433 でない場合のオプションです。
以下に例を示します。
./segment.py --task segment --pass password --zerotables --name mydatabase --port 1122
./segment.py --task script --pass database_admin_user_password --lt100G [--name database_name] [--port database_port]
Vertica Linux データベース管理者ユーザ パスワードを設定します。
データベースの名前を示します。 データベース名がデフォルトの drdata でない場合のオプションです。
Vertica に接続するために使用するポートを示します。 ポート番号がデフォルトの 5433 でない場合のオプションです。
以下に例を示します。
./segment.py --task script --pass password --lt100G --name mydatabase --port 1122
nohup ./segment-script.sh
このスクリプトは、セグメント化されていない 100 GB 未満のテーブル予測をセグメント化し、小さい順に並べます。 出力は nohup.out に送信されます。 シェルが予期せず閉じられた場合、スクリプトの実効は継続されます。
実施されている保守ウィンドウのサイズ、および 100 GB 未満のテーブルのすべての合計サイズに応じて、保守ウィンドウでセグメント化されるテーブルを判断します。 データベース テーブルのセグメント化を準備したときに計算された概算時間に基づいて、保守ウィンドウ内に収まらないテーブルを削除することによって、生成されたスクリプトを変更します。 生成された segment-script.sh を保守ウィンドウ内で実行します。 100 GB 未満のテーブルのすべてを保守ウィンドウ内でセグメント化できなかった場合は、スクリプトを再生成して次の保守ウィンドウ内で segment-script.sh を実行し、テーブルがすべてセグメント化されるまで続けます。
重要： スクリプトを実行すると、ディスク使用率が 90 パーセントを超える原因となるテーブルにはエラー メッセージが表示され、それらのテーブルはセグメント化されません。 これらのテーブルをセグメント化するには、使用可能なディスク容量を増やす必要があります。
ディスク使用率が 60 パーセントを超える原因となる各テーブルごとにプロンプトが示されます。 これらのテーブルをセグメント化する前に、Data Aggregator をダウンさせることを強くお勧めします。
また、このスクリプトの実行には数時間かかる場合があることに注意してください。 いったん開始されたら、データベースの破損を回避するためにスクリプトの実行を中断しないでください。
./segment.py --task script --pass database_admin_user_password [--name database_name] [--port database_port]
Vertica Linux データベース管理者ユーザ パスワードを設定します。
データベースの名前を示します。 データベース名がデフォルトの drdata でない場合のオプションです。
Vertica に接続するために使用するポートを示します。 ポート番号がデフォルトの 5433 でない場合のオプションです。
以下に例を示します。
./segment.py --task script --pass password --name mydatabase --port 1122
重要： スクリプトが生成されると、ディスク使用率が 60 パーセントおよび 90 パーセントを超える原因となる可能性があるすべてのテーブルが示されます。
nohup ./segment-script.sh
このスクリプトは、未分割のテーブルをすべてセグメント化し、小さい順に並べます。
重要： スクリプトを実行すると、ディスク使用率が 90 パーセントを超える原因となるテーブルにはエラー メッセージが表示され、それらのテーブルはセグメント化されません。 これらのテーブルがセグメント化されるようにするには、使用可能なディスク容量を増やす必要があります。
ディスク使用率が 60 パーセントを超える原因となる各テーブルごとにプロンプトが示されます。 これらのテーブルをセグメント化する前に、Data Aggregator をダウンさせることを強くお勧めします。
このスクリプトは、データベース内の大規模なテーブルに実行する場合は数時間かかる可能性があります。 内部のセグメント化テストおよび顧客データベース テストでは、100 GB 以上のテーブルのセグメント化が完了するまでに 10 時間以上かかりました。 セグメント化の時間はテーブル サイズに対して一定ではありません。 行数、列数、データの圧縮、マシンの仕様などの多くの要因によって時間は変わります。 実施されている保守ウィンドウのサイズに応じて、保守ウィンドウごとのテーブルのセグメント化を計画します。
./segment.py --task tables --pass database_admin_user_password [--name database_name] [--port database_port]
以下の 内容のメッセージが表示されます。
セグメント化されていないテーブルはありません。
service dadaemon start
service dcmd start
前述の手順では、segment.py スクリプトの使用について、および環境をマイグレートする際のさまざまな考慮事項について簡単に説明しています。 スクリプトの使用に関してご不明な点がある場合、またはマイグレーションを計画する際にヘルプが必要な場合は、CA サポートまでお問い合わせください。
|
Copyright © 2014 CA Technologies.
All rights reserved.
|
|