分类： Blogs

发布于

如何调优SQL Server数据库包含EXISTS子查询的SQL语句（一）？

下面示例展示了一个带有Exists子查询的SQL语句。该SQL语句查询DEPARTMENT表中DPT_ID列的值和employee表中emp_dept列的值相等并且employee表中emp_id列的值大于2700000的记录。

SELECT *
  FROM DEPARTMENT
   where exists (select ‘x’
        from employee
        where emp_id > 2700000
        and emp_dept=DPT_ID)

下面是Tosska树结构执行计划，该sql语句执行需要2.23秒才能完成。

该执行计划显示了从[EMPLOYEE].[EMPLOYEE_PK]到[EMPLOYEE].[EMPS_DPT_INX]的两个哈希匹配，然后合并连接到排序的[DEPARTMENT]表。这个执行计划看起来很合理，但是在第一阶段从[EMPLOYEE]表扫描的记录数太多了，我们可以用比较小的[DEPARTMENT]表去扫描[EMPLOYEE]表来改善这条SQL语句。

下面让我将EXISTS子查询改写为IN子查询，但是执行计划并没有按照预期的改变。

select *
from   DEPARTMENT
where DPT_ID in (select  emp_dept
         from    employee
         where  emp_id > 2700000)

我将进一步的改写SQL，并且添加伪函数“isnull(emp_dept,emp_dept)”到查询列表中，但它不能停止哈希匹配到[EMPLOYEE].[EMPS_DPT_INX]的操作。

select *
from   DEPARTMENT
where DPT_ID in (select  isnull(emp_dept,emp_dept)
         from    employee
         where  emp_id > 2700000)

为了进一步停止“哈希匹配到[EMPLOYEE].[EMPS_DPT_INX]”这一操作,我尝试在子查询中添加“group by emp_dept”伪操作。

select *
from   DEPARTMENT
where DPT_ID in (select  isnull(emp_dept,emp_dept)
         from    employee
         where  emp_id > 2700000)
         group by emp_dept)

下面是最终改写后的执行计划，SQL Server首先对[DEPARTMENT]进行表扫描和EMPS_DPT_INX索引从[EMPLOYEE]中寻找RID的嵌套循环操作，因此[DEPARTMENT]表中的每条记录最多匹配一次[EMPLOYEE]。现在的执行速度是0.024秒，比原来的SQL快很多。

尽管改写的步骤有点复杂，但它可以由Tosska SQL Tuning Expert for SQL Server自动实现，并且它比原始SQL快了90多倍。

Tosska SQL Tuning Expert (TSES™) for SQL Server® – Tosska Technologies Limited

发布于

如何在不修改源代码的情况下调优Oracle应用程序包的SQL

介绍

应用程序包软件是为授权给第三方组织而开发的软件程序的集合。虽然软件包软件可以通过参数或表来满足用户的特定需求，但软件本身并不是专门为组织开发的。因此，用户不能拥有源代码，也没有方法修改嵌入式SQL语句来进行性能调优。有很多基于Oracle RDBMS的应用程序包，如Siebel、PeopleSoft JD Edwards、SAP等。为了帮助应用程序包的用户，Oracle提供了一些特性来帮助用户调优SQL语句，且不需要更改源代码。

SQL profile

它是由Oracle SQL Tuning Advisor生成的概要文件。SQL概要文件包含对错误估计的统计信息和辅助信息的更正。因此，SQL profile只是将优化器引导到一个更好的计划，但它们并不保证每次解析语句时都使用相同的计划。对于某些SQL语句，无论统计数据有多好，Oracle SQL optimizer仍然无法在特定的环境中生成更好的计划。对于这些类型的SQL语句，人工干预是必要的，但是对于开发人员来说，SQL profile不是一个方便的工具，在不更改程序源代码的情况下，不能强迫Oracle执行新的计划。

SQL plan baselines and stored outlines

