OceanBaseデータベースのエンドツーエンド・トレース機能は、クライアントからOBProxy、さらにOBServerまでの全リンク各段階での処理時間および各コンポーネントの診断に関連するTrace情報を記録できます。ここで、Trace Logが記録する最小単位はSpanであり、各Spanは特定の実行区間またはモジュールの開始から終了までの時間および関連情報（Tags）を記録できます。これにより、運用保守担当者はデータベース内部の処理ロジックを理解し、問題の原因を特定するのに役立ちます。
SpanとTagの定義
SpanとTagはob_trace_def.hファイルで定義されており、HIGH（Level 1）、MIDDLE（Level 2）、LOW（Level 3）の3つのレベルに分かれています。ここで、HIGHがデフォルトの設定レベルであり、これはデフォルトでLevel 1に対応するSpanとTagが出力されることを意味します。他のレベルのSpanとTagを出力する必要がある場合は、制御コマンドを使用してTrace Level値を引き上げる必要があります。Level 2のSpanは、ユーザーが問題を分析する際により多くのSpan情報を得るために使用でき、Level 3 Spanは主にOceanBaseデータベースの開発診断時により詳細な情報を得るために使用されます。設定されたLevel値がNの場合、TraceはLevel <= NのSpanとTagを出力します。
Spanの定義は以下のとおりです：
#define HIGH_LEVEL_SPAN
DEF_SPAN(span_type, comment)
#undef HIGH_LEVEL_SPAN
#define MIDDLE_LEVEL_SPAN
DEF_SPAN(span_type, comment)
#undef MIDDLE_LEVEL_SPAN
#define LOW_LEVEL_SPAN
DEF_SPAN(span_type, comment)
#undef LOW_LEVEL_SPAN
Tagの定義は以下のとおりです：
#define HIGH_LEVEL_TAG
DEF_SPAN(tag_type, comment)
#undef HIGH_LEVEL_TAG
#define MIDDLE_LEVEL_TAG
DEF_SPAN(tag_type, comment)
#undef MIDDLE_LEVEL_TAG
#define LOW_LEVEL_TAG
DEF_SPAN(tag_type, comment)
#undef LOW_LEVEL_TAG
関連する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：コマンドの開始。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トランザクションのロールバック。
関連するTagの紹介は以下のとおりです：
com_query_entrylog_trace_id：現在のリクエストのログ内のTrace ID。err_code：現在のリクエストのエラーコード。
sql_compilesess_id：セッションID。sql_text：SQLテキスト。sql_id：SQL ID。hit_plan：実行計画が実行計画キャッシュにヒットしたことを示すビット。
px_tasktask_id：パラレルタスクの論理ID。dfo_id：データフロー操作ID。sqc_id：サブクエリコーディネータID。qc_id：クエリコーディネータID。group_id：リソースグループID。
px_scheduledfo_id：データフロー操作ID。used_worker_cnt：使用中のPXワーカースレッドの数。qc_id：クエリコーディネータID。
ps_closeps_id：Preprocess Statement ID。
Traceログの例
運用保守担当者は、必要に応じてPL/SQLパッケージDBMS_MONITORの関連メソッドを使用し、アプリケーションのさまざまな識別情報の観点からエンドツーエンドのトレースを有効にするかどうか、およびそのトレースのイベント記録と関連情報をTraceログに出力するポリシーを制御できます。ログの出力は、サンプリング頻度に基づいてサンプリングされメモリに記録されるかどうかが判断され、一定の確率でTraceログに出力されます。詳細については、エンドツーエンドトレースを参照してください。 例：
+-------------------------------------------+----------------------------+------------+
| Operation | StartTime | ElapseTime |
+-------------------------------------------+----------------------------+------------+
| com_query_process | 2023-03-22 14:30:27.552259 | 0.405 ms |
| └── mpquery_single_stmt | 2023-03-22 14:30:27.552266 | 0.386 ms |
| ├── sql_compile | 2023-03-22 14:30:27.552283 | 0.083 ms |
| │ └── pc_get_plan | 2023-03-22 14:30:27.552286 | 0.025 ms |
| └── sql_execute | 2023-03-22 14:30:27.552379 | 0.242 ms |
| ├── open | 2023-03-22 14:30:27.552380 | 0.024 ms |
| ├── response_result | 2023-03-22 14:30:27.552417 | 0.140 ms |
| │ ├── get_das_id | 2023-03-22 14:30:27.552421 | 0.000 ms |
| │ └── do_local_das_task | 2023-03-22 14:30:27.552435 | 0.049 ms |
| └── close | 2023-03-22 14:30:27.552570 | 0.039 ms |
| ├── close_das_task | 2023-03-22 14:30:27.552571 | 0.012 ms |
| └── end_transaction | 2023-03-22 14:30:27.552596 | 0.003 ms |
+-------------------------------------------+----------------------------+------------+
12 rows in set (0.006 sec)