作者介绍

丁俊，新炬网路首席性能优化专家，SQL初审产品总监。《剑破冰山-开发艺术》副主编，ITPUB开发版资深版主，十余年联通行业从业经验。

一、SQLT背景介绍

（简称SQLT）是COE提供的一款SQL性能确诊工具，SQLT主要方式是通过输入的一个SQL句子，进而生成一组确诊文件，这种文件用于确诊性能较差的或形成错误结果(WRONG)的SQL。

SQLT形成的确诊文件内容包括执行计划、统计信息、CBO的参数、10053文件、性能变化的历史等须要确诊SQL性能的一系列文件，但是SQLT还提供一系列工具，例如快速绑定SQL执行计划的工具。

SQLT主要使用场合是在须要快速绑定SQL执行计划，或则一些和参数、BUG等相关的疑难SQL剖析中。

二、SQLT家族简介

SQLT主要包含下述方式：

SQLT为一个SQL句子提供了下边7种主要方式来生成确诊详尽信息，，，，，和。，，，，和处理绑定变量和会做bind（绑定变量窥探），并且不会。这是由于是基于PLANFOR命令执行的，该命令不做bind。

为此，假如可能请避开使用，不仅的bind限制外，所有这7种主要方式都可以提供足够的确诊详尽信息，对性能较差或形成错误结果集的SQL进行初步评估。假如该SQL仍坐落显存中或则(AWR)中，请使用或，其他情况请使用。对于DataGuard或备用只读数据库，请使用。仅当其他方式都不可行时，再考虑使用。和是类似于和，但为了提升SQLT的性能它们禁了一些SQLT的特点。

几种主要方式的关系如下：

其中包括了和技巧，实际上它会同时执行这两个方式生成对应的文件。使用这种方式后，会生成文件，手动打包。

SQLT的详尽内容请参考MOS文档：SQLT使用手册(DocID.1)，本文重点说下SQLT里比较有用的方式（本文内容的环境是11.2.0.3）。

三、SQLT宝剑出鞘

1、SQLT生成确诊文件

生成确诊文件使用的是sqlt/run目录下的文件，此目录下还有SQLHC健康检测的脚本。这儿看一个反例：

SQLtext:

*

fromtest1

wheretest1.in(test2.fromtest2

wherelike'%');

这是条简单的子查询SQL，其中test1的有索引，并且有倾斜分布如下：

@ORADB>,count(*)

2fromtest1

3groupby;

COUNT(*)

-----------------

6

VALID76679

--子查询结果是

@ORADB>test2.fromtest2

2wherelike'%'

3;

-------

子查询中的句子返回的刚好是，这么可以预测，此句子应当是用子查询结果驱动表test1，走test.列的索引，正常的应当是走loops。OK，这么我们瞧瞧执行计划：

执行计划令人心寒，要晓得，对于表的统计信息是最新的且取样比列100%，但是也搜集了列的直方图，为何还走HASHJOIN，但是TEST1还走全表呢？先用SQLT确诊下，到sqlt/run目录下找到对应的脚本，之后输入SQLID,然后会将生成的文件打包。

@ORADB>@

PL/SQL.

:00:00:00.00

1:

oroftheSQLtobe()

Entervaluefor1:

2:

()

Entervaluefor2:

PL/SQL.

:00:00:00.00

Valueto:

:""

解压文件，即可见到如下内容：

这儿我们主要看main文件，这是主要内容以及10053等。

首先打开main文件，可以看见主要确诊内容：

可以看见，包括CBO的环境，执行计划以及历史执行信息，表，索引等对象统计信息都在这个main文件中，大部份时侯可以通过此文件，了解SQL效率不佳的缘由，例如执行计划变坏的时间段内刚好搜集了统计信息，这么可以快速定位可能是统计信息搜集不正确造成的。

通常情况下，都是先看执行计划，通过Plans目录找到Plans，可以点这些+，会显示对应的统计信息等内容：

在统计信息正确的情况下，CBO计算的返回结果行是76685行，而实际结果是6行，计算是实际的12781倍，这也许是有问题的。可以点开对应的+，瞧瞧统计信息：

TEST1的列搜集了直方图，并且是100%取样，没有任何问题。到此，这个简单的SQL很可能的情况就是：

针对以上两种情况，旁边会介绍解决方式，这儿先说下，为何这儿走了HASHJOIN，TEST1走了FULLTABLESCAN，结果集的计算的结果刚好是TEST1的行数呢，缘由在于：

综合以上诱因，CBO未能在运行期之前预知结果的具体值，继而引起优化器缺陷，走了不佳的执行计划（12C的plan可以解决这个问题）。

既然晓得是这个缘由，这么，就采用SQL绑定就可以了，详尽内容见下节。

2、SQLT快速绑定执行计划

SQL可以使用SQLT工具快速绑定，SQL就是对SQL降低了一系列HINTS，用处是不须要改写SQL，可以在数据库里直接管理。

对于COE工具SQL绑定有两类：

