データベースの性能が劣化した場合に、次のチェックリストを使用してトラブルシューティングを行います。 次のような問題が存在しないかどうか確認します。 ステップ タスク 結果 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...

デリートベクターを手動で削除するか、または自動的に削除されないためにトラブルシューティングをする場合、このチェックリストが役立ちます。 ステップ タスク 結果 1 プロジェクションでデリートベクターが多すぎるかどうか（100以上を目安）を確認します。 num_dvで確認できるデリートベクターの数が多すぎる（通常、100以上が目安）場合、Step 2 へ。 2 AHMやLGEが進んでいるかどうかを確認します。 AHMやLGEが進んでいる場合、Step 3 へ。 AHMやLGEが進んでいない場合、AHM（Ancient History Mark）が進まない場合の対処方法チェックリストを参照してください。 3 Step 1 で確認したエポックの番号が、Step 2 で確認したAHMよりも古いかどうかを確認します。 Step 1 のクエリの結果により、デリートされた行がAHMより新しいエポックの場合、Step 4 へ。 4 下記のコマンドでAHMを進めます。 次のいずれかを実行します。 パラメーターの値に基づき、mergeoutがデリートベクターを物理削除するのを待つ。 Step 5 に進み、手動でただちに削除する。 mergeoutが定期的に実行される際に、デリートベクターがを物理削除されるのを待っている場合、このチェックリストは完了です。 mergeoutでの削除を手動で実行開始する場合、Step 5 へ。 5 マークされたデリートベクターのパーセンテージがPurgeMergeoutPercentを満たすかどうかを確認します。この構成パラメータにより、、デリートベクターーがmergeout処理によって自動でpurgeされるタイミングが指可可能です。 PurgeMergeoutPercentを下記コマンドで確認します。 マークされたデリートベクターのパーセンテージを下記コマンドで確認します。 デリートベクターのパーセンテージがPurgeMergeoutPercentより大きく、ROSサイズが大きすぎない場合、下記2つの選択肢があります。 mergeoutがデリートベクターを物理削除するまで待つ。 purgeを強制実行するために、Step 5a へ。 デリートベクターのパーセンテージがPurgeMergeoutPercentより大きくないが、デリートベクターが大量に存在する場合、Step 5b へ。 デリートベクターのパーセンテージがテーブルの50％以上の行数占める場合、次のうちのいずれかを実行します。 purgeの強制実行 (Step 5a) 削除されていないデータのみを含むテーブルを新規作成 ( Step 5c) a. 次のうちいずれかを実行することにより、purgeを強制します。 AHMより古いエポックを持つ削除行を物理削除するために、PURGE_TABLE、もしくは、PURGE_PROJECTIONを実行する。 テーブルがパーティション化されていて、削除された行が特定のパーティションに集中している場合、PURGE_PARTITIONを実行する。 このチェックリストは完了です。...

