1. 前言
前几天写了一篇博客,告诉大家在遇到慢SQL或者复杂的并行SQL的时候怎么高效的来收集【SQL Monitor Report】,上一篇博客的链接: OceanBase 社区 ;发出去后有不少问我这份报告咋解读。今天再出一篇博客给大家介绍下如何解读报告。PS: 本文不介绍如何安装部署使用obdiag,用法参加上篇博客,本文仅做【SQL Monitor Report】报告解读。
2. 报告样式
生成的报告长这样,记得用浏览器打开。
#tree
.
├── resources
│ └── web
│ ├── bootstrap.min.css
│ ├── bootstrap.min.js
│ ├── jquery-3.2.1.min.js
│ └── popper.min.js
├── result_summary.txt
└── sql_plan_monitor_report.html
2 directories, 6 files
浏览器打开表头如下:(表头展示的是基本的sql执行信息,从gv$ob_sql_audit获取的)

3. 报告【执行计划】篇
执行计划的部分如下:

执行计划有两部分组成,一个是explain extend [SQL语句] 的结果,这个我们叫做物理执行计划,并不是实际这条SQL执行的时候命中的执行计划;物理执行计划下面的是才是实际执行计划。物理执行计划可以看到统计信息、hint、outline data等信息,就不在本文展开解释了。TIPS: 这两个执行计划大部分情况下是一样的,如果不一样需要关注一下。
4. 报告【SCHEMA 信息】篇
schema这块直接参见下图就行,注意一下表行数和第三节explan extend [SQL] 是否数量级能对应上,如果数量级都对应不上,那大概率统计信息收集存在滞后,先解决统计信息收集的问题再去看SQL慢的问题。

5. 报告【SQL_AUDIT信息】篇
报告如下,点击可以展开

使用的SQL如下:
-- ob 4.x --
select /*+ sql_audit */
`SVR_IP`,`SVR_PORT`,`REQUEST_ID`,`SQL_EXEC_ID`,`TRACE_ID`,`SID`,`CLIENT_IP`,`CLIENT_PORT`,`TENANT_ID`,
`EFFECTIVE_TENANT_ID`,`TENANT_NAME`,`USER_ID`,`USER_NAME`,`USER_CLIENT_IP`,`DB_ID`,`DB_NAME`,`SQL_ID`,
`QUERY_SQL`,`PLAN_ID`,`AFFECTED_ROWS`,`RETURN_ROWS`,`PARTITION_CNT`,`RET_CODE`,`QC_ID`,`DFO_ID`,`SQC_ID`,
`WORKER_ID`,`EVENT`,`P1TEXT`,`P1`,`P2TEXT`,`P2`,`P3TEXT`,`P3`,`LEVEL`,`WAIT_CLASS_ID`,`WAIT_CLASS`,`STATE`,
`WAIT_TIME_MICRO`,`TOTAL_WAIT_TIME_MICRO`,`TOTAL_WAITS`,`RPC_COUNT`,`PLAN_TYPE`,`IS_INNER_SQL`,
`IS_EXECUTOR_RPC`,`IS_HIT_PLAN`,`REQUEST_TIME`,`ELAPSED_TIME`,`NET_TIME`,`NET_WAIT_TIME`,`QUEUE_TIME`,
`DECODE_TIME`,`GET_PLAN_TIME`,`EXECUTE_TIME`,`APPLICATION_WAIT_TIME`,`CONCURRENCY_WAIT_TIME`,
`USER_IO_WAIT_TIME`,`SCHEDULE_TIME`,`ROW_CACHE_HIT`,`BLOOM_FILTER_CACHE_HIT`,`BLOCK_CACHE_HIT`,
`DISK_READS`,`RETRY_CNT`,`TABLE_SCAN`,`CONSISTENCY_LEVEL`,`MEMSTORE_READ_ROW_COUNT`,
`SSSTORE_R

最低0.47元/天 解锁文章
1327

被折叠的 条评论
为什么被折叠?



