OpenText Vertica 23.3 – the Smarter Data Lakehouse

デリートベクターを手動で削除するか、または自動的に削除されないためにトラブルシューティングをする場合、このチェックリストが役立ちます。 ステップ タスク 結果 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...