由于Oracle环境的变化或Oracle数据库版本升级，它可能会针对Oracle SQL优化器为某些SQL语句生成新的计划。如果它不好，我们需要一些东西来保存旧的计划，以适应新的环境。为了实现SQL计划的稳定性，stored outlines是Oracle数据库早期版本中的主要工具。Oracle数据库11g仍然支持该特性;但是，在将来的版本中，它可能会贬值，并被SQL计划管理所替代。SQL Plan Baselines的机制是保持指定SQL语句的性能，而不管数据库环境的变化或版本升级。此外，还可以手动为SQL语句创建Plan Baselines，并且该技术可以帮助开发人员指导Oracle SQL优化器为性能较差的SQL语句生成特定的计划。因此，当Oracle SQL optimizer下次接收到相同的SQL语句时，将根据数据库中存储的新计划基线组成更好的性能计划。不需要更改源程序中的SQL语句。
例如，如果您想要调优一条执行plan-A计划的SQL(目前Oracle SQL optimizer在您的数据库中使用这条SQL)，并且您想要调优这条SQL(带有提示)，使Oracle SQL optimizer生成一个新的计划plan-B。你需要做的是用执行调优后的SQL（带新的提示），并使用Oracle提供的以下方法:

使用优化后带提示的SQL执行，并在SGA中缓存plan B。

SET SERVEROUTPUT ON
DECLARE
    My_Plan  PLS_INTEGER;
BEGIN
     My_Plan := DBMS_SPM.load_plans_from_cursor_cache(
              sql_id          => 'Plan-B SQL_ID',
              plan_hash_value => 'Plan-B plan_hash_value’,
              sql_handle      => 'Original SQL’s sql_handle');
      DBMS_OUTPUT.put_line('Plan Loaded=> ' || My_plan);
END;

要启用调优计划，手动将调优后的计划更改为固定计划，方法是将其FIXED属性设置为YES。
要启用SQL plan baselines，请确保optimizer_use_sql_plan_baslines初始化参数设置为TRUE。

使用SQL Plan baselines进行SQL调优的缺点

由于SQL Plan baselines的设计目的是为了在以下环境发生变化后保持SQL语句的性能:

  • 新的优化器版本
  • 更改优化器统计信息和优化器参数
  • 更改schema和元数据定义
  • 更改系统设置
  • SQL profile 创建

您可以看到，它不是为手动SQL调优而设计的。还有一些额外的限制，比如SQL Plan Baselines不支持Parallel Hints，您不能为你的SQL加载一个应用Parallel Hints的Plan-B，而原始计划Plan-A的性能很差。 有时候, Parallel Hints 在Oracle SQL optimizer中往往能生成更好的计划。

SQL Patches

SQL Patches是SQL Repair Advisor提供的特性之一，用于修复SQL语句的关键故障，比如返回错误的结果。 SQL Repair Advisor分析有问题的语句，并在许多情况下建议使用SQL patch来修复该语句。SQL patch将影响Oracle SQL优化器为将来的执行选择一个替代的执行计划，而不是使用原来有问题的执行计划。在Oracle Database 12c Release 2之后,提供了一个公共API来手动创建SQL patch。DBMS_SQLDIAG.CREATE_SQL_PATCH包可以帮助用户为特定的SQL语句创建用于SQL调优的SQL patch。你可以改变一个性能不好的SQL语句的执行计划，而不需要修改程序源代码, 如下:

DECLARE
    Patch_name  VARCHAR2(32767);
BEGIN
    Patch_name := SYS.DBMS_SQLDIAG.create_sql_patch(
        sql_text  => 'SELECT *
                      FROM   employees
                      WHERE  emps_dept IN
                     (SELECT dpts_id
                      FROM   departments
                      WHERE  dpts_avg_salary <200000)', hint_text => 'INDEX(@SEL$1 EMPLOYEES) INDEX(@SEL$2 DEPARTMENTS)',
        name      => 'my_sql_patch_name');
END;

