参考资料:官方文档SQL Tuning Guide
https://docs.oracle.com/en/database/oracle/oracle-database/12.2/tgsql/sql-performance-fundamentals.html#GUID-DD9CAA74-3E0B-48C9-8770-AADB614BC992
Oracle Database 2 Day + Performance Tuning Guide
Oracle Performance Tuning Guide
DBA和开发人员均可通过平台来发现某时间段、某数据库实例上的慢SQL信息。但平台中只能简单的查看一些执行计划以及执行过程的统计信息,需要更详细信息还是要去数据库查询,目前慢优化这块待完善。
从ash查看某段时间SQL的等待总次数,CPU、IO等维度
col type for a10 select * from ( select ash.SQL_ID , ash.SQL_PLAN_HASH_VALUE Plan_hash, aud.name type, sum(decode(ash.session_state,'ON CPU',1,0)) "CPU", sum(decode(ash.session_state,'WAITING',1,0)) - sum(decode(ash.session_state,'WAITING', decode(wait_class, 'User I/O',1,0),0)) "WAIT" , sum(decode(ash.session_state,'WAITING', decode(wait_class, 'User I/O',1,0),0)) "IO" , sum(decode(ash.session_state,'ON CPU',1,1)) "TOTAL" from v$active_session_history ash, audit_actions aud where SQL_ID is not NULL and ash.sql_opcode=aud.action and ash.sample_time > sysdate - &minutes /( 60*24) --最近几分钟的时间范围 --and ash.sample_time between to_timestamp('&begin_time','yyyy-mm-dd hh24:mi:ss') and to_timestamp('&end_time','yyyy-mm-dd hh24:mi:ss') --某段时间范围 group by sql_id, SQL_PLAN_HASH_VALUE , aud.name order by sum(decode(session_state,'ON CPU',1,1)) desc ) where rownum < 20; --取TOP 20条等待次数最多sql
从AWR报告查看TOP SQL
awr中重点关注某问题段时间一般间隔为15分钟,top sql,主要关注平均每次执行的时间以及执行sql耗用资源情况。
按照某top sql维度从awr基表中批量获取慢SQL
适合做营销活动前主动的从awr资料库里面抓取最近几天的所有慢SQL
select dbms_lob.substr(sql_text, 100) sqla, AA.*, BB.SQL_TEXT from (select sql_id, plan_hash_value, object_name, BUFFER_GETS, EXECUTIONS, BUFFER_GETS / decode(nvl(EXECUTIONS, 1), 0, 1, EXECUTIONS) as BUFFER_GETS_Per_Exec, DISK_READS / decode(nvl(EXECUTIONS, 1), 0, 1, EXECUTIONS) as DISK_READS_Per_Exec, ELAPSED_TIME / 1000000 as to_time, io_wait / 1000000 as io_time, round(io_wait / ELAPSED_TIME * 100) || '%' ioa_time, -- round(CPU_TIME/ELAPSED_TIME*100)||'%' cpua_time, row_processed / decode(nvl(EXECUTIONS, 1), 0, 1, EXECUTIONS) rows_processed_1exec, ELAPSED_TIME / decode(nvl(EXECUTIONS, 1), 0, 1, EXECUTIONS) / 1000000 as ELAPSED_TIME_Per_Exec, CPU_TIME / decode(nvl(EXECUTIONS, 1), 0, 1, EXECUTIONS) / 1000000 as CPU_TIME_Per_Exec from (select b.sql_id sql_id, b.plan_hash_value, o.object_name, sum(nvl(b.EXECUTIONS_DELTA, 3)) as EXECUTIONS, sum(nvl(b.DISK_READS_DELTA, 3)) as DISK_READS, sum(nvl(b.iowait_DELTA, 3)) as io_wait, sum(nvl(b.BUFFER_GETS_DELTA, 0)) as BUFFER_GETS, sum(nvl(b.CPU_TIME_DELTA, 0)) as CPU_TIME, sum(nvl(b.rows_processed_delta, 0)) as row_processed, -- b.rows_processed_delta sum(nvl(b.ELAPSED_TIME_DELTA, 0)) as ELAPSED_TIME from DBA_HIST_SQLSTAT b, dba_hist_snapshot a, dba_hist_sql_plan p, dba_objects o where /*b.sql_id in (select distinct (sql_id) from dba_hist_active_sess_history t where session_id in (708,978) and sql_id is not null and to_char(t.sample_time, 'yyyy-mm-dd hh24-mi-ss') >= '2016-05-26 21-00-00' and to_char(t.sample_time, 'yyyy-mm-dd hh24-mi-ss')<= '2016-05-26 23-50-00') and */ b.snap_id = a.snap_id and b.parsing_schema_name in ('CCIC', 'CCICAGT') and b.instance_number = a.instance_number and b.sql_id = p.sql_id -- and p.options = 'FULL' and p.object_name=o.object_name and to_char(a.begin_interval_time, 'yyyy-mm-dd hh24-mi-ss') >= '2016-06-02 09-00-00' and to_char(a.end_interval_time, 'yyyy-mm-dd hh24-mi-ss') <= '2016-06-02 17-40-00' --and b.snap_id >= 67040 -- and b.snap_id <= 67050 group by b.sql_id, b.plan_hash_value,o.object_name)) aa, dba_hist_sqltext bb where AA.sql_id = BB.sql_id and BUFFER_GETS_Per_Exec > 10000 order by -- to_time desc BUFFER_GETS_Per_Exec desc
1、慢SQL监控告警:
2、开发人员主动找到DBA说有慢SQL
3、数据库出现性能问题告警
阻塞会话告警
活跃会话数告警
CPU、IO等告警
现象:开发人员发现某业务SQL没有反应,应用接口其它SQL正常。 DBA接收到阻塞会话和活跃会话告警信息。
一般是dba先接收到告警。这时候可以先去查看活跃会话,看看数据库当前节点在忙些啥?
接收到的告警:
同一时间开发人员反馈执行有问题的SQL
问题原因分析:
造成活跃会话升高原因基本上都是被瓶颈问题阻塞了,常见的有频次高的慢SQL,应用接连不断的发送sql 但执行比较慢,累积的越来越多活跃会话。阻塞会话过多,8成是遇到锁特别是行锁。
先看看活跃会话情况:
set linesize 200 col sid format 999999 col s# format 9999999 col username format a15 col event format a40 col BLOCKING_SESSION format 999999 col machine format a20 col p123 format a30 col wt format 999 col spid format a15 col SQL_ID for a18 SELECT /* XJ LEADING(S) FIRST_ROWS */ S.SID, S.SERIAL# S#, S.USERNAME, S.MACHINE, S.EVENT, S.BLOCKING_SESSION, S.P1 || '/' || S.P2 || '/' || S.P3 P123, S.WAIT_TIME WT, NVL(SQL_ID, S.PREV_SQL_ID) SQL_ID FROM V$SESSION S WHERE S.STATUS = 'ACTIVE' and S.TYPE <>'BACKGROUND';
查询结果如下:
从活跃会话查询结果中看到,sql ba2wr7m4xcrzx的等待事件都是关于行锁的enq:Tx - row lock contention,并且阻塞者的会话是6829,阻塞源头基本断定是6829,后面看看会话6829在干啥。
执行查询sql:
set linesize 200 col sid format 999999 col s# format 9999999 col username format a15 col event format a40 col BLOCKING_SESSION format 999999 col machine format a20 col p123 format a30 col wt format 999 col spid format a15 col SQL_ID for a18 col PROGRAM for a18 col MODULE for a18 alter session set cursor_sharing=force; SELECT /* XJ LEADING(S) FIRST_ROWS */ S.inst_id, S.SID, S.SERIAL# S#, S.USERNAME, S.MACHINE, S.PROGRAM, S.MODULE, S.EVENT, S.BLOCKING_SESSION, S.P1 || '/' || S.P2 || '/' || S.P3 P123, S.WAIT_TIME WT, NVL(SQL_ID, S.PREV_SQL_ID) SQL_ID FROM gV$SESSION S WHERE S.TYPE <>'BACKGROUND' and S.sql_id = '&sql_id' order by 1,2;
执行结果:
接下来在看看会话6829上sql 5haaxd3zxbqgc在跑啥?
select sql_id,sql_fulltext from v$sql where sql_id='5haaxd3zxbqgc' and rownum=1; 或者直接查看执行计划以及sql文本,看的信息更多一些 SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(to_char('&SQL_ID'),&child_NULL,'ADVANCED'));
发现是阻塞者和被阻塞者都是在更新同一张表中的某些行数据,更新到相同的行就会造成行锁冲突。解决也很简单,kill掉阻塞源头就可以,但DBA这个时候要作出评估。
1)、立马把SQL语句丢到开发沟通群,快速询问 这是阻塞源头是否可以立马kill掉,请尽快评估kill掉对业务是否有影响
2)、多次查询活跃会话,持续关注该库上的告警信息,看活跃会话和阻塞会话是否一直在快速增加
如果活跃会话和阻塞会话一直增加,数据库性能不可控。DBA要果断kill该阻塞源头。
alter system kill session '6829,43685' immediate; 或者通过sql_id生成相关kill语句 SELECT q'[alter system kill session ']'||S.SID||','||S.SERIAL#||q'[' immediate;]' sql_text from V$SESSION S WHERE S.sql_id = '&sql_id' AND S.STATUS = 'ACTIVE';
如果数据库性能暂时可控,告知开发后果后,等待他们答复后再处理。等开发人员做好准备工作后就可以kill该会话。
收尾工作:
持续关注该库上的告警信息,同时关注因kill掉了大事物的DML语句,关注数据库回滚情况。
alter session set NLS_DATE_FORMAT='DD-MON-YYYY HH24:MI:SS'; select usn, state, undoblockstotal "Total", undoblocksdone "Done", undoblockstotal-undoblocksdone "ToDo", decode(cputime,0,'unknown',sysdate+(((undoblockstotal-undoblocksdone) / (undoblocksdone / cputime)) / 86400)) "Estimated time to complete" from v$fast_start_transactions;
如果回滚事物太慢,可以考虑调整参数:
alter system set "_rollback_segment_count" = 2000;
一般分这几种情况:
1)、执行计划变了,最常见
2)、之前绑定的执行计划,随着数据量的增长已经不合适了。
3)、修改了数据库参数,特别是优化器相关的参数,问题sql是定时跑的,并没有立马体现出来。比较少见。
分析思路与解决方案:
执行计划抖动,绑定
开发人员给出的sql往往是sql文本,并且很有可能是同一张表雷同SQL,只是有细微差异,体现在数据库中的是不同SQL_ID。这种情况不能完全相信开发人员给出的sql,一定要根据提供的信息去数据库里面再找找,把所有雷同的sql列出来。解决问题不仅要解决问题点,还要覆盖到问题面。
核对慢sql 看平台上慢SQL,以及查v$SQL
select sql_id,sql_fulltext from v$sql where sql_text like '%sql注释部分%'
查看sql执行情况,对比性能好时段和变差时段执行计划变更情况
col PLAN_HASH_VALUE for 9999999999 col instance_number for 9 col snap_id heading 'SnapId' format 999999 col executions_delta heading "No. of exec" col date_time heading 'Date time' for a20 col avg_lio heading 'LIO/exec' for 999999999999 col avg_cputime_s heading 'CPUTIM/exec' for 99999 col avg_etime_s heading 'ETIME/exec' for 999999 col avg_pio heading 'PIO/exec' for 999999999 col avg_row heading 'ROWs/exec' for 9999999999 col sql_profile format a35 SELECT distinct s.snap_id , s.instance_number, PLAN_HASH_VALUE, to_char(s.BEGIN_INTERVAL_TIME,'mm/dd/yy_hh24mi')|| to_char(s.END_INTERVAL_TIME,'_hh24mi') Date_Time, SQL.executions_delta, SQL.buffer_gets_delta/decode(nvl(SQL.executions_delta,0),0,1,SQL.executions_delta) avg_lio, (SQL.cpu_time_delta/1000000)/decode(nvl(SQL.executions_delta,0),0,1,SQL.executions_delta) avg_cputime_s , (SQL.elapsed_time_delta/1000000)/decode(nvl(SQL.executions_delta,0),0,1,SQL.executions_delta) avg_etime_s, SQL.DISK_READS_DELTA/decode(nvl(SQL.executions_delta,0),0,1,SQL.executions_delta) avg_pio, SQL.rows_processed_total/decode(nvl(SQL.executions_delta,0),0,1,SQL.executions_delta) avg_row, SQL.sql_profile FROM dba_hist_sqlstat SQL,dba_hist_snapshot s WHERE SQL.dbid =(select dbid from v$database) and s.snap_id = SQL.snap_id and sql.instance_number = s.instance_number AND sql_id in ('&sql_id') order by s.snap_id;
如果结果中看出来执行计划变更了,那就要考虑把问题sql的执行计划绑定。
使用COE脚本绑定步骤:
脚本下载地址:https://github.com/AlbertCQY/scripts/blob/master/oracle/sql_profile_new2.sql
脚本简单说明:原始coe脚本出自oracle MOS官方,sql_profile_new2.sql脚本是oracle官方高级售后DBA修改的增强版。可以绑定执行计划、替换执行计划。
@sql_profile_new2.sql Parameter 1: SQL_ID (required) Enter value for 1: --这里传入需要优化的sqlid Parameter 2: PLAN_HASH_VALUE (required) Enter value for 2: --这里传入正确执行计划的PLAN_HASH_VALUE,可以不是Parameter 1对应sqlid的plan_hash 最后在当前目录下生成一个要执行的脚本,包含sql_id和plan hash 比如:coe_xfr_sql_profile_62159umsg6z8m_4105682492.sql 绑定执行计划就直接执行上面生成的脚本。
刷新sql执行计划游标:
select PLAN_HASH_VALUE,q'[exec sys.dbms_shared_pool.purge(']'||address||','||hash_value||q'[','C');]' as flush_sql from v$sqlarea where sql_id='63u74y7gdafzf'; 得到刷新语句后直接执行即可。
绑定执行计划后重新查看下sql执行计划信息,如果还是原来的执行计划则有可能是coe绑定成功了,但由于sql正在执行中 导致执行计划游标刷出失败。需要和开发沟通是否可以kill掉正在执行sql的会话,然后再去刷新即可。
构造新的执行计划,解绑->绑定新的
如果发现sql上面已经绑定了执行计划,但随着表上数据量的增长,以及业务逻辑的变更,绑定的执行计划已经不适合了,需要解绑并替换为更优的执行计划。
构造想要的执行计划:hint提示方法
由于业务评估失误以及数据量的不断增长,该sql在项目开始时候评估下来适合走object_id列上的索引,并且也做了执行计划的绑定。
现在业务数据产生了变化,需要按照预定方式走object_name列上的索引idx_name
原来sql(fvscnttfnqvkf) select * from t_testplan where object_id=1 and object_name='test' Plan hash value: 2317386271 ------------------------------------------------------------------------------------------ | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ------------------------------------------------------------------------------------------ | 0 | SELECT STATEMENT | | 8 | 1656 | 2 (0)| 00:00:01 | |* 1 | TABLE ACCESS BY INDEX ROWID| T_TESTPLAN | 8 | 1656 | 2 (0)| 00:00:01 | |* 2 | INDEX RANGE SCAN | IDX_ID | 14 | | 1 (0)| 00:00:01 | ------------------------------------------------------------------------------------------ Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("OBJECT_NAME"='test') 2 - access("OBJECT_ID"=1)
加hint后sql(9xtcn2g6n7gsw) select /*+INDEX(t_testplan idx_name) */ * from t_testplan where object_id=1 and object_name='test' Plan hash value: 1801285354 -------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 7 | 3367 | 12 (0)| 00:00:01 | |* 1 | TABLE ACCESS BY INDEX ROWID BATCHED| T_TESTPLAN | 7 | 3367 | 12 (0)| 00:00:01 | |* 2 | INDEX RANGE SCAN | IDX_NAME | 16 | | 3 (0)| 00:00:01 | -------------------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("OBJECT_ID"=1) 2 - access("OBJECT_NAME"='test')
现在需要把fvscnttfnqvkf的执行计划替换为9xtcn2g6n7gsw的执行计划
第一步:删除绑定的执行计划(解绑profile)
select name from dba_sql_profiles where name like '%fvscnttfnqvkf%'; BEGIN DBMS_SQLTUNE.DROP_SQL_PROFILE(name => 'SYS_SQLPROF_fvscnttfnqvkf'); END; /
第二步:绑定执行计划
@sql_profile_new2.sql Parameter 1: SQL_ID (required) Enter value for 1: --这里传入需要优化的sqlid fvscnttfnqvkf Parameter 2: PLAN_HASH_VALUE (required) Enter value for 2: --这里传入加Hint后的9xtcn2g6n7gsw执行计划PLAN_HASH_VALUE 1801285354
参照之前的步骤,刷新执行计划游标。
场景分析:应用server内存OOM后,开发人员在分析应用代码以及框架没问题后,一般会找DBA查找SQL的原因。
1)、开发人员提供的SQL有很明显的全表扫描语句
比较少见,一般添加合适的索引即可。
2)、开发人员提供的带绑定变量的sql,并且dba提供了完整测试语句
开发提供的sql在数据库上测试了下,性能很好,返回的结果集也很小。但真的是这样么?这时候就要怀疑是不是没有给到出现OOM时绑定变量真正的传参值。
出现这种比较奇怪的信息不对称情况时,其实也挺好求证。查看该SQL历史执行情况,和之前的逻辑读、物理读、返回行数等对比下就知道了。如果问题时段这些指标相对高,那么八九不离十就是传参倾斜导致。
场景分析:新上线的SQL由于性能评估不到位,过段时间在业务高峰时段,逐渐暴露出来性能问题。
常见有缺少必要的索引:DBA根据表结构以及各列的统计信息来判断,下面分享两个常用的脚本
表维度,查看表上结构信息、统计信息等,tabstat.sql脚本:传入用户名+表名
https://github.com/AlbertCQY/scripts/blob/master/oracle/tabstat.sql
SQL维度,SQL语句所有关联的表上结构信息、统计信息等,sql10.sql脚本:传入sql_id
https://github.com/AlbertCQY/scripts/blob/master/oracle/sql10.sql
创建索引指导建议:
适合创建索引的列
不适合创建索引的列
Oracle数据库不仅对OLTP型短平快的sql支持很好,OLAP型复杂的分析SQL同样支持很好。一般来说复杂SQL执行计划特别长,甚至超过200行,关联5张以上表或视图,无法快速分析出执行计划是否有问题,甚至执行计划还经常抖动。
优化思路:不管SQL写的多复杂,执行计划超级长,只需要抓住sql最影响性能的地方即可。
借助脚本plan_ash.sql或者sql10.sql脚本可以展示出最消耗性能的部分:https://github.com/AlbertCQY/scripts/blob/master/oracle/plan_ash.sql
比如下面这个执行计划,发现性能瓶颈在逻辑读上面,优化掉db file sequential read(2)(40%) 这一步骤的性能问题,该复杂SQL问题也就解决了。
Oracle官方工具篇:
Oracle官方提供了丰富的sql调优工具,面对复杂SQL善于使用官方提供的工具也是个不错的方法。
Oracle真的是博大精深,学习永无止境...
Information Center: Sql Performance Tuning: Troubleshoot (Doc ID 1516522.2)
SQL Tuning Advisor:
SQL Tuning Advisor (Doc ID 2582636.1)
Automatic SQL Tuning and SQL Profiles (Doc ID 271196.1)
Using the DBMS_SQLTUNE Package to Run the SQL Tuning Advisor (Doc ID 262687.1)
Example: SQL Tuning Task Options (Doc ID 2461848.1)
SQL Performance Analyzer Summary (Doc ID 1577290.1)
SQL Tuning Health-Check Script (SQLHC) (Doc ID 1366133.1)
NOTE:243755.1 - Script to produce HTML report with top consumers out of PL/SQL Profiler DBMS_PROFILER data
NOTE:1482811.1 - Best Practices: Proactively Avoiding Database and Query Performance Issues
NOTE:1460440.1 - Script PXHCDR.SQL: Parallel Execution Health-Checks and Diagnostics Reports
NOTE:1477599.1 - Best Practices: Proactive Data Collection for Performance Issues
NOTE:224270.1 - TRCANLZR (TRCA): SQL_TRACE/Event 10046 Trace File Analyzer - Tool for Interpreting Raw SQL Traces (NO LONGER SUPPORTED - Use SQLTXPLAIN sqltrcanlzr.sql)
NOTE:1627387.1 - How to Determine the SQL_ID for a SQL Statement
NOTE:1455583.1 - SQL Tuning Health-Check Script (SQLHC) Video
NOTE:215187.1 - All About the SQLT Diagnostic Tool
NOTE:1417774.1 - FAQ: SQL Health Check (SQLHC) Frequently Asked Questions
最后分享一个丁俊老师的一篇文章:
https://dbaplus.cn/news-10-1314-1.html