案例

首先基于系统监控发现租户的 QPS_RT 和 TPS_RT 出现飙升。

然后下钻分析，发现磁盘读的 IOPS 和数据量发生飙升，怀疑是 SQL 问题。

基于 SQL Audit，定位到疑点 SQL 语句。

结论：

• 通过 avg_logical_read 字段发现这两个 SQL 逻辑读分别为 97 和 5。

• 通过 cnt 字段发现这两个 SQL 并发量较大。

并发量较大产生大量磁盘 IO，进而导致租户工作线程 IO 等待，导致所有 SQL 的 QUEUE_TIME 达到 30s+。

分析疑点 SQL

• 获取疑点 SQL 的 Text 文本。

  obclient> select query_sql from v$ob_sql_audit where sql_id in ('E49D99FE0221C22E9E65352924104224') limit 1\G
  *************************** 1. row ***************************
  query_sql:
  select *
  from t1
  where user_id = 'xxx' and product_type = 'xxx' and standard_category not in('xxx','xxx')           
  order by gmt_last_trans DESC  limit 35
  1 row in set (0.01 sec)
  

  通过分析 GV$OB_PLAN_CACHE_PLAN_EXPLAIN 视图，其走的索引为 (user_id)，该索引对于大客户会产生大量回表，需要优化索引。

  综合考虑其他查询后，新建索引为 (user_id, product_type, standard_category, gmt_last_trans)。

• 获取疑点 SQL 的 Text 文本。

  obclient> select query_sql from v$ob_sql_audit where sql_id in ('49E666DA7094F3C6089853875D94F8E6') limit 1\G
  *************************** 1. row ***************************
  query_sql:          
  select sum(trans_amount)  
  from t2   
  where a_id = 'xxx' and user_id = 'xxx' and trans_code = 'xxx' and out_date <= '20180831'
  1 row in set (0.00 sec)
  

  通过分析 GV$OB_PLAN_CACHE_PLAN_EXPLAIN 视图，其走的索引为 (user_id)，该索引对于大客户会产生大量回表，需要优化索引。

  综合考虑其他查询后，新建索引为 (a_id, trans_code, user_id,out_date,trans_amount)。