开网站做淘宝客,做网站需要招什么职位,行业网站盈利模式,wordpress 4.0 打开慢面对SQL问题#xff0c;大家的常用的分析思路是#xff1a;
一、问题是否源于SQL本身#xff1f;是的话需进行SQL调优。
二、SQL语句本身无误#xff0c;但执行效果并未达到我们的预期效果。
检查当前的服务器负载状况#xff0c;例如CPU利用率、内存占用、IO读写等关键…面对SQL问题大家的常用的分析思路是
一、问题是否源于SQL本身是的话需进行SQL调优。
二、SQL语句本身无误但执行效果并未达到我们的预期效果。
检查当前的服务器负载状况例如CPU利用率、内存占用、IO读写等关键指标。确认是否存在数据库锁冲突问题统计信息是否准确考虑其他可能的场景因素 常用的信息收集
一、获取 trace_id 的方式
方法一如果SQL可以执行成功执行完第一步的sql后立即执行获取
select last_trace_id();
方法二如果SQL执行失败可以通过设置参数失败后会返回信息trace_id、执行节点等
alter system set enable_rich_error_msgtrue; // 需要在sys租户下执行
方法三直接通过 SQL 过滤 sql_audit
select * from oceanbase.GV$OB_SQL_AUDIT where query_sql like xxx% order by REQUEST_TIME desc limit 5; 二、执行信息收集
1、OCP 平台业务租户监控截图包括性能和主机监控
2、获取执行计划
explain extended sql
3、执行原始SQL然后获取trace_id
select last_trace_id(); 获取trace id
4、获取 sql_audit
select * from oceanbase.GV$OB_SQL_AUDIT where TRACE_IDxxx order by REQUEST_TIME desc limit 5;
5、获取对应的observer log
通过 sql_audit 信息到执行的节点下执行
grep xxx observer.log*
6、获取 sql_monitorlocal计划默认不会生成sql_monitor 1、sql 执行添加monitor hint
select /* monitor */ * from xxx; delete /* monitor */ * from xxx; 2、获取trace id
select last_trace_id(); 3、获取 sql_monitor这里要替换traceid
select plan_line_id, plan_operation, sum(output_rows), sum(STARTS) rescan, min(first_refresh_time) open_time, max(last_refresh_time) close_time, max(last_refresh_time) - min(first_refresh_time) open_close_cost, min(first_change_time) first_row_time, max(last_change_time) last_row_eof_time, max(last_change_time) - min(first_change_time) rows_cost, count(1) from oceanbase.GV$SQL_PLAN_MONITOR where trace_id xxxx group by plan_line_id, plan_operation order by plan_line_id;
7、查询表的统计信息
select * from OCEANBASE.DBA_TAB_STATISTICS where table_namexxx \G
8、收集 explain trace 日志
set ob_log_levelTRACE;explain extend 原始sql;select last_trace_id();
然后用 trace id 捞一下日志 三、收集常见问题
如果日志没有查到记录可能是因为日志级别设置的太高
show parameters like %syslog_level%;set ob_log_levelTRACE;
也有可能日志限流以及刷新过快
alter system set syslog_io_bandwidth_limit1G;alter system set max_syslog_file_count15; 常见的问题解决思路 可以先收集下执行计划然后再执行转储合并以及收集统计信息后重试来排除这方面导致慢的可能。 收集统计信息
CALL dbms_stats.gather_table_stats(库名, 表名); 转储合并
转储
alter system minor freeze;
查询转储信息如果没有记录说明转储完成
SELECT * FROM oceanbase.GV$OB_TABLET_COMPACTION_PROGRESS WHERE TYPEMINI_MERGE\G
合并
ALTER SYSTEM MAJOR FREEZE;
查询合并状态可以多查询几次status 变成 idle 就可以了
SELECT * FROM oceanbase.CDB_OB_MAJOR_COMPACTION\G sql_audit 判断
sql_audit 如果花费的时间都是 execute_time就说明没有排队、堵塞等问题这个时候就要看计划是否合理、sql是否可以优化。 根据 sql_monitor 中慢的部分再分析执行计划
举个 估行不准
比如慢的算子部分 EST.ROWS 跟直接count 差别很大尤其是用了 NLJ 的场景。 数据倾斜
带有业务特征的字段十有八九都会比较容易倾斜。比如时间字段高度可疑特别是这种2099年。 怀疑统计信息不准确可以尝试动态采样
动态采样为了使优化器得到足够多的统计信息会在计划生成阶段针对数据库对象进行提前采样通过采样的方式进行行数估计从而用于代价模型中生成更好的计划。
语句添加 /*dynamic_sampling(1)*/ 这个hint执行 采集列的直方图
如果某些列的执行计划感觉有影响可以确认列的统计信息是否准确 确认列的直方图收集情况需要确认 HISTOGRAM 字段不为空。
select * from OCEANBASE.DBA_TAB_COL_STATISTICS where TABLE_NAME dim_scd_organization\G 收集所有列的统计信息
call dbms_stats.gather_table_stats(库名, 表名, degree4, method_optfor all columns size 256);
收集完成后再确认 OCEANBASE.DBA_TAB_COL_STATISTICS 的 HISTOGRAM 字段。 收集完可以再确认下sql的执行情况以及执行计划。 如果怀疑表关联顺序或者表关联算法有问题可以通过 Hint 来指定。
如下为碰到的问题 如果怀疑 NLJnext-loop join 慢可以添加 Hint NO_USE_NL 关闭。 比如这个例子USE_NL (xxx)Hint 换成/* NO_USE_NL(SEL$D2F629B4 dm.dm_outpatient_medical_reduce1SEL$1)*/
来让这个算子不走 NLJ再查看执行效率以及执行计划 如果执行结果不满足预期或者执行计划仍不是最优比如仍存在其他的nlj、关联顺序变化等可以手动指定不合理的地方
/*LEADING(SEL$D2F629B4 ((dw.dim_scd_organization_province_codeSEL$1 dm.dm_outpatient_medical_reduce1SEL$1) dw.dim_organization_level_level1_org_idSEL$1)) USE_HASH(SEL$D2F629B4 dw.dim_organization_level_level1_org_idSEL$1) USE_HASH(SEL$D2F629B4 dm.dm_outpatient_medical_reduce1SEL$1)*/ 这个 Hint 让 Leading 跟之前保持一致dim_organization_level_level1_org_id 的关联算法也跟之前的保持一致然后指定了 dm_outpatient_medical_reduce1 的关联算法由 USE_NL -- USE_HASH 写在最后
SQL问题可能的原因其实有很多解决SQL问题很多时候还是依靠经验我这里提供的一些思路也只是冰山一角建议大家碰到SQL问题可以记录下来处理得多了以后就会形成自己的一套方法论也就会越来越得心用手。
