分类： News

发布于

如何让SQL语句运行得更慢…但让用户的体验更好(Oracle)？

您的最终用户可能会不断抱怨他们的数据库应用程序的某些功能运行缓慢，但您可能会发现，在当前的Oracle和硬件配置中，这些SQL语句已经达到了它们的最大速度。除非您愿意升级硬件，否则可能没有办法改进SQL。有时，为了让用户感觉更好，您不必调优SQL以使其运行得更快，而只需调优SQL以使某些应用程序的SQL语句运行得更慢。

这是一个示例，该SQL用于显示表Emp_sal_hist和表Employee在满足某些条件后的信息。该SQL是在线查询执行的，用户必须等待至少5秒，才能在单击鼠标后在屏幕上显示任何数据。

select * from employee a,emp_sal_hist c
where a.emp_name like ‘A%’
 and a.emp_id=c.sal_emp_id
 and c.sal_salary<1800000
order by c.sal_emp_id

下面是SQL的执行计划和执行统计，提取全部79374条记录花费了10.41秒，第一条记录返回的反应时间为5.72秒。该查询显示了EMPLOYEE和EMP_SAL_HIST表的MERGE JOIN，在将其合并到最终结果之前，对两个相对应的表进行排序操作。这就是用户必须等待至少5秒才能看到屏幕上显示的内容的原因。

作为条件“a.emp_id = c.sal_emp_id”，我们知道“ORDER BY c.sal_emp_id”和“ORDER BY a.emp_id”是等效的，因为SQL语法改写不能强制对该SQL的执行计划进行指定的操作，所以我添加了一个优化器提示/*+ INDEX(@SEL$1 A EMPLOYEE_PK) */来减少“order by a.emp_id”的排序时间。

SELECT   /*+ INDEX(@SEL$1 A EMPLOYEE_PK) */ *
FROM   employee a,
     emp_sal_hist c
WHERE  a.emp_name LIKE ‘A%’
   AND a.emp_id = c.sal_emp_id
   AND c.sal_salary < 1800000
ORDER BY c.sal_emp_id

虽然在新的执行计划中，总体运行时间增加了3秒，但响应时间从5.72秒减少到1.16秒，因此用户可以更快的看到屏幕上第一页信息。我相信大多数用户不在乎是否还有3秒可以返回所有79374条记录。这就是为什么在管理用户期望时，SQL调优更像一门艺术而不是科学。
这种改写可以由Tosska SQL Tuning Expert Pro for Oracle自动实现。

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

发布于

如何调优SQL Server性能不好并且设置返回行数的SQL语句？

在设置返回行数或者使用Top关键字后，某些SQL语句会运行的非常慢。设置返回行数和使用Top关键字会告诉SQL Server从SQL语句中选择特定行数而不是提取所有记录。没有多少人知道在设置返回行数或者使用Top关键字后SQL Server会尝试重新优化您的SQL语句，重新优化后的SQL语句产生的执行计划通常可以更快的检索前几条记录，但是也可能适得其反。

设置返回行数重新优化查询的好示例
下面是一个示例，显示了该SQL从数据库中检索217500行记录需要6.78秒。这是一个好的执行计划，因为它对[DEPARTMENT]和[EMPLOYEE]的两个表扫描进行哈希匹配。

下面屏幕显示了设置返回行数为1后新的执行计划把哈希匹配改为嵌套循环。嵌套循环操作通常提供更快的前几条记录检索时间，但在某些情况下可能不利于整体记录的提取。很高兴看到SQL Server提取此SQL的第一行记录仅用了0.013秒。

设置返回行数重新优化查询的坏示例
让我们来看一个坏示例，它展示了在使用设置返回行数为1后，SQL Server如何将一个好的执行计划变成一个糟糕的执行计划。下面一个示例显示，该SQL从数据库中检索1613行记录花费了0.118秒，虽然该执行计划有点复杂，但对于检索完所有行来说是一个很好的执行计划。

下面屏幕显示了设置返回行数为1后生成的新执行计划，该执行计划现在更改为带有两次表扫描的嵌套循环。新的执行计划提取第一条记录需要1.312秒，比从数据库提取所有行所用的0.118秒还要慢。