如果数据库版本在Oracle database 12c Release 2之前，则必须使用DBMS_SQLDIAG_INTERNAL.i_create_patch包代替。SQL文本和SQL ID都可以用于SQL提示注入。为SQL注入的提示应该放在hint_text输入参数中。只有一行 Hints 文本可以用于SQL，而且无法为任何子查询块定义自己的查询块名称。因此，如果您的SQL有多个子查询，并且希望指示Oracle在子查询的块中执行某些操作，则必须在注入的 Hints 文本中使用Oracle默认的查询块名称。
hint_text => ‘ INDEX(@SEL$1 EMPLOYEES) INDEX(@SEL$2 DEPARTMENTS) ‘
上面示例中的提示文本显示@SEL$1和@SEL$2是Oracle在SQL执行计划中提供的默认查询块名称。提示告诉Oracle使用索引搜索查询块@SEL$1中的EMPLOYEES表，同时使用索引搜索查询块@SEL$2中的DEPARTMENTS表。

使用SQL Patches来调优SQL的优缺点

没有SQL Plan Baselines的限制，SQL patch更灵活地接受提示指令，带parallel操作的复杂提示通常能被SQL patch接受。在创建 SQL Patches之后，不需要额外的维护工作来告诉Oracle使用 SQL Patches。 Oracle将使用存储的提示优化任何具有相同SQL ID或SQL文本的SQL，并生成更好的性能执行计划。此外,您还可以使用 SQL Patches 来禁用已在包应用程序中写入的破坏性提示的 SQL,甚至使用它来控制一个具有绑定感知的SQL的执行行为。
由于注入的提示文本必须放在一个文本行中，并且只使用默认的查询块名称，因此手工编写一个预期的提示来改进SQL语句，对于大多数SQL开发人员来说是一项困难的任务，尤其是对于包含许多子查询的复杂SQL语句。

一个自动创建Hints和SQL Patches的工具

到目前为止，市场上只有一个工具能够生成更好的提示且完全自动化的方式创建SQL Patch。
Tosska SQL Tuning Expert Pro 是一个用户可以在不接触其程序源代码的情况下提高 SQL 性能的工具。用户可以为不同大小的生产数据库部署不同的性能查询计划，而不需要保存程序源代码的多个版本，并且特别适合于不拥有其应用程序源代码的包应用程序用户。该工具将尝试最有用的提示组合来调优性能较差的SQL语句，最好的提示组合SQL性能将与原始SQL并排进行基准测试。用户将得到准确的性能改进，没有任何猜测或不确定的成本评估。

您可以访问我们的网站了解产品详情
https://www.tosska.cn/tosska-sql-tuning-expert-pro-tse-pro-for-oracle-zh/

发布于

从另一个角度看为什么要使用Oracle In-Memory数据库选项

很多人都在谈论为什么或者为什么不在他们的应用程序中使用 Oracle In-memory 数据库，他们中的大多数都过于关注数据库的大小，或者它是否是 OLAP 应用程序。中小型数据库似乎不适合使用 Oracle In-memory数据库选项。但是，如果您的 OLTP 数据库存在性能瓶颈，并且您正在寻找解决方案，我认为 Oracle In-memory数据库选项应该位于您的解决方案列表中，尤其是在计划升级硬件时。

在Oracle In-Memory 数据库中，SQL优化器优化计划空间越来愈大
计划空间是数据库 SQL optimizer 在输入 SQL 语句之前将考虑的潜在处理方法的大小。更大的计划空间大小意味着数据库 SQL optimizer 将考虑处理 SQL 语句的更多潜在方法。因此，您的 SQL 语句有更多运行更快的机会。使用 Oracle In-Memory 数据库新的 In-Memory数据访问方法，Oracle SQL 优化器将在 SQL 语句执行之前考虑更大的计划空间。由于乘数效应，新的 In-Memory 执行计划步骤可能会导致计划空间大小发生巨大扩展。例如， In-Memory 包含 5 个表的 SQL 语句，每个表的访问方法的”Table Access Inmemory Full”步骤，结果是 C（5，1）+C（5，2）+C（5，3）+C（5，4）C（5，5）=5=10=10=5=1=31。但不要忘记，此乘法器适用于原始计划空间树中的每个执行计划，这意味着新计划空间大小可能比原始计划空间大 31 倍。

