Vertica Blog
Soniya Shah

Soniya Shah

Information Developer

Currently, a first year law student with a background in science and technology. Experienced technical writer, with specializations in software documentation, big data, blog development, and website development. I build user-centered content to communicate complex and technical information more easily.

I used to work for Vertica full time for about 3 years. I still work at Vertica part time while going to law school.

Update: Soniya is now doing her law internship, and no longer working at Vertica. Good luck, Soniya!

Connect With Soniya on

Verticaホストのネットワーク接続に問題がある場合の対処方法

Verticaホストが物理的に利用できる状態で、オペレーティングシステムが稼動していてもVerticaクラスターへのネットワークにアクセスできない場合、外部からの接続ができないことが考えられます。クライアントソフトウェアの接続に失敗し、ユーザーはホストにsshできない状態で、ハードウェアのコンソール接続を確認すると、ホストがまだ稼動しているように見えるとします。 次のような問題が存在しないかどうかを確認します。 ステップ タスク 結果 1 NETWORK_USAGEシステムテーブルから初期情報を取得します。 NETWORK_USAGEシステムテーブルに関する情報を取得したら、 に進みます。 2 デフォルトのルートIPアドレス、あるいは、ルーターアドレスにpingする際に問題がありますか? 問題がある場合、ルーターはダウンしているか、または誤って構成されています。ルーターを再設定して再起動してください。該当システムのネットワーク管理者に相談してください。 問題がない場合、 へ。 3 ファイアウォールが有効になっていますか? 有効になっている場合、ファイアウォールを無効にして設定を確認し、 へ。 有効になっていない場合、設定を確認し、 へ。 4 ファイアウォール設定がVerticaが必要とするポートをブロックしていますか? デフォルト設定を使用し、Verticaが必要とするポートをブロックすると、ファイアウォールの問題が発生することがあります。 ポートをブロックしている場合、次のコマンドを実行してファイアウォールを無効にします。 ポートをブロックしていない場合、 へ。 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が必要とするポートの一覧とファイアウォール上でオープンしているポートを確認します。 ポートのブロックに問題ない場合、 へ。 6 DNS設定エラーが発生しましたか? エラーが発生している場合、 ホスト名の代わりにIPアドレスを使用してみてください。 pingコマンドを使用して接続を確認します。host.domain名、あるいは、IPアドレスを使用します。 エラーが発生していない場合、 へ。...

クエリの性能が突然低下した場合の対処方法

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

データベースの性能が劣化した場合の対処方法

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

カタログサイズ肥大化の対処方法

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

デリートベクターの対処方法

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

データベースプロセスが起動していない場合の対処方法

データベースプロセスが起動していない場合、次のチェックリストを使用してトラブルシューティングを行います。 ステップ タスク 結果 1 Verticaプロセスがどのノード上でも実行されていないことを確認します。 Verticaプロセスは次のように表示されます。 続いてのチェックを行う前に、dbadminがカタログディレクトリとデータディレクトリの所有者であり、そのディレクトリにアクセスできることを確認してください。 Verticaプロセスがどのノード上でも実行されていない場合、 へ。 2 前回のデータベースの停止が正常に実行されたかどうかを確認します。 Epoch.logが存在する場合、データベース停止が正常に実行されたことが分かります。 データベース停止が正常に実行されていた場合、 へ。 データベース停止が正常に実施されていなかった場合、Verticaデータベースをまず起動してみてください。状態によっては、Last Good Epoch(LGE)でVerticaを起動するようにプロンプトが表示されることがあります。 3 パスワードなしのSSH接続で、すべてのノードが互いに接続可能であることを確認します。 接続が成功すると、最後のログインの日付、曜日、タイムスタンプ等の詳細情報が表示されます。 接続に失敗すると、パスワードを要求され、「No route to host」と表示されます。 パスワードなしのSSH接続で接続可能な場合、 へ。 SSH接続時にパスワード入力が必要な場合、 を参照してください。 4 spreadがすべてのノードと通信しているかどうかを確認します。 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 上記のエラーの対処後、データベースプロセスを起動します。 問題なくデータベースプロセスが起動する場合、チェックリストは完了です。 データベースプロセスが正常に起動しない場合、 へ。 8 a. ノードがLGEを検出できない場合、データベースの状態はLost Contactに変更され、admintoolsは、「Recovery after unclean shutdown」といった内容を示すでしょう。こちらの詳細については、 内の  を参照ください。 b. それでもデータベースを起動できない場合、データが破損あるいは失われている可能性があります。場合によっては、Verticaは、データが失われている状態、あるいは一部失われている状態であっても、起動することができます。それが受け入れ可能な場合は、次のコマンドを使用します。...

