OpenText Vertica 23.3 – the Smarter Data Lakehouse

メンテナンスのためにVerticaノードをシャットダウンする必要がある場合、このチェックリストが役立ちます。 ステップ タスク 結果 1 すべてのノードがUPであることを確認します。 シャットダウン後の長時間にわたるノードリカバリを避けるには、1つ以上のノードが停止している場合、Restarting Vertica on a Host 内の説明にしたがって、なるべく早く検知し、再起動します。 2 ノードを再起動できない場合、 AHMが長い間進んでいないかどうか確認します。 デリートベクター数を確認します。 AHMが長時間保持されていて、デリートベクター数が多く、また、複数のテーブルにまたがっている場合、ノードリカバリが遅延する可能性があります。 この場合、ノードリカバリのチェックリスト内の手順に従います。 次の内容があてはまるとします。 データの3％以上に影響を与える削除や更新を行っています。 ノードが長い間停止しています。 多くの更新と削除を行うステージングテーブルがある場合、ノードをリカバリする前にテーブルを削除します。 最後の選択肢は、次のコマンドでAHMを強制的に進めることです。 続いて、停止ノードをリカバリすると、Verticaはバディーノードからデータをコピーすることによって、そのノードを初期状態からリカバリします。 3 ノードの依存関係を確認します。 想定するノード依存関係の場合、（ノードの数 + 1）行をリストします。 ノードの依存関係が正しい場合、Step 4 へ。 ノードの依存関係が正しくない場合、クラスター内のデータをリバランスします。 クラスターで再度リバランスを実行してもノードの依存関係が正しくない場合、Verticaテクニカルサポートまでお問い合わせください。 4 データの損失を避けるために、データベースをバックアップします。 より詳細な情報については、Backing Up the Database をご確認ください。Creating Hard-Link Local Backups に記載があるように、ハードリンクのバックアップを使用して、バックアップ処理をスピードアップすることを検討してください。 バックアップが成功した場合、Step 5 へ。 バックアップが完了しない場合、データベースが停止している場合は、コールドバックアップまたはオフラインバックアップを実行します。 これを行うには、カタログディレクトリとデータディレクトリを別の場所にコピーします。 Vertica 7.2.xおよびそれ以前の場合： Vertica 8.0.x以降の場合： 5 データベースをシャットダウンする準備をします。 a. セッションの最大数の設定内容を表示します。...

7.2.x以降を使用している場合、テーブルごとにリカバリを実行してください。詳細については、Vertica Documentation の Recovery By Table を参照ください。 7.1.xより前のVerticaバージョンを使用している場合、ETLジョブ等の更新処理を行う処理を停止してノードリカバリを再開してください。 ステップ タスク 結果 1 リカバリの進捗状況をモニターします。 「is_running = f」 の場合、リカバリは完了しています。 このステートメントを繰り返し実行し、current_completedの値が増加しているかどうかを確認します。増加している場合、リカバリが進行中であることを意味します。 リカバリは進行中ですか？ リカバリが進行していない場合、Step 3 へ。 リカバリが進行している、あるいは、終了している場合、Step 2 へ。 2 ノードリカバリは正常に完了しましたか？ 正常に完了している場合、チェックリストは完了です。 正常に完了しておらず、リカバリがエラーで終了している場合、Step 6 へ。 3 リカバリは予想よりも遅いですか？ 遅くない場合、Step 4 へ。 遅い場合、次の内容を実施します。 iostatを使用し、ディスクI/Oをチェックします。問題がある場合、ディスクI/Oスケジューラをdeadline（HDDの場合）あるいはnoop（SSDの場合）に変更します。 同時に実行されているクエリの数が最大数、あるいはそれに近いかどうかを確認します。 「max_concurrency = running_query_count」の場合、クエリのロードが非常に高いと言えます。 a. MAXCONCURRENCY の増加 b. リカバリの再開 c. Step 1 へ 4 リカバリは特定のテーブルでとまっているように見えますか？ 特定のテーブルでとまっていない場合、Step 6 へ。 特定のテーブルでとまっている場合、ノードがリカバリ中であるかどうか確認します。 「node_state=RECOVERING」の場合、ノードリカバリが進行中であることが分かります。 5 ノードがリカバリのHistoricalフェーズにあるかどうかを確認します。 「historical_completed」の値が、「historical_total」の値よりも小さい場合、ノードはHistoricalフェーズにあるといえます。Verticaがストレージコンテナを隣接ノードからコピーしているフェーズとなります。 「historical_complete...