OLTP 数据库如何从 In-Memory 数据库中获得优势?
OLTP 数据库是面向事务的应用程序，它要求每个事务都有快速的响应时间，但这并不意味着在工作时间没有用于联机报告或数据整合的复杂 SQL。如果此类慢速的 SQL 语句与其他联机事务同时运行，则整体性能将受到影响。如果硬件升级是其中一个选项，应考虑使用 Oracle In-Memory作为替代解决方案之一。
下面的示例向您展示了OLTP SQL语句如何从使用Oracle In-Memory数据库选项中获益。
下面是一个典型的 OLTP SQL，对所有表都进行了分析，原始执行计划显示了一个 Oracle 自适应计划，其中哈希联接或嵌套循环将在执行的初始阶段确定。此 SQL 的运行时间约为 1 分 35 秒。

L让我们使用强制提示将 EMPLOYEE 表放入Oracle In-Memory中，然后 Oracle 访问它时，采用”Table Access Inmemory Full”扫描，下面的基准测试显示，“Auto 1” SQL仅花费0.45秒就完成了，比原始执行计划快200多倍。该解决方案表明，对EMPLOYEE表引入新的“Table Access Inmemory Full”扫描，创建了比原来更好的执行计划。

对于OLTP的SQL，不需要将所有表放入 In-Memory
使用 OLTP 数据库时，我们不希望将所有表填充到In-Memory，从而给联机事务带来过多的开销。因此，对于OLTP 的 SQL 使用 In-Memory SQL 调优的目标不是选择最佳性能解决方案，而是具有较少In-Memory表的最经济高效的解决方案，且其性能改进仍是可以接受的。
如下面： “Auto 3” 解决方案把包含的所有表都被放入In-Memory，但改进仅比 “Auto 1” 高 0.01 秒，后者只需要将一个表放入In-Memory。因此，”Auto 1″显然是一个更可取的选择。

Oracle应该根据 In-Memory 的大小为 In-Memory 选项装载
实际上，Oracle In-Memory数据库不仅仅有利于OLAP用户，而是对于所有数据库用户(比如OLTP用户)来说，都是一个很好的SQL性能增强工具。鉴于Oracle In-Memory 数据库选项定价过高，限制了该新技术的快速适应，建议Oracle根据 In-Memory 大小来决定价格。换句话说，更小的尺寸和更低的价格肯定会帮助 Oracle
In-Memory数据库可广泛渗透到所有数据库用户，包括 OLTP 用户。

Author: Richard To (Richard.to@tosska.com), CTO of Tosska Technologies Limited

发布于

释放强大的 Oracle Optimizer Hints 来优化SQL语句

常见的SQL调优方法
SQL 调优是提高 SQL 语句性能,达到用户期望的过程。开发人员或 DBA 通常使用三种方法，这些方法包括创建新索引、重写 SQL 语句和将 Oracle 优化器提示应用于 SQL 语句。每种方法都有其优缺点,适用于应用周期的不同阶段。让我们在下面讨论这三种方法。

为SQL语句创建新的索引
为SQL语句创建新的索引是提高SQL性能的一种非常常见的方法，在数据库开发过程中尤其重要。由于SQL语句的新索引不仅影响当前SQL，还影响同一数据库上运行的其他SQL语句。因此，在生产数据库中应谨慎使用。通常，用户需要对新创建的索引的其他相关SQL语句进行影响分析。

