oracle中慢sql优化思路 |
您所在的位置：网站首页 › 数据库查询慢怎么办解决方法 › oracle中慢sql优化思路 |
oracle中慢sql优化思路
|
参考资料：官方文档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 如何发现慢SQL 主动发现DBA和开发人员均可通过平台来发现某时间段、某数据库实例上的慢SQL信息。但平台中只能简单的查看一些执行计划以及执行过程的统计信息，需要更详细信息还是要去数据库查询，目前慢优化这块待完善。 通过ASH&AWR去发现从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-06-02 09-00-00' and to_char(a.end_interval_time, 'yyyy-mm-dd hh24-mi-ss') = 67040 -- and b.snap_id 10000 order by -- to_time desc BUFFER_GETS_Per_Exec desc 被动发现1、慢SQL监控告警： 2、开发人员主动找到DBA说有慢SQL
3、数据库出现性能问题告警 阻塞会话告警 活跃会话数告警 CPU、IO等告警 分析并优化慢SQL 开发人员反馈某个应用的SQL卡住了， 一直未返回结果现象：开发人员发现某业务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;开发人员反馈同样SQL昨天好好，今天突然变慢 一般分这几种情况： 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参照之前的步骤，刷新执行计划游标。 开发人员反馈应用OOM告警，需要看下SQL是否有异常 场景分析：应用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
创建索引指导建议： 适合创建索引的列 索引覆盖(只select索引列)、避免排序(order by索引列)复合索引尽量兼顾更多SQL(索引具有较多的使用场景)该列在表中的唯一性特别高、有些状态列有倾斜值(符合少数)复合索引等值谓词条件字段做前导列，非等值谓词条件字段放在后面表关联使用Nested Loop 被驱动表的关联字段上建议创建索引SQL语句是主流的业务，具有高并发，where条件中出现的列可以考虑创建复合索引不适合创建索引的列 DML频繁的表不适合创建索引，索引会带来额外的维护成本为了少数查询，并且频次不高的查询列上建索引(这类SQL考虑放读库执行)Where条件中不会使用的列也不适合创建索引
如何解决一条复杂的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 |
【本文地址】
今日新闻 |
点击排行 |
|
推荐新闻 |
图片新闻 |
|
专题文章 |