ノードがSpreadに接続されていない場合、次のチェックリストを使用してトラブルシューティングを行います。 ステップ タスク 結果 1 カタログフォルダ内のspread.confファイルが、クラスター内のすべてのノードで同一であるかどうかを確認します。 spread.confファイルがすべてのノードで同一の場合、 Step 2 へ。 すべてのノードでspread.confファイルが同一でない場合、次の手順を実施します。 正しいspread.confファイルを確認します。ファイルには、すべてのクラスターノードのIPアドレスが含まれているはずです。 正しいspread.confファイルをscpを使用してすべてのノードにコピーします。 2 spreadのポート（デフォルトは4803）が次のいずれかを使用してリスニングしているかどうかを確認します。 もしくは クラスター内の各ノードには、それぞれのspreadのポートがあります。クラスター内のspreadによって使用されるポートを確認するには、次の手順を実行します。 /database_catalog_directory/spread.conf 内で確認する。 「Spread_Segment 192.168.40.255:4803」のようなSpread_Segmentの行のIPの後の内容（この場合、4803）を確認する。 spreadがリスニングしていない場合、Step 3 へ。 spreadがリスニングしている場合、Step 4 へ。 3 ファイアウォールが有効になっていないことを確認します。 ファイアウォールが有効になっている場合、ファイアウォールを無効にするか、ネットワーク管理者にポートを開くように依頼してください。 4 /etc/hosts ファイルにクラスターのすべてのIPアドレスが含まれているかどうかを確認します。 ファイルがクラスターのすべてのIPアドレスを含んでいて正しい内容の場合、Step 5 へ。 ファイルが正しくない場合、クラスター内のすべてのノードを含めるように/etc/hostsファイルを修正し、Step 5 へ。 5 UDP受信パケットにエラーが含まれていないかどうかを確認します。 UDP受信パケットにエラーが含まれる場合、該当システムのシステム管理者に相談して問題を解決してください。 UDP受信パケットにエラーが含まれていない場合、Step 6 へ。 6 spuserを使用して、spreadのグループが形成されているかどうかを確認します。 a. クラスター内のすべてのノード上で次のコマンドを実行します。 b. 次のコマンドを実行します。 c. 前の手順で見つかったメンバーの数がノードの数と一致することを確認します。 ノードの数が一致する場合、spreadは接続されているはずであり、チェックリストは完了です。 ノードの数が一致しない場合、このチェックリストを再度たどって、別のパスを探します。 メンバーの数が継続してノードの数と一致しない場合、Verticaテクニカルサポートまでお問い合わせください。 関連詳細情報 Vertica Documentationの Spread や、Vertica Knowledge Baseの Spread Debugging で詳細情報が確認できます。