重写 SQL 语句
有很多人通过互联网教授 SQL 重写技能。这些重写规则大多都基于 Oracle 规则的 SQL 优化器或基于成本的 SQL 优化器的旧版本继承。例如,有些人可能认为以下 SQL 可能具有不同的性能:
Select * from A where A.unique_key in (select B.unique_key from B);
Select * from A where exists (select ‘x’ from B where A.unique_key=B.unique_key);
实际上，如果将这两个 SQL 放入 Oracle 数据库中,您可能会从 Oracle 获得相同的查询计划；这是因为 Oracle SQL 优化器将在内部将这两个 SQL 重写为一个标准形式,以便生成更好的查询计划。在过去的二十年中,Oracle SQL optimizer开发了一种更强大的内部重写能力。因此，Oracle已经解决了一些明显的问题，如“KEY IS NOT NULL”或“NVL(KEY， ‘ ABC ‘) = ‘ ABC ‘”不能使用索引。当然，对于复杂的SQL转换，Oracle SQL optimizer仍然存在一些限制，因此经验丰富的用户仍然可以通过SQL重写来调优SQL语句，从而影响Oracle SQL optimizer生成更好的查询计划。但是,由于 SQL 语法和最终查询计划生成之间的关系越来越弱,因此 DBA 越来越难以应用此方法,这是因为Oracle基于成本的优化器(CBO) 变得越来越智能,并且 SQL 文本的语法不再是成本计算和计划生成中的主导因素。
SQL 重写在开发和生产数据库中仍然很有用,因为它是对数据库的单独更改,并且不会影响其他 SQL 的性能,并且比创建新索引更安全。但是它需要在程序源代码中修改SQL语句，因此单元测试或集成测试可能仍是必需的。相反,使用提示来调整 SQL 相对更安全，因为不容易意外地更改SQL的语义。

对SQL语句应用提示
市场上的大多数数据库都提供了一些查询计划控制语言，以帮助其优化器更好地优化特定的 SQL 语句。例如:IBM LUW 优化指南和 SQL Server 计划指南已经提供了多年。Oracle 提供了嵌入 SQL 文本的优化器提示，用于告诉 Oracle SQL 优化器如何优化 SQL 语句。由于提示不会影响 SQL 语句的语义，因此它比 SQL 重写和生成新索引相对更安全。Oracle提供了超过100个文档化的优化提示。使用正确的提示来调整 SQL 是并不容易掌握，除非您是使用优化器提示的专家，即使是专家,如果从一百个提示中挑选只3个提示，那也是非常的困难的， 因为它是接近一百万的排列。
让我们用一个带有以下 Optimizer Hints 的简单SQL示例来展示优化提示是如何工作的，这些提示用于告诉Oracle SQL Optimizer在查询计划选择期间尽可能使用DEPARTMENT表的索引。Oracle将通过对DEPARTMENT表的索引检索，在所有计划中寻找成本最低的计划。
Select /*+ INDEX(@QB2 DEPARTMENT) */ *
From employee
Where emp_dept in (Select /*+ QB_NAME(QB2) */ dpt_id
    From department
    Where dpt_name LIKE ‘D%’);

Oracle SQL提示不是一种编程语言
Oracle Optimizer hint不是一种带有正确语法检查或错误返回的编程语言。这意味着一个无效的SQL语句提示指令，Oracle SQL优化器不会返回错误消息。此外，即使这是一条有效的提示指令，Oracle SQL优化器实际上不能遵守，也不会返回错误消息。因此，在影响SQL优化器生成特定的更好的查询计划之前，用户必须进行大量的反复试验。

了解解决方案
这是一个非常常见的调优实践，人们试图为性能较差的SQL语句找到最佳的查询计划，它的工作就像一个人模拟Oracle SQL优化器的工作，用人的知识优化SQL语句。如果SQL语句很简单，而且Oracle SQL优化器犯了一个明显的错误，那么人工干预对这种简单的SQL很有效。举个例子:
Select * from A where A.KEY<’ABC’;
如果Oracle SQL optimizer没有使用索引从表A检索记录，而使用索引KEY1实际上是一个更好的解决方案。您可以使用优化器提示来指示Oracle对该SQL语句使用索引而不是全表扫描。
Select /*+ INDEX(KEY1 KEY1_INX) */ from A where A.KEY1<’ABC’ and A.KEY2<123 and A.KEY3<’C’;
了解最佳解决方案对于简单的 SQL 语句来说很容易,但对于复杂的 SQL 语句来说却很难。由于复杂 SQL 的查询计划中有很多执行步骤,因此人类无法估计每个步骤并制定一系列查询步骤来组成最佳性能查询计划。因此,使用 Oracle 优化器提示来指示 SQL 优化器为复杂 SQL 生成特定的查询计划可能并不容易,即使对于经验丰富的 SQL 调优专家也是如此。

