フルリンクでは、異なるリクエストには対応するリクエストのパスがあります。完全なリクエストのパス（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の1つのトランザクションと理解できます。
- Span：特定のTraceに属し、1つのTraceには複数のSpanが存在できます。Spanはステートメント、関数、匿名ブロックなどになります。
- tag：KV。特定のSpanに属し、1つのSpanには複数のtagが存在できます。
- log：timestamp付きKV。特定のSpanに属し、1つのSpanには複数のlogが存在できます。
クライアント
アプリケーションはOBClientクライアントまたはJDBCドライバを使用してOceanBaseデータベースに接続します。 クライアント関連のSpanには、obclient と JDBC の2種類があります。
obclient：OBClientクライアントを使用したアクセス。JDBC：JDBCドライバを使用した接続。
クライアント関連のtagには、command_name と client_ip の2種類があります。OBClientとJDBCのtag情報は一致しています。
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は、response結果を全体として読み取る時間です。ob_proxy_cluster_resource_createは、OBProxyがリクエスト転送段階でクラスタリソースを準備する時間です。
レベル3
ここでは、ob_proxy_partition_location_lookup、ob_proxy_do_OBServer_open、ob_proxy_client_response_write、ob_proxy_server_request_write の4種類のSpanを定義します。
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、プリプロセスステートメント、ストアドプロシージャの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：プリプロセスステートメントの事前処理。
- ps_execute：プリプロセスステートメントの実行。
- ps_close：プリプロセスステートメントを閉じる。
- 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：現在のリクエストのログ内のtrace 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：preprocess statement ID。