データベースプロセスが起動していない場合、次のチェックリストを使用してトラブルシューティングを行います。 ステップ タスク 結果 1 Verticaプロセスがどのノード上でも実行されていないことを確認します。 Verticaプロセスは次のように表示されます。 続いてのチェックを行う前に、dbadminがカタログディレクトリとデータディレクトリの所有者であり、そのディレクトリにアクセスできることを確認してください。 Verticaプロセスがどのノード上でも実行されていない場合、Step 2 へ。 2 前回のデータベースの停止が正常に実行されたかどうかを確認します。 Epoch.logが存在する場合、データベース停止が正常に実行されたことが分かります。 データベース停止が正常に実行されていた場合、Step 3 へ。 データベース停止が正常に実施されていなかった場合、Verticaデータベースをまず起動してみてください。状態によっては、Last Good Epoch（LGE）でVerticaを起動するようにプロンプトが表示されることがあります。 3 パスワードなしのSSH接続で、すべてのノードが互いに接続可能であることを確認します。 接続が成功すると、最後のログインの日付、曜日、タイムスタンプ等の詳細情報が表示されます。 接続に失敗すると、パスワードを要求され、「No route to host」と表示されます。 パスワードなしのSSH接続で接続可能な場合、Step 4 へ。 SSH接続時にパスワード入力が必要な場合、Enable Secure Shell (SSH) Logins を参照してください。 4 spreadがすべてのノードと通信しているかどうかを確認します。 spreadが他のノードと通信している場合、Step 5 へ。 spreadが他のノードと通信していない場合、ノードがSpreadに接続できなくなった場合の対処方法チェックリストを参照してください。 5 他のアプリケーション等がVertica用のポートを使用していないかどうかを確認します。 他のプロセスがVertica用のポートにバインドされている場合、Verticaポートを保持しているすべてのプロセスを終了します。 6 次にあげるログ上でエラーがないか確認します。 a. Admintoolsログb. VerticaログとdbLogc. Spreadログ デフォルトでは、spreadログは無効化されています。spreadログを有効化するためには、spreadの設定ファイルを編集します。 d. ErrorReport.txt上のPANICエラー e. オペレーティングシステムログ f. カーネルログ 左記のログでエラーを確認した場合、解決します。 エラーを解決できない場合、scrutinizeログを取得し、Verticaテクニカルサポートまでお問い合わせください。 7 上記のエラーの対処後、データベースプロセスを起動します。 問題なくデータベースプロセスが起動する場合、チェックリストは完了です。 データベースプロセスが正常に起動しない場合、Step 8 へ。...

データベースノードが停止している場合、次のチェックリストを使用してトラブルシューティングを行います。 ステップ タスク 結果 1 データベースがUPの状態であるかどうか確認します。 データベースがUPの状態である場合、Step 2 へ。 データベースがUPの状態でない場合、データベースを再起動します。 データベースが起動すれば、このチェックリストは完了です。 データベースが起動しない場合、データベースプロセスが起動していない場合の対処方法チェックリストを参照してください。 2 DOWNしている全てのノードを確認します。 DOWNしている全てのノードを確認し、Step 3 へ。 3 DOWNしているノードとSSH接続可能かどうか確認します。 ノードにSSH接続できる場合、DOWNしているノード上のVerticaプロセスを再起動します。 無事再起動できたらチェックリストは終了です。 再起動に失敗した場合、Step4 へ。 ノードにSSH接続できない場合、ポートの問題またはネットワークの問題であるかどうかをシステム管理者に問い合わせてください。 4 再起動失敗の原因解析のために、DOWNしたノード上でstarup.logをtailコマンドで確認します。startup.logをtailすると、下記のような内容が確認できます。 ログからDOWNしたノードの最新の状態が確認できます。ノード状態の詳細を確認するために、Step 5 へ。 5 a. startup.logの出力が、「Waiting for cluster invite」という状態でとまっている場合 ノードがSpreadに接続できなくなった場合の対処方法チェックリストを参照してください。 b. startup.logの出力が、「Recovery stage」という状態でとまっている場合 ノードのリカバリ処理遅延の対処方法チェックリストを参照してください。 c. 「Data inconsistency problems found」というエラーメッセージが表示された場合、forceオプションを使用してノードを再起動します。 再起動して、チェックリストは完了です。 d. 前回の再起動後にstartup.logに新しいデータが表示されない場合、dbLogファイルにエラーが出力されていないかチェックしてください。 エラーを解決できない場合、Verticaテクニカルサポートまでお問い合わせください。 e. 「Shutdown Complete」が表示されたものの、ノードがまだDOWNしている場合、 tail vertica.logを実行し、<ERROR>と<PANIC>を探します。 ErrorReport.txtで出力されるPANICレポートとscrutinizeログを取得し、Verticaテクニカルサポートまでお問い合わせください。 関連詳細情報 Vertica Documentation  の Node Down...