如何解决这个问题呢？
我们可以使用提示注入或者SQL语法改写来影响SQL Server为设置返回行数或者Top关键字操作改回原始的执行计划或者生成更好的执行计划。下面是提示注入生成的一个很好的执行计划，它比设置返回行数为1的原始SQL快了90倍。

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

发布于

如何调优SQL Server的冷缓存SQL语句？

对于不经常执行的SQL语句，相关的数据可能不在缓存区，冷缓存会显著的影响这类SQL语句的性能。 用于热缓存的高性能SQL语句在冷缓存环境中可能表现的不好。经验丰富的开发人员会调优他们的SQL, 使其在两种情况下都能得到良好运行。

下面是一个SQL示例：
select * from
EMPLOYEE A
 where A.EMP_ID IN (SELECT B.EMP_ID from EMP_SUBSIDIARY B
     where B.EMP_DEPT < ‘D’)

下面是Tosska的树结构执行计划，第一次执行因为缓存延迟需要8.024秒，第二次执行无需缓存延迟只需要3.7秒。

根据执行计划，您可能发现IO消耗最多的是[EMPLOYEE]表的表扫描。为了模拟冷缓存环境，我们可以在每次执行SQL语句前使用DBCC DROPCLEANBUFFERS命令来清除数据缓存。

让我为这条SQL添加OPTION(LOOP JOIN)提示,并尝试将执行计划的哈希匹配更改为嵌套循环连接。因此，将使用[EMPLOYEE]的EMP_ID(EMPLOYEE_PK)和RID查找，而不是使用表扫描。我希望RID查找可以从硬盘中选择较少的数据，同时在[EMPLOYEE]和[EMP_SUBSIDIARY]中匹配EMP_ID。

select *
from   EMPLOYEE A
where  A.EMP_ID in (select  B.EMP_ID
          from   EMP_SUBSIDIARY B
          where  B.EMP_DEPT < ‘D’) OPTION(LOOP JOIN)

根据下面的执行计划，携带数据缓存开销的执行时间从8.024秒减少到1.565秒，物理读也从190,621减少到39,044。如果您用SQL Server的EstimateIO乘以EstimiateExecutions来得到IO估计值，这是错误的。

下面的人工智能调优工具还提供了其它更好的调优解决方案：

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

下面带有提示的SQL语句生成一个更复杂的执行计划，最好的执行时间为0.7秒。该SQL是在冷缓存下进行调优的，每次执行SQL语句之前都会清除缓存数据。

发布于

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

在我上一篇文章中，带有Exists子查询的SQL语句通过以下改写执行速度快了90倍。

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

执行计划：

改写的SQL语句：

select *
from   DEPARTMENT
where DPT_ID in (select  isnull(emp_dept,emp_dept)
         from    employee
         where  emp_id > 2700000)
         group by emp_dept)
执行计划：

语法改写的解决方案
DBA或者开发人员通常使用语法改写技术来改进SQL语句，尤其是对于Oracle或者MySQL数据库，但对于MS SQL Server或者IBM Db2 LUW的用户来说语法改写并不容易使用。原因是MS SQL Server和IBM Db2 LUW在它们的SQL优化器中有一个强大的内部改写引擎。这个内部SQL改写引擎会尝试将SQL语法改写为它们的内部规范语法。这意味着，无论您如何改写您的SQL语句，MS SQL Server或者IBM Db2 LUW都会尝试将SQL重新改写回它们内部假定的最优语法。所以如果假定的最优语法不好，就很难调优SQL。因为用户不容易通过简单的SQL改写来影响数据库SQL优化器生成更好的执行计划。

查询提示解决方案
为了解决这个问题，SQL Server为用户提供了查询提示功能，以帮助它的SQL优化器生成更好的执行计划。 它不像SQL改写方法，经验丰富的开发人员可能会说出改写SQL的最终执行计划是什么。查询提示是一个精确的解决方案，它通常应用于整个执行计划中的特定步骤，但对特定步骤的更改将会对整个执行计划的其他步骤产生多米诺效应。因此MS SQL Server必须调整其它步骤以实现用户对SQL语句中查询提示的预期。所以最终的执行计划并不容易被用户预测，尤其是对复杂的SQL语句。