Verticaクラスターにノードを追加したり、クラスターからノードを削除したりすると、Verticaはすべてのノード上でデータのリバランスを実施します。リバランスに長時間を要する場合、これらの手順を参照して原因を調べます。 前提条件 リバランスを開始する前に、クラスターの正常なリバランスを確実に行うために、以下のステップを実行してください。 1. ETLジョブと競合しない時間帯にリバランスをスケジューリングします。 2. データベースをバックアップします。 3. 古い、あるいは、未使用のテーブルパーティションを削除します。 4. ローカルセグメンテーションが無効であることを確認します。ローカルセグメンテーションが無効になっていない場合、このコマンドを実行して無効にします。 5. vioperfとvnetperfを使用して、CPUとネットワークの帯域幅をそれぞれ確認します。 使用可能な帯域幅が初期ベンチマークの値よりも小さい場合、システム管理者に連絡して、性能が低下している原因となる問題を見つけて修正してください。 6. リバランスを実行するために、データベースのサイズの少なくとも40％のストレージが使用可能であるかどうかを確認します。ストレージの使用状況を確認するには、次のクエリを実行します。 Linuxファイルシステムで使用可能なディスク容量を確認します。 HOST_RESOURCESシステムテーブルから各ノードのスナップショットを取得します。 ストレージが不足している場合、カタログサイズを縮小するための手順を実行してください。 不要なデータ、一時的なデータ、ステージングデータを削除する。 ログファイルをクリーンアップする。 不要なテーブルまたはパーティションを削除する。 新しいドライブを追加し、ストレージのロケーションを追加し、一部のカタログオブジェクトを新しいロケーションに移行する。 リバランスの間に使用される一時スペース用の一時格納領域を追加する。 ビルトインのREFRESHリソースプールの設定を確認します。 必要に応じて、リバランス処理が滞りなく実行できるように、リソースプール設定を調整します。 7. リバランス対象のテーブルに対するDML処理（COPY、INSERT、UPDATE、DELETE）を最小限に抑えます。リバランスがテーブルのロックを保持している場合、ロードは失敗します。ロードがテーブルをロックしている場合、リバランスは一時停止します。 リバランスがETLジョブと競合していると考えられる場合、LockTimeout値を増やしてください。デフォルト値は、300秒（5分）です。 8. Purging Deleted Data の説明にしたがって、DeleteされたデータをPurgeします。 9. クラスターに追加するホストを構成します。 10. ホストをクラスターに追加します。 11. データベースにノードを追加します。 注意：詳細については、Managing the Database を参照してください。 12. リバランスを途切れることなく実行するには、DMLCancelTMパラメーターをfalseに設定して、リバランスプロセスを優先します。 これで、リバランス処理を開始する準備が整いました。ここでは、リバランスを開始し、プロセスが正常に完了するのをモニタリングするための手順を示します。 Rebalancing Data Using SQL Functions の説明に従って、リバランスを開始します。 ステップ タスク 結果 1...

データベースホストがまだ稼働中で、電源がオンの場合、Verticaストレージにアクセスできなくなることがあります。Verticaが停止している可能性があり、データやカタログのディスクボリュームが使用できません。 次のチェックリストを使用してトラブルシューティングを行います。 ステップ タスク 結果 1 ホストが再起動した際に、ファイルシステムの自動マウントに問題はありましたか？ 問題があった場合、 手動でそれらをマウントします。 /etc/fstabにエントリーを追加して、次のサーバーのブート時に自動マウントするようにします。 Linuxのログで、ディスクの障害やエラーの可能性があるかどうかを確認します 問題がなかった場合、Step 2 へ。 2 ハードウェアまたはディスクの障害のために、1つあるいは複数のディスクがオフラインになっていますか？ 該当する場合、RAIDセットとハードウェアコントローラーでエラーとメッセージを確認してください。複数のディスク障害がないかチェックします。 該当しない場合、Step 3 へ。 3 ハードウェアのRAID保護の設定、たとえば、RAID 0となっているなど、設定が間違っていないですか？ 間違っている場合、ハードウェアRAID保護の設定、RAID 1+0またはRAID 5を使用してRAIDセットを再構築します。 障害が発生したホストのデータは、K-safetyがデータベースに設定されている場合にのみ、別のVerticaホストから復元できます。 間違っていない場合、Step 4 へ。 4 ディスクボリュームの修復が必要ですか？ 修復が必要な場合、fsckを実行します。 修復が必要でない場合、Step 5 へ。 5 もっと情報が必要ですか？ 情報が必要な場合、 追加情報とエラーについては、/var/log/messagesを確認します。 製造元のディスクユーティリティ（ハードウェアコンソール）をチェックして、構成を検証し、エラーを確認します。 情報が必要でない場合、Step 6 へ。 6 ディスクエラーのためにディスクが「読み取り専用」でマウントされていますか？ 該当する場合、システム上のデータ保護が有効化されています。Verticaは、読み取り専用のファイルシステムを持つホスト上では起動せず、失敗します。 ディスクを再マウントするか、読み取り専用のファイルシステムの原因となるエラーを修正してください。 該当しない場合、Verticaテクニカルサポートまでお問い合わせください。 関連詳細情報 Vertica Documentation の Restart Vertica on a Node をご参照ください。

