フルリンクでは、異なるリクエストには対応するリクエストのパスが存在します。完全なリクエストパス（Trace）は、複数のリクエストプロセス（Span）で構成されており、OceanBaseデータベースでは内部処理の各プロセスを1つのSpanとして定義しています。リクエストパスはツリー構造として理解でき、親ノードSpanとそれに対応する子ノードSpanを含みます。この情報はトレースログ（trace logs）に出力され、parent_id と id によって親子ノードが関連付けられます。同時に、trace logsには各リクエストプロセスの実際に実行されたSQL情報が含まれており、これをtagと呼びます。異なるtagを用いて現在の操作の詳細情報を記録します。Spanとtagはtrace logsに記録され、運用保守担当者がデータベース内部の処理ロジックを理解し、問題の所在を特定するのに役立ちます。 アクセスパス全体を3つの部分に分けて紹介します。
重要な概念
- Trace：エンドツーエンドのトレースプロセスにおいて、TraceはOceanBaseのトランザクションと理解できます。
- Span：特定のTraceに属し、1つのTraceには複数のSpanが存在できます。Spanはステートメント、関数、匿名ブロックなどになり得ます。
- tag：KV（Key-Value）。特定のSpanに属し、1つのSpanには複数のtagを付けることができます。
- log：timestampを含むKV（Key-Value with timestamp）。特定のSpanに属し、1つのSpanには複数のlogを記録することができます。
クライアント
アプリケーションは、OBClientクライアントまたはJDBCドライバを使用してOceanBaseデータベースに接続します。 クライアント関連のSpanには、obclientとJDBCの2種類があります。
obclient：OBClientクライアントを使用したアクセス。JDBC：JDBCドライバを使用した接続。
クライアント関連のタグには、command_nameとclient_ipの2種類があります。OBClientとJDBCのタグ情報は一致しています。
command_nameは、テキスト、prepare、executeなど、さまざまなタイプのリクエストを識別するために使用されます。client_ipは、リクエストを送信したobclientのIPアドレスとポートを識別するために使用されます。
OBProxy
この段階では、3つのレベルのSpanが定義されています。ここでのレベルは、DBMS_MONITOR のTrace関連関数における変数levelに対応しています。
レベル1
ここでは2種類のSpan、ob_proxyとob_proxy_server_process_reqを定義します。
ob_proxyはOBProxyが1つのSQLを処理するための全時間です。つまり、OceanBaseデータベースのフロントエンドドライバ層を除いた、データベースリクエストの開始からデータ処理完了、結果フィードバックまでの全リンクの時間です。ob_proxy_server_process_reqは、OBProxyが1つのSQLリクエストを処理する時間と、アクセスの往復にかかるネットワークオーバヘッドです。
レベル2
ここでは2種類のSpan、ob_proxy_server_response_readとob_proxy_cluster_resource_createを定義します。
ob_proxy_server_response_readは、レスポンス結果を読み取る全体的な時間です。ob_proxy_cluster_resource_createは、OBProxyがリクエスト転送段階でクラスタリソースを準備する時間です。
レベル3
ここでは4種類のSpan、ob_proxy_partition_location_lookup、ob_proxy_do_OBServer_open、ob_proxy_client_response_write、ob_proxy_server_request_writeを定義します。
ob_proxy_partition_location_lookupは、OBProxyがリクエスト転送段階でパーティションロケーションを取得し、ルーティングを準備する時間です。ob_proxy_do.Observer_openは、OBProxyがリクエスト転送段階でOBServerを選択し、接続するプロセスの時間です。ob_proxy_client_response_writeは、OBProxyがOBServerからのレスポンスを受信した後、そのレスポンスをクライアントに転送する時間です。ob_proxy_server_request_writeは、OBProxyがクライアントリクエストをOBServerに転送する時間です。
OBServer
Span
OBServer内部の処理メカニズムでは、配信されたリクエストをリクエストタイプに応じてテキストSQL、preprocess statement、ストアドプロシージャの3種類に分類します。さらに、これら3種類の中にはトランザクション、内部SQL、およびデータベース内部に格納されるアクセスが含まれます。
下図は異なるリクエストタイプのアクセスパスであり、Span間の親子関係が示されています。例：Span mpquery_single_stmt の親Spanは com_query_entry です。Span com_query_entry の子Spanは mpquery_single_stmt です。
関連するspanの説明は以下のとおりです：
- com_query_entry：クエリプロセス。
- mpquery_single_stmt：単一ステートメントのアクセスパス。
- sqlCompile：SQLのコンパイル。
- pc_get_plan：実行計画の取得。
- hard_parse：ハードパース。
- parse：ソフトパース。
- resolve：構文木の意味を解析し、ステートメントを生成。
- rewrite：SQLのリライト。
- optimize：コストベースの最適化を行い、実行計画ログを生成。
- code_generate：実行計画ログに基づいて物理実行計画を生成。
- pc_add_plan：生成された実行計画をplan cacheに追加。
- sql_execute：物理実行計画を実行。
- open：実行計画を開く。
- response_result：実行計画のプロセスと結果。
- px_schedule：pxに従ってタスクを分割。
- px_task：pxサブタスクを実行。
- close：実行計画を閉じる。
- cmd_execute：コマンドを実行。
- cmd_open：cmd計画を開始。
- ps_prepare：preprocess statementの事前処理。
- ps_execute：preprocess statementの実行。
- ps_close：preprocess statementを閉じる。
- pl_entry：ストアドプロシージャの処理。
- pl_compile：ストアドプロシージャオブジェクトのコンパイル。
- pc_get_pl_object：plan cacheからストアドプロシージャオブジェクトを取得。
- pc_add_pl_object：ストアドプロシージャオブジェクトをplan cacheに保存。
- pl_execute：ストアドプロシージャを実行。
- pl_spi_query：ストアドプロシージャ内のspiステートメントを実行。
- pl_spi_prepare：ストアドプロシージャの事前処理段階。
- pl_spi_execute：ストアドプロシージャ内のspiステートメントを実行。
- inner_prepare：内部SQLの事前処理段階。
- inner_execute：内部SQLの実行段階。
- inner_execute_read：内部SQLの読み取り。
- inner_execute_write：内部SQLの書き込み。
- inner_commit：内部SQLトランザクションのコミット。
- inner_rollback：内部SQLトランザクションのロールバック。
関連タグの紹介
一部のSpanの情報を豊かにするため、以下のようなタグが定義されています。
- com_query_entry
- log_trace_id：現在のリクエストのログ内のトレースID。
- err_code：現在のリクエストのエラーコード。
- sql_compile。
- sess_id：セッションID。
- sql_text：SQLテキスト。
- sql_id：SQL ID。
- hit_plan：実行計画が実行計画キャッシュにヒットした場合。
- px_task
- task_id：並列タスクの論理ID。
- dfo_id：データフロー操作ID。
- sqc_id：サブクエリコーディネーターID。
- qc_id：クエリコーディネーターID。
- group_id：リソースグループID。
- px_schedule
- dfo_id：データフロー操作ID。
- used_worker_cnt：使用中のPXワーカースレッドの数。
- qc_id：クエリコーディネーターID。
- ps_close
- ps_id：プリプロセスステートメントID。