データベースノードが停止した場合の対処方法

データベースノードが停止している場合、次のチェックリストを使用してトラブルシューティングを行います。 ステップ タスク 結果 1 データベースがUPの状態であるかどうか確認します。 データベースがUPの状態である場合、 へ。 データベースがUPの状態でない場合、データベースを再起動します。 データベースが起動すれば、このチェックリストは完了です。 データベースが起動しない場合、チェックリストを参照してください。 2 DOWNしている全てのノードを確認します。 DOWNしている全てのノードを確認し、 へ。 3 DOWNしているノードとSSH接続可能かどうか確認します。 ノードにSSH接続できる場合、DOWNしているノード上のVerticaプロセスを再起動します。 無事再起動できたらチェックリストは終了です。 再起動に失敗した場合、 へ。 ノードにSSH接続できない場合、ポートの問題またはネットワークの問題であるかどうかをシステム管理者に問い合わせてください。 4 再起動失敗の原因解析のために、DOWNしたノード上でstarup.logをtailコマンドで確認します。startup.logをtailすると、下記のような内容が確認できます。 ログからDOWNしたノードの最新の状態が確認できます。ノード状態の詳細を確認するために、 へ。 5 a. startup.logの出力が、「Waiting for cluster invite」という状態でとまっている場合 チェックリストを参照してください。 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テクニカルサポートまでお問い合わせください。 関連詳細情報  の  をご参照ください。

Query Tuning with Vertica: Dos and Don’ts

This blog post was authored by Eugenia Moreno. Query tuning in Vertica is not an exact science. Recommendations differ based on your database. This document assumes that all nodes in the cluster are UP, your Vertica configuration is ok, and that v*perf tools have been executed. The following diagram shows the query flow in Vertica:...
Programmer

Saving an Apache Spark DataFrame to a Vertica Table

Before you save an Apache Spark DataFrame to a Vertica table, make sure that you have the following setup: • Vertica cluster • Spark cluster • HDFS cluster. The Vertica Spark connector uses HDFS as an intermediate storage before it writes the DataFrame to Vertica. This checklist identifies potential problems you might encounter when using...

Why is Vertica not Ingesting Data From Kafka?

Prerequisite: Verify that Vertica is up and running. If you want to troubleshoot why Vertica is not ingesting data from Kafka, follow this checklist. Step Task Results 1 Check whether Kafka is up and running. a. Examine the server log files for broker errors: If there are errors, consult the Kafka documentation. b. Examine the...

Rebalance Taking a Long Time

After you add a node to your Vertica cluster or remove a node from your cluster, Vertica rebalances the data across all the nodes. If rebalancing is taking a long time, review these steps to find out the probable cause. Pre-Requisites To ensure a successful rebalance of your cluster, before you start the rebalance, take...

Storage not Accessible and Vertica Fails to Start on Host

When the database host is still up and available and the power is on, Vertica storage may be inaccessible. Vertica may be down and the disk volumes /data and /catalog are unavailable. To troubleshoot, follow this checklist: Step Task Results 1 When the host rebooted, was there a problem auto-mounting the file systems? If yes,...