OceanBase 分析 RT 突然抖動的 SQL

推薦使用外部診斷工具 Tars 進行問題分析，或者使用 ?(g)v$sql_audit? 視圖進行問題排查。

使用 ?(g)v$sql_audit? 進行問題排查方式如下：

1. 在線上如果出現(xiàn) RT 抖動，但 RT 并不是持續(xù)很高的情況，可以考慮在抖動出現(xiàn)后，立刻將 sql_audit 關(guān)閉 ?(alter system set ob_enable_sql_audit = 0)?，從而確保該抖動的 SQL 請求在 sql_audit 中存在。
2. 通過 SQL Audit 查詢抖動附近那段時間 RT 的 TOP N 請求，分析有異常的 SQL。
3. 找到對應(yīng)的 RT 異常請求，則可以分析該請求在 sql_audit 中的記錄進行問題排查：
• 查看 retry 次數(shù)是否很多（?RETRY_CNT? 字段），如果次數(shù)很多，則可能有鎖沖突或切主等情況。
• 查看 queue time 的值是否過大（?QUEUE_TIME? 字段）。
• 查看獲取執(zhí)行計劃時間（?GET_PLAN_TIME? 字段），如果時間很長，一般會出現(xiàn) ?IS_HIT_PLAN ＝ 0?，表示沒有命中 plan cache。
• 查看 EXECUTE_TIME 的值，如果值過大，則可以通過以下步驟進行排查：

a. 查看是否有很長等待事件耗時。

b. 分析邏輯讀次數(shù)是否異常多（突然有大賬戶時可能會出現(xiàn)）。

邏輯讀次數(shù) = 2 * ROW_CACHE_HIT 
           + 2 * BLOOM_FILTER_CACHE_HIT 
           + BLOCK_INDEX_CACHE_HIT 
           + BLOCK_CACHE_HIT + DISK_READS

如果在 SQL Audit 中 RT 抖動的請求數(shù)據(jù)已被淘汰，則需要查看 OBServer 中抖動時間點是否有慢查詢的 trace 日志，并分析對應(yīng)的 trace 日志。