OceanBaseデータベースは、特定のSQLリクエストに関連するログを検索する機能をサポートしています。ただし、現在のシステムログレベルや具体的なSQL例外シナリオによって制限されるため、ログファイル内で対応するSQLリクエストのログが必ず見つかるとは限りませんが、試してみる価値は常にあります。
特定のSQLリクエストのログを検索することは、可観測性分野において非常に有用な技術です。基本的な技術ポイントは、ノードIPアドレスとTRACE_IDを用いてログファイルからログを検索し、手がかりを捉え、その手がかりをたどって全リンクを通じて最初の発見現場を特定することです。その特徴は、「事後」および「全リンク」という2つの重要な特性を備えている点にあり、モニタリング指標の強力な補完となります。モニタリング指標は異常検出に長けており、システムログは詳細や全リンク追跡に優れています。
操作手順
OceanBaseクラスタにログインし、以下のSQLを実行します。このSQLはエラーを返します。
obclient> select timestamp'0001-01-33'; ERROR 1525 (HY000): Incorrect DATETIME value: '0001-01-33'注意
ここで実行するSQLは示唆的なものであり、実際の業務では通常アプリケーションシステムがSQLを実行します。場合によっては、エラーコードの返却や高い実行時間などの異常が発生することがあります。その際は、アプリケーション担当者が運用担当者に連絡し、問題の特定を支援してもらいます。
システムテナントにログインし、
GV$OB_SQL_AUDITビューを使用して、このSQLの実行情報を照会します。注意
GV$OB_SQL_AUDITから結果が取得できない場合は、audit機能が無効になっているかどうか確認してください。つまり、enable_sql_audit構成パラメータがFalseに設定されていないかどうか確認してください。enable_sql_audit構成パラメータの詳細については、enable_sql_auditを参照してください。obclient> select * from gv$ob_sql_audit where query_sql like '%select timestamp%' limit 1\G *************************** 1. row *************************** SVR_IP: xx.xx.xx.158 SVR_PORT: 2882 REQUEST_ID: 374223576 SQL_EXEC_ID: 389174628 TRACE_ID: YB4206019C9E-0005F55950FFAF04-0-0 SID: 3222268068 CLIENT_IP: xx.xx.xx.88 CLIENT_PORT: 54896 TENANT_ID: 1 TENANT_NAME: sys EFFECTIVE_TENANT_ID: 1 USER_ID: 200001 USER_NAME: dba_read USER_GROUP: 0 USER_CLIENT_IP: xx.xx.xx.113 DB_ID: 201001 DB_NAME: oceanbase SQL_ID: 86CC23B2B299FFAB9C50809C7238E891 QUERY_SQL: select timestamp'0001-01-33' PLAN_ID: 0 AFFECTED_ROWS: 0 RETURN_ROWS: 0 PARTITION_CNT: 0 RET_CODE: -5241 QC_ID: 0 DFO_ID: 0 SQC_ID: 0 WORKER_ID: 0 EVENT: P1TEXT: P1: 0 P2TEXT: P2: 0 P3TEXT: P3: 0 LEVEL: 0 WAIT_CLASS_ID: 100 WAIT_CLASS#: 0 WAIT_CLASS: OTHER STATE: MAX_WAIT TIME ZERO WAIT_TIME_MICRO: 0 TOTAL_WAIT_TIME_MICRO: 0 TOTAL_WAITS: 0 RPC_COUNT: 0 PLAN_TYPE: 0 IS_INNER_SQL: 0 IS_EXECUTOR_RPC: 0 IS_HIT_PLAN: 0 REQUEST_TIME: 1678603660669976 ELAPSED_TIME: 254 NET_TIME: 0 NET_WAIT_TIME: 2 QUEUE_TIME: 53 DECODE_TIME: 0 GET_PLAN_TIME: 158 EXECUTE_TIME: 4 APPLICATION_WAIT_TIME: 0 CONCURRENCY_WAIT_TIME: 0 USER_IO_WAIT_TIME: 0 SCHEDULE_TIME: 0 ROW_CACHE_HIT: 0 BLOOM_FILTER_CACHE_HIT: 0 BLOCK_CACHE_HIT: 0 DISK_READS: 0 RETRY_CNT: 0 TABLE_SCAN: 0 CONSISTENCY_LEVEL: -1 MEMSTORE_READ_ROW_COUNT: 0 SSSTORE_READ_ROW_COUNT: 0 DATA_BLOCK_READ_CNT: 0 DATA_BLOCK_CACHE_HIT: 0 INDEX_BLOCK_READ_CNT: 0 INDEX_BLOCK_CACHE_HIT: 0 BLOCKSCAN_BLOCK_CNT: 0 BLOCKSCAN_ROW_CNT: 0 PUSHDOWN_STORAGE_FILTER_ROW_CNT: 0 REQUEST_MEMORY_USED: 65536 EXPECTED_WORKER_COUNT: 0 USED_WORKER_COUNT: 0 SCHED_INFO: NULL FUSE_ROW_CACHE_HIT: 0 PS_CLIENT_STMT_ID: -1 PS_INNER_STMT_ID: -1 TX_ID: 0 SNAPSHOT_VERSION: 0 REQUEST_TYPE: 2 IS_BATCHED_MULTI_STMT: 0 OB_TRACE_INFO: NULL PLAN_HASH: 0 LOCK_FOR_READ_TIME: 0 PARAMS_VALUE: 1 row in set (1.08 sec)上記のクエリ結果から、このSQLリクエストの実行対象ノードと
TRACE_IDを取得できます。SVR_IP: xx.xx.xx.158 TRACE_ID: YB4206019C9E-0005F55950FFAF04-0-0注意
この例では、
GV$OB_SQL_AUDITビューを使用してノードIPアドレスとTRACE_IDを取得しますが、OceanBaseデータベースはODPのログや待機イベント関連ビューなど、他にもさまざまな取得方法を提供しています。対象ノードにログインし、
TRACE_IDを使用してログファイルを検索します。[hellodba@xx.xx.xx.158 /home/admin/oceanbase/log] $ grep 'YB4206019C9E-0005F55950FFAF04-0-0' observer.log [2023-03-12 14:47:40.670100] WARN resolve_const (ob_resolver_utils.cpp:2420) [116987][T1_TNT_L0_G0][T1][YB4206019C9E-0005F55950FFAF04-0-0] [lt=21] Incorrect DATETIME value: '0001-01-33' [2023-03-12 14:47:40.670205] WARN resolve_const (ob_resolver_utils.cpp:2420) [116987][T1_TNT_L0_G0][T1][YB4206019C9E-0005F55950FFAF04-0-0] [lt=37] Incorrect DATETIME value: '0001-01-33'注意
observer.logで関連ログがgrepできない場合は、observer.logが切り替えられた可能性があります。その場合は、grep YB4206019C9E-0005F55950FFAF04-0-0 observer.log.*と入力してください。TRACE_IDに関連するログを検索することは最初のステップにすぎません。真の目的は、入念な分析にあります。- ログのコンテキスト、OSメトリクス、OSイベントなど、多角的な指標を組み合わせて、このノードを分析します。
TRACE_IDに対応するRPC呼び出しを通じて、他のOceanBaseノード、ODPノード、アプリケーションノードをつなぎ合わせ、エンドツーエンドで分析します。