データベースの運用中には、アプリケーションエラー、データベース接続エラー、データベース権限問題、データベースリソース問題、ネットワーク問題など、さまざまな異常状況が頻繁に発生します。これらすべてのケースの中で、アプリケーション例外というものがありますが、そのエラーメッセージにはOceanBaseのエラーコードが含まれています。
このようなシナリオにおいて、問題の根本原因を迅速に特定し、効率的に解決するために、ここでは明確かつ実用的なアプリケーション例外であり、エラーメッセージにOceanBaseエラーコードが含まれる場合のトラブルシューティングプロセスをまとめました。このプロセスは明確な操作手順を提供し、問題処理の効率を向上させ、業務への影響を可能な限り低減することを目的としており、日常的な運用保守作業を強力に支援します。
アプリケーション実行時にエラーが発生し、そのエラーメッセージにOceanBaseエラーコードが含まれる場合のトラブルシューティングプロセスは以下の図のとおりです。
プロセスの紹介
アプリケーションの実行時に異常が発生し、エラーメッセージにOceanBaseのエラーコードが含まれている場合は、このプロセスに従って問題のトラブルシューティングを行うことができます。
まず、OBClientを使用してデータベースに接続した後、手動で問題を再現できるかどうかを判断します。
はいの場合、問題の再現に成功したら、さらに調査を進めることができます。
いいえの場合、プログラム設定のデータソース情報を確認する必要があります。
問題の再現による問題の特定
OBClientを使用して、2881（SQLポート番号、デフォルトは2881ですが、カスタマイズされている場合は実際のポート番号に置き換えてください）でOceanBaseクラスタに接続します。
エラーが報告されたSQLを手動で実行し、問題シナリオを再現します。
以下のステートメントを実行して、trace_idを取得します。
注意
エラーが報告されたSQLを実行した後、直ちに以下のステートメントを実行する必要があります。そうしないと、エラーが報告されたSQLの
trace_idではないものが照会されます。MySQLモードOracleモードMySQLモードで
trace_idを取得するステートメントは次のとおりです：obclient> SELECT last_trace_id();Oracleモードで
trace_idを取得するステートメントは次のとおりです：obclient> SELECT last_trace_id() FROM DUAL;実際に実行されたSQLのホスト情報を取得します。
OceanBaseクラスタは通常複数ノードで構成されており、以下のSQLを使用して実際にSQLが実行されたノードを取得し、その後ログフィルタリングを行うことができます。
MySQLモードOracleモードMySQLモードでは、次のステートメントを実行します。
obclient> SELECT * FROM oceanbase.GV$OB_SQL_AUDIT WHERE trace_id=last_trace_id;ここで、
last_trace_idは前のステップで取得したtrace_idに置き換える必要があります。Oracleモードで以下のステートメントを実行します：
obclient> SELECT * FROM SYS.GV$OB_SQL_AUDIT WHERE trace_id=last_trace_id;ここで、
last_trace_idは前のステップで取得したtrace_idに置き換える必要があります。GV$OB_SQL_AUDITビューのクエリ結果によると、svr_ipに対応するホストが実際にそのSQLを実行したホストです。取得したホスト情報に基づいて、
sshコマンドを使用して対応するホストにログインします。ログが保存されているディレクトリに移動します。
以下は、OceanBaseデータベースのインストールディレクトリが
/home/admin/oceanbaseである場合の例です。ログの具体的な保存パスは、実際の環境に基づいてください。cd /home/admin/oceanbase/log以下のコマンドを実行して、ログ内の関連情報をフィルタリングします。
grep "${trace_id}" observer.loggrep "${trace_id}" observer.log.xxxここで、
${trace_id}は前のステップで取得したtrace_idに置き換える必要があります。observer.log.xxxはタイムスタンプ付きのログファイルであり、xxxはSQLエラーが発生した時間に基づいて実際のタイムスタンプに置き換える必要があります。ログから提供される情報と、関連するエラーメッセージなどを組み合わせて、問題を分析します。
ログに関する詳細は、ログの概要を参照してください。ログ内の情報が不明確な場合は、技術サポート担当者までお問い合わせください。
プログラム設定のデータソース情報
データソースに基づいてアクセスリンクを明確にします。
アクセスリンクには、以下の情報が含まれるアドレスの数を明確にします。
OBProxyの数とアドレス情報
OBServerホストの数とアドレス情報
OBProxyを経由するかどうかを判断します。
はい、OBProxyを経由する場合は、以下の手順でさらに調査を進めます：
sshコマンドを使用して、対応するOBProxyノードにログインします。cdコマンドを使用して、OBProxyのログディレクトリに移動します。OBProxyのログは、そのインストールディレクトリの/logディレクトリに保存されています。以下のコマンドを実行して、エラーログをフィルタリングします。
grep "エラーテキスト" obproxy_error.log obproxy_error.log.xxx | grep "エラー発生時点"フィルタリングされたログエントリに基づいて、エラーが発生したSQLがルーティングされたOBServerノードを特定します。
再び
sshコマンドを使用して、対応するOBServerノードにログインし、調査を続けます。
いいえ、OBProxyを経由しない場合は、以下の手順でさらに調査を進めます：
sshコマンドを使用して、対応するOBServerノードにログインします。ログが保存されているディレクトリに移動します。
以下は、OceanBaseデータベースのインストールディレクトリが
/home/admin/oceanbaseである場合の例です。ログの具体的な保存パスは、実際の環境に基づいてください。cd /home/admin/oceanbase/log以下のコマンドを実行して、エラーログをフィルタリングします。
grep "sending error" observer.log observer.log.xxx | grep "エラーコード'フィルタリングされたログに基づいて、trace_idを取得し、その後trace_idを使用してログをさらにフィルタリングします。
grep "trace id" observer.log observer.log.xxxログが提供する情報と関連するエラーメッセージなどを組み合わせて、問題を分析します。
ログに関する詳細は、ログの概要を参照してください。ログ内の情報が不明瞭な場合は、テクニカルサポート担当者に連絡して調査を支援してください。
よくあるケース
- 普通の業務テナントの一般ユーザーがOceanBaseデータベースのポート2881に直接接続しようとした際、
ERROR 1040 (08004): Too many connectionsというエラーが発生しました。具体的なトラブルシューティング手順については、一般ユーザー接続時にエラーERROR 1040 (08004): Too many connectionsが発生した場合を参照してください。