状況： 応答時間が遅い サーバーはCPU負荷が高く、プロセスが多すぎる ホストがハングしている可能性があり、接続できない、あるいは、接続がハングしている可能性がある 考えうる原因： 利用可能なメモリが少ない 実行中の同時実行プロセスが多すぎる サーバーがスワップ領域を積極的に使用している 次のチェックリストを使用してトラブルシューティングを行います。 ステップ タスク 結果 1 Vertica以外のプロセスまたはアプリケーションが実行されているかどうかを確認します。 ホストの稼働時間を確認するか、Linuxコマンドを使用して、プロセス、メモリ使用量、およびCPU稼動のリストを表示します。 uptimeの結果は、それぞれ直近の1分、5分、15分のシステムの平均負荷を表しています。 サーバーのアクティビティを表示するその他のコマンドは次の通りです。 top コマンドは、詳細なリアルタイムCPUアクティビティ、メモリ使用量、および現在実行中のプロセスの詳細を表示します。 Vertica以外のプロセスまたはアプリケーションが実行されている場合、可能であれば、それらのプロセスを他のサーバーに移動してVerticaデータベースホストへの影響を減らします。 該当しない場合、Step 2 へ。 2 メモリが少なく、スワップ領域を積極的に使用しているかどうかを確認します。 2a. top コマンドを使用して、使用可能なメモリーとスワップ領域の使用状況を表示します。top コマンドの出力により、メモリの使用状況が、以下のように表示されます。 2b. 認識されている総メモリ（16,333,388k）と使用メモリ量（4,355,992k）を確認できます。 スワップの使用領域は、例のように0である必要があります。 スワップの使用領域の値が0以外の場合、スワップ動作を意味し、ホストの低速応答の考えうる原因の1つとなりえます。 個々のプロセスの場合、top コマンドは各プロセスのメモリ使用量を返します。 この内容が、誤って構成されたアプリケーションを識別するのに役立ちます。 スワップの使用領域が0の場合、 このホスト上で実行中のワークロードを評価し、同じクラスター内の他のVerticaホストと比較します。 ワークロードとユーザー接続のバランスを取ります。 ハードウェア構成とメモリサイズを確認します。 他のアプリケーションがVerticaホスト上でメモリを消費していないか確認します。それらを他のサーバーに移動することを検討してください。 2c. 各Verticaホストで、vm.swappiness の値を1に設定します。 デフォルト値は60です。というのも、システムがスワップディスク上のスペースを容易に使用するためです。 値が1の場合、ディスクへのスワップを最小限におさえます。 rootで、値を1に変更します。 vm.swappiness の値が1の場合、Step 3 へ。 2d. 設定を確認します。 3 セキュリティおよびオペレーティングシステムのパッチが最新のものかどうかを確認します。オペレーティングシステムのパッチは、yum コマンドを使用してインストールできます。 3a. 最新のパッチをダウンロードしてインストールするには、次のコマンドを実行します。...

このチェックリストでは、Verticaクラスターの各メンバーをホストと呼びます。 Verticaプロセスは、クラスター内の他のVerticaノードと通信します。ノードは、Verticaデータベースソフトウェアを参照します。 ホストが停止している場合、次のチェックリストを使用してトラブルシューティングを行います。 ステップ タスク 結果 1 Verticaホストが物理的に電源オフになっています。サーバーの前面に、ステータスのライトがありません。 電源まわりで問題はありますか？ チェックすべき項目： サーバーの電源障害 UPSバッテリー サイトの停電 ラックの電源障害 問題がある場合、各コンポーネントの障害のためにホストの電源がオフになっていることが考えられます。 Step 2 に進み、停電の原因を特定し、解決します。 2 次のようなハードウェアのいずれかが原因でホストがクラッシュしましたか？ ディスク、あるいは、ディスクコントローラー CPU メモリ ネットワークアダプター 該当する場合、問題を解決してください。その後、Step 6 へ。 該当しない場合、Step 3 へ。 3 次のいずれかが原因の温度過熱の問題はありますか？ 十分な冷却が足りておらず、その結果、高温状態でシャットダウンが発生 データセンターの冷却問題 ラック内の通気不足 換気の遮断 問題がある場合、該当する問題を解決してください。その後、Step 6 へ。 問題がない場合、Step 4 へ。 4 既知のクラッシュまたは障害の時刻を記録します。 Step 5で記録された障害の発生時刻を使用して、クラッシュの根本原因を特定します。 5 Step 4の障害発生時刻を使用して、次のログファイルで障害とその原因を確認します。 ブートログ：/var/log/boot.log Linuxログ（通常のシャットダウン、電源オフ、ハードウェア障害）：/var/log/messages ハードウェアコンソールログ。コンソールマネージャーからログを確認 これらのログファイルの情報は、障害の原因を特定するのに役立ちます。 将来の障害を防ぐために、問題解決にあたります。 問題を解決するために必要に応じてVerticaテクニカルサポートまでお問い合わせください。 6...

