推荐使用外部诊断工具 Tars 进行问题分析，或者使用 ​(g)v$sql_audit​ 视图进行问题排查。

成都创新互联自2013年创立以来，公司以成都网站设计、网站建设、系统开发、网络推广、文化传媒、企业宣传、平面广告设计等为主要业务，适用行业近百种。服务企业客户近千家，涉及国内多个省份客户。拥有多年网站建设开发经验。为企业提供专业的网站建设、创意设计、宣传推广等服务。 通过专业的设计、独特的风格，为不同客户提供各种风格的特色服务。

使用 ​(g)v$sql_audit​ 进行问题排查方式如下：

1. 在线上如果出现 RT 抖动，但 RT 并不是持续很高的情况，可以考虑在抖动出现后，立刻将 sql_audit 关闭 ​(alter system set ob_enable_sql_audit = 0)​，从而确保该抖动的 SQL 请求在 sql_audit 中存在。
2. 通过 SQL Audit 查询抖动附近那段时间 RT 的 TOP N 请求，分析有异常的 SQL。
3. 找到对应的 RT 异常请求，则可以分析该请求在 sql_audit 中的记录进行问题排查：
• 查看 retry 次数是否很多（​RETRY_CNT​ 字段），如果次数很多，则可能有锁冲突或切主等情况。
• 查看 queue time 的值是否过大（​QUEUE_TIME​ 字段）。
• 查看获取执行计划时间（​GET_PLAN_TIME​ 字段），如果时间很长，一般会出现 ​IS_HIT_PLAN ＝ 0​，表示没有命中 plan cache。
• 查看 EXECUTE_TIME 的值，如果值过大，则可以通过以下步骤进行排查：

a. 查看是否有很长等待事件耗时。

b. 分析逻辑读次数是否异常多（突然有大账户时可能会出现）。

逻辑读次数 = 2 * ROW_CACHE_HIT 
           + 2 * BLOOM_FILTER_CACHE_HIT 
           + BLOCK_INDEX_CACHE_HIT 
           + BLOCK_CACHE_HIT + DISK_READS

如果在 SQL Audit 中 RT 抖动的请求数据已被淘汰，则需要查看 OBServer 中抖动时间点是否有慢查询的 trace 日志，并分析对应的 trace 日志。

网站栏目：创新互联OceanBase教程：OceanBase分析RT突然抖动的SQL
转载来于：https://chengdu.cdxwcx.cn/article/cdihepc.html