注意：假如SQL没有绑定变量，则通过生成的文件须要更改=>true,自动编撰储存过程或则做替换绑定的也须要更改=>true,以让所有SQL结构相同（字面量条件不同）的SQL都绑定上好的执行计划。

（对应的绑定计划的脚本在sqlt/utl目录下）

下边分别谈谈这两种绑定方法：

1）使用脚本直接绑定

针对SQL执行计划常常突变，当计划变差时侯，快速绑定到效率高的执行计划中。如下例：运行之后输入：

SQL>@.sql

1:

()

Entervaluefor1:

--------------------------

.006--效率高的计划

653

2:---------------次数输入须要绑定的,其实我们输入

()

Entervaluefor2:

最后生成文件，执行。

注意：假如SQL没有使用绑定变量，须要将生成文件的=>FALSE中的FALSE改成TRUE。

2）使用做替换绑定

3.1中的事例是因为CBO的缺陷造成难以判断子查询结果，进而造成走错了执行计划，这儿在12c之前须要绑定执行计划，由于没有现成的执行计划，所以须要自己写hints构造一条正确执行计划的SQL，之后通过SQLT的替换绑定，将正确执行计划绑定到原SQL中去。

先将原始SQL通过降低hints,让其执行计划正确，改建后的SQL如下：

/*+

(@"SEL$""TEST1"@"SEL$1")

(@"SEL$""TEST2"@"SEL$2""TEST1"@"SEL$1")

(@"SEL$""TEST2"@"SEL$2"("TEST2".""))

(@"SEL$""TEST1"@"SEL$1"("TEST1".""))

(@"SEL$2")

(@"SEL$1")

(@"SEL$2")

(@"SEL$")

('11.2.0.3')

NABLE('11.2.0.3')

*/*

fromtest1

wheretest1.in(test2.fromtest2

wherelike'%');

之后使用脚本做替换绑定，输入原始的和替换的：

@ORADB>@

1:

()

Entervaluefor1:

2:

()

Entervaluefor2:

----------------------------------------

.001

3:

()

Entervaluefor3:

to:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

:""

:""

:""

…

再度执行原始句子，可以看见，绑定执行计划成功，早已走了索引和LOOPS。

SQLT的快速绑定执行计划，在处理突发SQL性能问题中使用广泛，的确是一个十分好的工具，就像宝剑出鞘，削铁如泥。

3、快速确诊参数设置问题

某日夜里某系统一重要句子，迁移到新库后执行1小时都没有结果，原本很快（1s左右），业务人员焦躁万分。对应的句子如下：

FROM(A.ID,A.,A.,A.,A.

FROMA,

(,MIN()AS

FROM

WHERE>'08-APR-19'

ANDIDNOTIN

(IMEIFROMWHERETID='10')

GROUPBY)B

WHEREA.=B.

ANDA.=B.

ANDA.IDNOTIN

(IMEIFROMWHERETID='10')

ORDERBY)

WHERE<200

查看执行计划:

执行计划中出现，也就是子查询未能,因为使用的是NOTIN，然而回头一想，这是11g,有aware特点，应当不会出现才对，但是使用hints也无效。这么首先想到的就是检测aware参数是否设置，经过检测：

完全没有问题，这么在搜集统计信息、SQL、可以想到的参数设置都没有问题情况下，怎样解决呢？

因为查询转换受诸多参数设置影响，尽管aware早已开启，并且可能受其它参数或fix设置影响，为此，这儿可以使用SQLT的利器剖析，它会将已知参数、已知bug对应的fix逐一重新设置一遍，之后生成对应的执行计划，最后生成一个html文件，通过查看执行计划，找到对应的参数或则BUG。

SQLT中有、等诸多方式，对于慢的句子，建议使用方式。之后查看剖析结果与目标计划匹配的设置，因而找出问题。

使用，可以参考sqlt/utl/中的.txt。这儿须要将对应的SQL内容里加上：/*^^*/。

最终，生成的文件内容如下：

有8个执行计划的，对应的点进去，找到正确的执行计划对应的参数设置：

最终找到，原先和mup参数有关，这个参数，系统设置成FALSE，造成此子查询难以进行aware查询转换，重新设置后句子执行恢复到正常时间。

针对这样的情况，若果一个个参数去对比剖析，必然历时很长，使用SQLT的利器，可以快速找到对应的参数设置或已知BUG问题，例如一些新特点造成的SQL性能问题、SQL形成错误的结果等，都可以通过剖析，快速找到对应的参数，之后重新设置。

最后做个总结：SQLT里还有好多其他的功能，可以通过MOS查看对应的文章，SQLT在解决棘手的SQL性能问题时，的确是一把神器，如同宝剑出鞘，SQL性能问题无所遁形。

从过去40年至今，数据库的形态基本经历了传统商业数据库、开源数据库到云原生数据库的演化过程。云时代下数据库将怎样革新与创变？金融行业核心数据库迁移与建设怎么安全平稳展开？来全球敏捷运维大会上海站找寻答案：

让我们9月11日在上海共同凝望数据库发展改革更长远的未来！