Verticaホストが物理的に利用できる状態で、オペレーティングシステムが稼動していてもVerticaクラスターへのネットワークにアクセスできない場合、外部からの接続ができないことが考えられます。クライアントソフトウェアの接続に失敗し、ユーザーはホストにsshできない状態で、ハードウェアのコンソール接続を確認すると、ホストがまだ稼動しているように見えるとします。 次のような問題が存在しないかどうかを確認します。 ステップ タスク 結果 1 NETWORK_USAGEシステムテーブルから初期情報を取得します。 NETWORK_USAGEシステムテーブルに関する情報を取得したら、Step 2 に進みます。 2 デフォルトのルートIPアドレス、あるいは、ルーターアドレスにpingする際に問題がありますか？ 問題がある場合、ルーターはダウンしているか、または誤って構成されています。ルーターを再設定して再起動してください。該当システムのネットワーク管理者に相談してください。 問題がない場合、Step 3 へ。 3 ファイアウォールが有効になっていますか？ 有効になっている場合、ファイアウォールを無効にして設定を確認し、Step 4 へ。 有効になっていない場合、設定を確認し、Step 4 へ。 4 ファイアウォール設定がVerticaが必要とするポートをブロックしていますか？ デフォルト設定を使用し、Verticaが必要とするポートをブロックすると、ファイアウォールの問題が発生することがあります。 ポートをブロックしている場合、次のコマンドを実行してファイアウォールを無効にします。 ポートをブロックしていない場合、Step 5 へ。 5 使用中のネットワークポートを確認します。 Verticaでは、次のネットワークポートが必要となります。 22 TCP：管理ツール 5433 TCP/UDP：Verticaクライアント（vsql, ODBC, JDBC など） 5434 TCP：クラスター内通信 5444 TCP：Verticaマネージメントコンソール 5450 TCP：Verticaマネージメントコンソールウェブアクセス 4803 TCP：Spreadクライアント接続 4803 UDP：Spreadデーモン間接続 4804 UDP：Spreadデーモン間接続 6543 UDP：デーモン接続に対するSpreadモニター 一部のポートがブロックされている場合、Verticaが必要とするポートの一覧とファイアウォール上でオープンしているポートを確認します。 ポートのブロックに問題ない場合、Step 6 へ。 6...

