参考资料：官方文档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_TEXTfrom (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_Execfrom (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_deltasum(nvl(b.ELAPSED_TIME_DELTA, 0)) as ELAPSED_TIMEfrom DBA_HIST_SQLSTAT  b,dba_hist_snapshot a,dba_hist_sql_plan p,dba_objects owhere /*b.sql_id in(select distinct (sql_id)from dba_hist_active_sess_history twhere session_id in (708,978)and sql_id is not nulland 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_idand b.parsing_schema_name in ('CCIC', 'CCICAGT')and b.instance_number = a.instance_numberand b.sql_id = p.sql_id-- and p.options = 'FULL'and p.object_name=o.object_nameand 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 <= 67050group by b.sql_id, b.plan_hash_value,o.object_name)) aa,dba_hist_sqltext bbwhere AA.sql_id = BB.sql_idand BUFFER_GETS_Per_Exec > 10000order by -- to_time descBUFFER_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_IDFROM V$SESSION SWHERE 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_IDFROM gV$SESSION SWHERE 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 SWHERE 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

oracle中慢sql优化思路相关推荐

【DB笔试面试605】在Oracle中，SQL概要（SQL Profile）的作用是什么？
♣题目部分在Oracle中,SQL概要(SQL Profile)的作用是什么? ♣答案部分 SQL Profile就是为某条SQL语句提供除了系统统计信息.对象(表和索引等)统计信息之外的其它信息 ...
oracle表中增加字段 sql语句,ORACLE中通过SQL语句(alter table)来增加、删除、修改字段...
1.添加字段: alter table 表名 add (字段字段类型) [ default '输入默认值'] [null/not null] ; 2.添加备注: comment on ...
Oracle 实验五：Oracle中的SQL使用
实验五:Oracle中的SQL使用一.实验目的 1.掌握SQL语言中常用系统函数: 2.掌握SQL语言的应用. 二.实验内容 1. 查询SQL中如下常用函数的使用,并举例说明(完成格式参考Lengt ...
Oracle中使用SQL根据出生日期精确计算年龄
Oracle中使用SQL根据出生日期精确计算年龄提示:以下是本篇文章正文内容,下面案例可供参考代码如下(示例): select XM,CSNY as 出生日期,-- extract函数用于提取日期 ...
ORACLE中使用SQL语句查询所有员工的职位信息，并用DISTINCT消除重复信息。
ORACLE中使用SQL语句查询所有员工的职位信息,并用DISTINCT消除重复信息. 在sqlplus中执行下面语句: select job from emp: 显示结果如下: SQL> se ...
oracle delete not in 优化,Oracle中的sql语句优化
1.选择最有效率的表名顺序(只在基于规则的优化器中有效) ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名,FROM子句中写在最后的表(基础表driving table)将被最先处理,在 ...
基于oracle 11g 的SQL优化
1.查看当前数据库版本: select* from v$version;(以下示例基于oracle 11.2.0.1.0) 2.ROWID oracle数据库的表中的每一行数据都有一个唯一的标识符,该 ...
ORACLE中高效SQL的写法
目录 1. 书写格式规范 1-1.大小文字及空格的统一 1-2.日期格式明确化 1-3.Bind变量的使用 1-4.表别名的使用 1-5.检索时尽量避免检索不需要的列 1-6.ORDER ...
sql优化的方法及思路_合理的sql优化思路--如何缩短SQL调优时间？
概述当生产环境发生故障或者系统特别慢的时候,这时候你从awr报告拿到有问题的sql,但是优化的时候却优化了很久还没解决,这时候在领导或者客户面前就不太好了...那么我们怎么去缩短sql调优的时间,一 ...

oracle中慢sql优化思路

如何发现慢SQL

主动发现

通过ASH&AWR去发现

被动发现

分析并优化慢SQL

开发人员反馈某个应用的SQL卡住了，一直未返回结果

开发人员反馈同样SQL昨天好好，今天突然变慢

开发人员反馈应用OOM告警，需要看下SQL是否有异常

新上线了功能，第二天发现一堆性能告警

如何解决一条复杂的SQL

oracle中慢sql优化思路相关推荐

最新文章

热门文章

oracle中慢sql优化思路

如何发现慢SQL

主动发现

通过ASH&AWR去发现

被动发现

分析并优化慢SQL

开发人员反馈某个应用的SQL卡住了， 一直未返回结果

开发人员反馈同样SQL昨天好好，今天突然变慢

开发人员反馈应用OOM告警，需要看下SQL是否有异常

新上线了功能，第二天发现一堆性能告警

如何解决一条复杂的SQL

oracle中慢sql优化思路相关推荐

最新文章

热门文章

开发人员反馈某个应用的SQL卡住了，一直未返回结果