了解问题
与了解 SQL 语句的解决方案不同，人工专家可以相对更轻松地查找问题在复杂查询计划中的位置。告诉 Oracle 绕过此问题的方法是应用前缀为”NO_”的提示,如 NO_INDEX 或 NO_USE_HASH。它告诉 Oracle 不要在查询计划中使用指定的操作,而是选择成本较低的其他操作。这种方法在市场上并不普遍采用,因为人们通常受以解决方案为导向的思维的约束。
例如:
Select /*+ NO_INDEX(KEY2 KEY2_INX) */ * from A where A.KEY1<’ABC’ and A.KEY2<123 and A.KEY3<’C’;
如果您认为 KEY2_INX 不是从表 A 检索记录的好索引,则可以通过应用 /* NO_INDEX(KEY2 KEY2_INX)*/ 来禁用 KEY2 索引,并让 Oracle 选择其他索引来检索记录。

释放Oracle优化器提示的潜在功能
无论您是使用面向解决方案的方法还是问题绕过方法,您都需要了解 SQL 查询计划的详细信息、数据分布、每个步骤的成本,并尝试预测计划的最终实际聚合成本是什么。有时,您必须将这两种技术用于复杂的 SQL 语句;您必须为查询计划的某些部分提供最佳查询步骤,并使用”NO_”绕过查询计划中的已知问题。这是一个非常复杂的过程,如果没有对 SQL 调优的深入了解,普通 SQL 开发人员很难执行。
下面的示例显示了一个花费8.56秒完成的SQL，查询计划看起来很正常。SQL语法是完整的，因此没有太多空间进行SQL重写。可能并行执行可以帮助改进SQL语句，但是应该使用哪个表或索引进行并行执行，以及新的并行执行步骤如何影响整个查询计划。即使对于经验丰富的 SQL 调优专家来说,这也不是一件容易的事。这就是为什么Oracle优化器提示没有从一开始就被充分挖掘的原因。

借助最新的 AI 算法,计算机搜索引擎可以极大地释放用户发现提示组合的努力,而无需经历巨大的提示排列空间。它使 hint SQL调优变得更容易，并可以解决比您预期的更多的问题。
以下解决方案显示了一系列提示组合，这些提示组合告诉 Oracle 不要使用 EMPLOYEES.EMPSS_GRADE_INX 索引和排除哈希联接以联接表，然后使用表 EMPLOYEES 的并行索引扫描。它生成比原始计划快 70% 的新查询计划。整个调优过程无需人工干预即可完成,结果是安全的,因为它不涉及任何语法重写。


https://www.tosska.cn/tosska-sql-tuning-expert-tse-oracle-zh/

Tuning SQL without touching the its SQL text
如果您是一个应用程序用户,您可能想知道,如果无法直接编辑查询,如何调整 SQL。或者,如果您是应用程序开发人员，您希望快速修复 SQL 性能，而无需花时间进行思考源代码更改和单元测试。Oracle 提供了多个功能,例如 SQL 配置文件、SQL Plan Baselines和 SQL Patch， 您可以使用这些功能告诉 Oracle 修复 SQL 的查询计划，而不需要更改SQL文本。但是这些功能的使用仅受 Hints 注入的限制，您不能使用不同的语法重写 SQL，并且要求原始 SQL 接受重写的 SQL 查询计划。因此，在当今瞬息万变的数据库应用程序中，基于Hints的 SQL 调优变得越来越重要。
实际上,SQL 性能应该与应用程序源代码分离，SQL 性能应该易于管理，以便随时随地部署和回滚。它还应该为一个源 SQL 代码进行定制，以适应不同大小的数据库。基于hints的 SQL 调优将是释放 Oracle 数据库 SQL 性能管理潜在功能的关键，在现代数据库 SQL 调优过程中,它变得越来越重要。

发布于

揭示CBO的力量

揭示甲骨文数据库基于成本的SQL优化器的强大功能的示例

用户拥有需要很长时间才能执行的SQL语句；实际上SQL并不是很复杂，但它有一个非常复杂的执行计划。

