高可用性の章で説明したように、OceanBaseデータベースのデータリンクはAPPServer <-> OBProxy <-> OBServerです。APPServerはデータベースドライバーを通じてODPに接続し、リクエストを送信します。OceanBaseデータベースの分散アーキテクチャにより、ユーザーデータは複数のパーティションとレプリカに分かれて複数のOBServerに分散されています。ODPはユーザーのリクエストを最適なOBServerに転送して実行し、その結果をユーザーに返します。各OBServerにはルーティング転送機能も備えており、現在のノードでリクエストを実行できない場合は、正しいOBServerにリクエストを転送します。
エンドツーエンドのパフォーマンス問題が発生した場合（データベースのシナリオでは、エンドツーエンドとはアプリケーションサーバー上でSQLリクエストのRTが非常に高いことを指します）、まずはデータベースアクセスリンク上のどのコンポーネントに問題があるかを特定し、次にそのコンポーネント内の具体的な問題を調査する必要があります。
一般的には、以下の2つの調査手法があります：
ドリルダウン調査法
データアクセスの順序に従ってリンク上の各コンポーネントを順番に調査し、そのコンポーネントが下流のコンポーネントを呼び出す際の時間を観測し、さらに時間が著しく異常な（「時間のホットスポット」とも呼ばれる）下流のコンポーネントを調査します。本質的には、「地図に従って馬を探す」（再帰法）という考え方で、手がかりに従って段階的に掘り下げていき、根本原因のコンポーネントに近づけます。
ターゲット指向調査法
過去の経験に基づいて、最も頻繁に異常が発生するコンポーネントを調査し、そのコンポーネントの主要なSLA指標を観測して異常があるかどうかを判断し、次に調査するコンポーネントを決定します。本質的には、「除外法」（貪欲法）という考え方で、最初に最も頻繁に異常が発生するコンポーネントを調査し、徐々に除外していき、根本原因のコンポーネントに近づけます。
上記の図はデータベースアクセスリンクの簡略版ですが、注目すべき点として、上記の図で2つのコンポーネントがネットワークを介して相互にアクセスする場合、ネットワークもコンポーネントと見なすべきです。2つのコンポーネント間のネットワークに異常が疑われる場合は、ネットワークリンク上の各レベルのスイッチを調査する必要があります。ODPのデプロイ形態により、特にVPC間やクラウド間の長距離ネットワークアクセスについては、高度な注意を払う必要があります。
2つの調査手法に絶対的な優劣はなく、調査担当者は手元のツールの利便性や過去の調査経験に基づいて、最も効率的な調査手法を選択するべきです：
初めて稼働するビジネスリンクの場合、例えば一部の企業がハイブリッドクラウドデプロイモデルを採用し、一部のビジネスを自社データセンターからパブリッククラウドに移行する場合、アクセスリンクがクラウドをまたいでいるため、ドリルダウン調査法を選択するのが適しています。
成熟したビジネスリンクの場合、その中の一部のコンポーネントに変更がある場合、例えば大規模なプロモーションイベントやODPのアップグレードなど、ターゲット指向調査法を選択するのが適しています。
上記のシナリオに基づいて調査手法を選択するほか、エラーメッセージに基づいてボトルネックコンポーネントを正確に特定することもできますが、この方法は調査担当者の経験に大きく依存します。
一般的なエラースタックは上記の図のように、スタックは3層に分かれています。OBServerとODPについては詳述しませんが、アプリケーションサーバー部分について説明します。アプリケーションは通常、データミドルウェアを通じてデータベース接続を管理し、アクセス認証、接続ウォームアップ、接続プール化などの機能を含みます。データミドルウェアは通常、パッケージ形式でアプリケーションプログラムに導入され、両者の実行ログは通常別々になります。以下の文章では、アプリケーションプログラムとデータミドルウェアを区別せず、統一的にアプリケーション層と呼びます。
各層のコンポーネントのエラーは、自身の実行ログに出力されるだけでなく、上位層にもスローされ、上位層のコンポーネントの実行ログにも出力されます。したがって、特定の層でエラー情報が発生した場合、まずはどの層のエラーかを分析する必要があります。もし本層のコンポーネントがエラーをスローした場合は、本層から調査を開始する必要があります。もし下層のコンポーネントがエラーをスローした場合は、直接ターゲット層で調査を行うことができます。
以下では、各層の一般的なエラーについて説明します。ただし、各層のエラーはその層で発生するだけでなく、上位層にもスローされ、上位層の実行ログにも表示される可能性があることをご注意ください：
アプリケーションエラー
アプリケーションエラー「データベース接続プールが上限」
このエラーはアプリケーションシステムで最も一般的なエラーの一つであり、アプリケーションシステムのデータベース接続プールが上限で、新しいリクエストで接続を取得できないことを意味します。アプリケーションコードは通常、トランザクションを開始してデータベースにアクセスし、トランザクション内ではデータベースへのアクセスに加えて、他の下流システムへの呼び出しも行われます。例えば、下流のアプリケーションシステムやキャッシュなどです。トランザクション開始時に接続プールから接続を取得し、トランザクション終了時に接続を接続プールに返却します。接続プールが上限になるのは通常、トランザクションの実行時間が長すぎることが原因であり、トランザクションの実行時間が長すぎる原因を調査する必要があります。これは、データベースリクエストのRTが高いことに加えて、他の下流システムへのアクセス時間が長すぎることや、アプリケーションシステム自体の問題などによって引き起こされる可能性があります。
他の下流システムの実行時間が長すぎる：RPCを通じて下流システムを呼び出す時間が長すぎるため、トランザクション全体の時間が長くなります。その中で、データベースシステムへのアクセス時間は正常です。
アプリケーションシステム自体：アプリケーションシステム自体のfullgcやCPUがフル稼働によるシステムのカクつきが原因で、トランザクション全体の時間が長くなります。その中で、データシステムへのアクセス時間は正常です。
アプリケーションエラー「データベース接続に失敗」
アプリケーションシステムがOBServerに接続に失敗したことを意味します。これは、バックエンドのデータベースシステムがリクエストによってフル稼働し、接続構築に失敗したことによる可能性があるほか、アプリケーションシステム自体の問題（例えばfullgcが発生した場合、アプリケーションサーバーのNICに異常がある場合、アプリケーション層のデータベース設定に誤りがある場合など）、あるいはアプリケーションサーバーとOBServer間のネットワーク異常などによって引き起こされる可能性があります。
アプリケーションエラー「ロック競合」
アプリケーションシステムが特定のデータベースオブジェクトにロックをかける際にロック競合イベントが発生したことを意味します。アプリケーションシステムは通常、ロックメカニズム（悲観的ロックまたは楽観的ロック）を通じて、同一オブジェクトへの同時アクセスを制御します。ロック競合は強いアプリケーションセマンティクスを持ち、データベースシステムのRTが急激に高くなることによってアプリケーションシステムが大量にタイムアウトしてリトライするだけでなく、アプリケーションシステム自体から原因を探る必要があります。例えば、スケジューリングシステムの異常によって同一オブジェクトに対する大量の同時操作が発生した場合や、特定のハッカー攻撃などです。
OBProxyエラー
OBProxyエラー
ERROR 1317 (70100): Query execution was interruptedクライアントが積極的にクエリを中断したことを意味します。通常、クライアントが送信したSQLリクエストが予想されるタイムアウト時間内に返されなかった場合、またはユーザーが
Ctrl + Cを使用して積極的にKill Queryを実行した場合に発生します。本番環境でこのエラーが大量に発生する場合、アプリケーション視点から見たSQLの実行時間がクライアントのタイムアウト時間（Query Timeout）を超えていることを意味し、クライアントからOBserverまでの各コンポーネントを調査する必要があります。
OBServerエラー
OBServerエラー
ERROR 4012 (HY000): Timeout, query has reached the maximum query timeoutSQLリクエストがOBServer内部での処理時間がサーバー側のタイムアウト時間（
ob_query_timeout）を超えたことを意味します。これは、OBServer内部に異常があることを直接特定できます。ob_query_timeoutはSQLの最大実行時間を設定するために使用され、単位はマイクロ秒です。この変数の詳細については、ob_query_timeoutを参照してください。
注意
上記で説明したエラーメッセージに基づいてコンポーネントを正確に特定する方法は、各コンポーネントのバージョンによって異なる場合があり、調査担当者の経験の蓄積に大きく依存します。調査担当者は特定のバージョンに応じて、一連の調査手法を蓄積する必要があります。