以下由Tosska SQL Tuning Expert生成带提示的SQL比原来的SQL快了4倍左右，耗时0.639秒。

select  *
from    DEPARTMENT
where    exists (select  ‘x’
        from   employee
        where emp_id > 2700000
           and emp_dept = DPT_ID) OPTION(LOOP JOIN,HASH GROUP)

还有一个带提示的SQL,它比原始的SQL快了50倍左右，只需0.055秒。这个执行计划非常接近我上一篇文章中的改写调优。

select  *
from    DEPARTMENT
where    exists (select  ‘x’
        from   employee WITH(INDEX(EMPS_DPT_INX))
        where emp_id > 2700000
           and emp_dept = DPT_ID)

语法改写加提示的解决方案
对于一些SQL语句，语法改写或者提示方法可能无法单独解决一个复杂的SQL性能问题，有些人可能会想，是否有可能同时改写和应用提示来改进一条SQL语句？是的，这在Tosska SQL Tuning Expert人工智能引擎中是可能的，这种技术可以解决更多的SQL性能问题。稍后我将在我的博客中讨论这项技术。

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

下面显示Tosska SQL Tuning Expert在考察300种加提示的SQL写法后挑选出178条等价SQL，这远远超出了一个专家在10分钟内所能达到的水平。MS SQL Server是市场上对提示注入最敏感的数据库，SQL Server的查询提示通常能够影响SQL优化器生成特定的执行计划，因此MS SQL Server的SQL调优远比其他数据库更具挑战性。

发布于

如何调优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

发布于

Tosska软件有限公司宣布正式发布Tosska SQL Tuning Expert (TSEM™) for MySQL® 1.1.0 版

世界上少有的基于人工智能(AI)引擎的MySQL®数据库SQL调优产品

Apr. 10, 2020

2020年4月10日，香港 – Tosska Technologies Limited (Tosska), 一家专注于提供数据库SQL相关性能优化解决方案的公司, 今天宣布其用于提高MySQL® SQL性能的「一键式机器调优」产品，Tosska SQL Tuning Expert (TSEM™) for MySQL® 1.1.0 版本面市

SQL调优对于每个DBA来说都是一个经典问题，它存在于每个数据库中，包括MySQL® 数据库，现在每天都有成千上万的任务关键型应用程序在上面运行。在很长一段时间以来，MySQL领域的DBA们一直寻找一种易于使用但功能强大的工具来满足他们的SQL调优需求。借助Tosska SQL Tuning Expert (TSEM™) for MySQL®, MySQL的DBA们终于梦想成真了。MySQL的DBA们现在可以在不需要人工干预的情况下一键SQL调优，使得这一繁琐，有时不可能的SQL调优任务成为了可能和容易。

Tosska的CEO，KaMing Ng说到：「用户对我们的Tosska SQL Tuning Expert for Oracle®产品为他们的日常SQL调优工作带来的一系列好处而感到兴奋。许多人一直问我们什么时候可以把这个简单易用的一键式SQL调优工具带到MySQL®。今天我很自豪的宣布Tosska SQL Tuning Expert (TSEM™) for MySQL®, 这是世界上少有的MySQL®数据库基于人工智能(AI)引擎的SQL调优产品。」

Tosska的CTO，Richard To说到：「在MySQL® 的市场中有声音说他们需要一个强大的SQL调优工具，以减轻他们的工作。很不幸的是，目前市场上现有的SQL调优工具都不能满足这一需求。因此，我们决定构建一个自己的MySQL®特定SQL调优工具。Tosska SQL Tuning Expert (TSEM™) for MySQL® 跟Tosska 的TSE™ for Oracle® 产品系列一样使用了相同的AI SQL调优技术，但特别针对MySQL数据库进行了修改和优化。除此之外，我们还为MySQL®数据库增加了Tosska专有的tree plan，不仅拥有令人满意的丰富的MySQL®数据库信息，例如Tubular Explain，而且还拥有一个像在Visual plan中显示的层次结构。其优点在于所有的信息都可以在一个小窗口中显示，便于阅读。」