Mimic SQL text ：
  SELECT TO_CHAR(SYSDATE, ‘yyyy-mm-dd’) AS STAT_DATE,
SYSDATE AS STAT_TIME,
X.TABLE_NAME,
NVL(X.NUM_ROWS, 0) AS TABLE_ROWS,
NVL(ROUND(X.NUM_ROWS * X.AVG_ROW_LEN / 1024, 2), 0) AS TABLE_SIZES,
Y.CREATED AS CREATE_TIME,
Z.COMMENTS AS TABLE_COMMENT,
H .COL_CNT
FROM ALL_TABLES X,
ALL_OBJECTS Y,
ALL_TAB_COMMENTS Z,
(SELECT H .TABLE_NAME, COUNT(1) AS COL_CNT
FROM ALL_TAB_COLS H
WHERE H.OWNER = ‘TOSSKA’
GROUP BY H .TABLE_NAME) H
WHERE X.TABLE_NAME = Y.OBJECT_NAME
AND X.TABLE_NAME(+) = Z.TABLE_NAME
AND X.TABLE_NAME = H.TABLE_NAME
AND Y.OBJECT_TYPE IN (‘TABLE PARTITION’, ‘TABLE’)
AND X. OWNER = ‘TOSSKA’
AND Y. OWNER = ‘TOSSKA’
AND Z. OWNER = ‘TOSSKA’
ORDER BY X.TABLE_NAME

执行计划：
以下部分计划步骤列出了总共214个执行计划步骤中的10%。

用户将SQL输入到Tosska SQL Tuning Expert for Oracle中，并按Tune开始探索是否只潜在有来自Oracle的更好的查询计划。 用户回到他的日常工作中，让计算机代他完成余下的调优工作。 最后，在一小时内找到了5个更好的SQL替代计划。

产品亮点
Tosska SQL Tuning Expert配备了一个人工智能引擎，可以针对有问题的SQL尝试最有效的Hints注入组合。 引擎可以深入探索Oracle CBO在在线SQL优化阶段无法发现的任何隐藏的良好执行计划，但这些好计划实际存在于SQL语句的计划空间中。


基准结果：
原始SQL需要14分7秒。
注入提示的最佳替代SQL是SQL 45，仅需4秒。
SQL45的运行速度比原始SQL快99倍。

Oracle CBO生成的查询计划的观察
Tosska SQL Tuning Expert是一个基于提示注入的SQL调优工具，无需重写用户的SQL。 因此，注入SQL语句的各种提示以及Oracle生成的相应查询计划都是Oracle SQL优化器可以为SQL语句提供的潜在查询计划。
让我们回顾一下那些生成的查询计划以及为什么Oracle在开始时找不到最佳查询计划的原因。

第一个观察：
原始SQL的成本是1330，但SQL 130，SQL 135和SQL 45的成本都低于原始SQL的成本，为什么Oracle无法获得这些低成本计划？
原因：
Oracle无法探索它可以在短时间内生成的所有潜在查询计划，否则它将需要更长的时间来优化所指定的SQL，而这可能无法以不能预见的更好的查询计划完全补偿的。

第二个观察：
SQL 127和SQL 129的成本比原始SQL高3倍，但速度比原始SQL快得多，这意味着这两个SQL的成本估算异常错误。
原因：
这是数据库SQL优化器中使用的成本估算算法的局限性。 从理论上讲，市场上没有100％准确的SQL成本估算算法可以处理各种环境，对于像上述SQL语句这样复杂的SQL语句尤其如此。

结论：
Oracle拥有市场上最复杂的SQL优化器。 Oracle有很多更好的查询计划可以让您的SQL语句更快地运行。 因此，当您考虑升级硬件或云服务支出时，都应首先探索Oracle SQL优化器为SQL语句提供的潜在能力，而您所需要的只是一个能够揭示Oracle SQL优化器潜在能力的正确工具。

Tosska SQL Tuning Expert (TSE™) ® for Oracle®

Tosska SQL Tuning Expert Pro (TSE Pro™) for Oracle®