以前は高速で実行されていたクエリの実行が遅くなり始めましたか？ 次のチェックリストを使用し、以前は高速に実行されていたクエリの性能が突然低下した原因を調べます。 ステップ タスク 結果 1 次のコマンドを使用して、ホストのエラーメッセージを確認します。 $ dmesg クラスターの状態が良好な場合、Step 2 へ。 クラスターの状態が良好でなく、エラーメッセージが表示された場合は、システム管理者に連絡してください。 サーバー上の問題が解決したら、このチェックリストの次に進みます。 2 次のコマンドを使用して、全ノードのクラスター設定を確認します。 クラスターが正しく設定されていない場合、Verticaのドキュメントへのリンクを含むエラーのリストを表示します。リンク先の内容を確認し、エラーを解決してください。 エラーが表示されない場合、Step 3 へ。 3 クラスターの状態を確認する前にデータベースを停止します。 データベースが正常に停止した場合、Step 4 へ。 それ以外の場合、検証スクリプトを実行し、Step 4 へ。 4 クラスターのネットワーク性能を確認します。 ディスクI/Oの性能を確認します。 CPUの性能を確認します。 ネットワーク、ディスクI/O、およびCPUのパフォーマンスの結果を調べ、Step 5 へ。 5 EXPLAINステートメント、あるいは、EXPLAIN LOCAL VERBOSEステートメントを実行し、出力結果を確認し、異常である可能性がある点を特定します。 統計情報が不足しているというメッセージが表示された場合、Step 6 へ。 期待される結合順序で表示されない場合、Step 7 へ。 現在のプランと古いプランを比較することで、実行計画の変更を確認できます。新しいプランが以前より悪くなっている場合、Verticaテクニカルサポートまでお問い合わせください。古いプランが確認できない、あるいは、異常が見られない場合、Step 8 へ。 6 次のコマンドを使用して、EXPLAINで確認した実行計画の内容から、統計情報が欠落していると判別したテーブルに対して、統計情報を更新します。 統計取得が完了したら、Step 5を繰り返し、計画が変更されているか、あるいは、異常がある可能性がある別の点が発生していないかどうかを確認します。 詳細情報については、Verticaドキュメントの ANALYZE STATISTICS を参照ください。 7 新しい結合順序がより効率的である場合、Verticaはクエリを分析してクエリの結合順序を変更します。 クエリの結合順序が変更されている場合、SYNTACTIC_JOINヒントを使用して結合順序を強制できます。ヒントは結合順序を強制し、他の結合のヒントを有効にします。 クエリオプティマイザーのヒントを使用して、クエリのパフォーマンスを向上させる必要がある場合、Verticaテクニカルサポートにお問い合わせいただき、以前より悪くなっている点について報告してください。 8 リアルタイムでプロファイリングすることにより、実行中の長時間実行クエリをモニターすることができます。 クエリ性能の劣化原因を特定するために、クエリをプロファイルしてください。クエリ実行のプロファイリングについてのより詳細な情報については、Vertica Knowledge Baseの System...

データベースの性能が劣化した場合に、次のチェックリストを使用してトラブルシューティングを行います。 次のような問題が存在しないかどうか確認します。 ステップ タスク 結果 1 特定のクエリの性能が遅いですか？ 特定のクエリの性能が遅い場合、クエリの性能が突然低下した場合の対処方法チェックリストを参照します。 特定のクエリの性能が遅くない場合、 Step 2 へ。 2 データベース全体が遅いですか？ データベース全体が遅い場合、 Step 3 へ。 データベース全体が遅くない場合、このチェックリストは完了です。 3 全ノードが起動しているかどうか確認します。 任意のノードがDOWNしている場合、 ノードが停止している理由について調査を行うために、 データベースノードが停止した場合の対処方法チェックリストを確認します。 ノードを再起動します。 ノードが再起動し、性能が向上した場合、このチェックリストは完了です。 ノードが再起動したが、性能がまだ遅い場合、 Step 4 へ。 ノードが再起動しない場合、 データベースノードが停止した場合の対処方法チェックリストへ。 4 大量のデリートベクターが存在していないかどうか確認します。 1000以上のデリートベクターが存在する場合、デリートベクターの対処方法チェックリストを参照します。 それほど多くのデリートベクターが存在しない場合、Step 5 へ。 5 エポックが進んでいるかどうか確認します。 エポックが進んでいない場合、AHM（Ancient History Mark）が進まない場合の対処方法チェックリストを参照します。 エポックが進まない場合、Step 6 へ。 6 任意のノードが他のノードよりも遅延していないかどうか確認します。 クラスター内の各ノード上でSELECT文を実行し、遅いノードを特定します。 任意のノードが他のノードよりも遅い場合、 ホストの性能の問題について調査します。 該当のノード上のVerticaプロセスを再起動します。 起動: 停止: 全てのノードが同様の性能である場合、Step 7 へ。 7 ワークロードがすべてのノード上でバランスがとれている状態かどうか確認します。 ひとつのノードのワークロードがより高い場合、全てのノード上にワークロードが分散するようにします。 Load balancing のドキュメンテーションの内容を参照してください。 ワークロードのバランスがとれている場合、Step 8 へ。...