Tosska SQL Tuning Expert (TSEM™) for MySQL® 现在可以从Tosska的网站上免费下载试用。详情请访问Tosska网站www.tosska.cn。

   
关于Tosska
Tosska Technologies是一家专注于为数据库和SQL相关性能优化和改进提供解决方案的公司。我们的使命是通过我们的新技术帮助用户消除障碍。此外，Tosska是世界上为数不多的专注于使用人工智能技术解决各种数据库性能问题的公司之一。我们的目标是帮助客户减少硬件投资; 提高他们的数据库应用程序服务水平，利用我们的创新技术，为更多的战略活动腾出人力资源。更多信息请访问www.tosska.cn 或发邮件至 enquire@tosska.com。

新闻和媒体咨询
KaMing Ng
Chief Executive Officer
Tosska Technologies Limited
电话：+852-21501987
邮箱：enquire@tosska.com

All Trademarks mentioned on this Site are the property of their respective owners.

发布于

如何在不修改源代码的情况下调优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/

发布于

Tosska Technologies宣布推出其旗舰SQL性能调优产品 – 适用于Oracle®的Tosska SQL调优专家（TSE™）

创新的SQL语句优化工具

Dec. 18, 2017

Hong Kong, December 18, 2017 – Tosska Technologies Limited（Tosska）是一家专门提供数据库和SQL性能相关工具的IT公司，今天宣布推出他们的第一个提供机器调整功能以改善Oracle® SQL性能的产品Tosska SQL Tuning Expert（TSE™）。

SQL调优是每个DBA都会遇到的标准问题。 调优SQL语句就是要找到执行SQL语句的最快路径。 为了调优SQL语句，您需要了解数据库体系结构并具有SQL调优技能的深入知识。

「市场上有很多SQL调优技巧，但大多数只在特定的数据库环境中才有用。 您需要在数据库上手动逐个尝试这些提示。 这不仅耗时，而且也无法保证您能为SQL语句找到最佳性能的解决方案，」Tosska首席执行官伍家铭说。 「对于DBA或有经验的SQL开发人员来说，调整有问题的SQL语句可能需要数天或数周的时间。 SQL调优是一项非常需要技巧的工作，在很多企业中，他们的开发人员都无法执行这样的工作。 这些昂贵且宝贵的时间是否应该节省并用于公司内部其他更高效的任务？ 这就是我们设计TSE来解决这个问题的原因。」

「TSE™背后的设计理念是提供一种机器调优工具，可以在不需要用户参与的情况下优化SQL语句。 用户只需要将有问题的SQL语句输入到工具中并按下按钮，然后工具就会处理其余部分，无需用户在整个SQL调优过程中进行分析，猜测或测试，」Tosska首席技术官杜伟业表示。「TSE™通过使用Tosska发明的嵌入式人工智能（AI）引擎的专有技术，来模仿人类专家的SQL调优过程，来实现这一目标。调优引擎会在指定的配额内，为SQL语句尝试每种可能的有效Oracle Hints组合以改进执行的速度。 由于SQL语句的Oracle Hints组合的排列非常庞大，因此人类专家是无法为复杂的SQL语句完成这样的调优的。」

TSE™现在可以从Tosska的网站免费下载。 有关详细信息，请访问Tosska的网站www.tosska.com。

关于 Tosska
Tosska Technologies是一家专注于为数据库和SQL相关性能优化和改进提供解决方案的公司。我们的使命是通过我们的新技术帮助用户消除障碍。此外，Tosska是世界上为数不多的专注于使用人工智能技术解决各种数据库性能问题的公司之一。我们的目标是帮助客户减少硬件投资; 提高他们的数据库应用程序服务水平，利用我们的创新技术，为更多的战略活动腾出人力资源。更多信息请访问www.tosska.com 或发邮件至 enquire@tosska.com。

新闻和媒体咨询
KaMing Ng
Chief Executive Officer
Tosska Technologies Limited
Phone: +852-28248420
Email: enquire@tosska.com

All Trademarks mentioned on this Site are the property of their respective owners.

发布于

从另一个角度看为什么要使用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 调优过程中,它变得越来越重要。