カタログのサイズが10 GBを超えるか、あるいは、カタログが1日あたり5％を超えて増えている場合、カタログサイズが大きいといえます。 このチェックリストには、データベースカタログのサイズをモニタリング、および、削減するための提案事項と推奨事項が記載されています。 データベースカタログには、テーブル、プロジェクション、ユーザー、ノード、ROSなどのメタデータが含まれています。 カタログには2種類のオブジェクトがあります。 グローバルオブジェクトはノード固有ではありません。グローバルオブジェクトには、テーブル、ユーザー、およびノードが含まれます。 どのノードもクエリのイニシエーター（実行開始ノード）として機能するため、グローバルオブジェクトは全ノード上に完全に複製されます。 ローカルオブジェクトはノード固有です。ローカルオブジェクトには、ROS、WOS、および依存関係が含まれます。ストレージレイアウトはノードによって異なる可能性があるため、ローカルオブジェクトは複製されません。各ノード上で、独立してストレージレイアウト情報を保持します。 ノード起動時に、カタログはメモリ上にキャッシュされます。 ステップ タスク 結果 1 全ノード上のカタログサイズを確認します。 大規模なカタログサイズで徐々にサイズが増加していて、データベースのパフォーマンスに影響する可能性がある場合は、Vertica 7.2.3-15以上にアップグレードすることを検討してください。または、このチェックリストを使用してカタログサイズ肥大化の原因を特定してください。 メモリ上のカタログサイズがメモリ全体の5％未満で、Verticaのパフォーマンスが許容範囲である場合、ここでこのチェックリストは完了です。 カタログサイズが5％以内であるが10GBを超える場合は、このチェックリストを使用し、大きなカタログサイズの根本原因を特定してください。このチェックリストの内容を確認し、カタログサイズを縮小することを検討してください。 2 カタログが増加しているかどうかを確認し、データベースにオブジェクトが多すぎるかどうかを確認するには、次のクエリを使用します。   カタログサイズが大きく、オブジェクトが多数ある場合、不要なオブジェクトを減らすことを検討してください。次の方法でオブジェクトを削減できます。 使用していないオブジェクトを削除する。 オブジェクトの依存関係を減らす。例えば、JOIN、WHERE句、およびGROUP BYによって使用される列の統計情報のみ取得する。 オブジェクト数が削減できない場合、リソースプールを調整するために、Step 12 へ。 オブジェクトが多くない場合、Step 3 へ。   3 デリートベクターの増加により、カタログサイズの増大しているかどうかを確認します。 多数のデリートベクターがある場合は、デリートベクターの削除を検討してください。より詳細情報は、デリートベクターの対処方法チェックリストを参照してください。 デリートベクターを削除することにより、メモリ上のカタログサイズを小さくすることが可能です。 デリートベクターを削除後、カタログサイズを縮小するために、データーベースあるいはノードを再起動する必要があります。 大量のデリートベクターがない場合、Step 4 へ。 4 ROSコンテナが大量にあるかどうかを確認します。 ROSコンテナ数が多い場合、Step 5 へ。ROSコンテナが多すぎるプロジェクションを確認します。 Verticaテクニカルサポートにお問い合わせいただければ、カタログが大きい原因について詳細に分析することも可能です。 5 より多くのROSコンテナを保持するプロジェクションを特定します。 大量のROSコンテナを持つプロジェクションが大量にあるが、ROS数の平均が300未満である場合、Step 11 へ。 それほど大量のプロジェクションは無いが、ROS数の平均が500以上の場合、Step 6 へ。 6 テーブルの設計方法に基づいて、パーティションが多すぎるかどうかを確認します。 該当のテーブルがパーティション化されていない、あるいは、パーティション数が600未満の場合、Step 7 へ。 一意のパーティションIDが大量にあるプロジェクションが存在する場合、プロジェクションごとにより少ないパーティション数になるようにテーブルのパーティションキーを変更するために、Step 7 へ。 7...