23ai 的这个功能，让 DBA 离失业又更进一步

前言

Oracle 23ai 已经正式发布一段时间了，不过由于OP版只能在 Oracle Engineer System 上使用，所以在我们接触到的客户中真正使用 23ai 非常少。最近我们借助于 Oracle 提供的 Free 版本，针对新特性进行了系统的分析和学习，发现 23ai 真的是将 AI 功能贯彻的非常彻底的一个版本，以至于我都怀疑 DBA 是不是真的会失业！

本篇是 23ai 新特性系列文章的第一篇，介绍 SQL 分析报告，对新技术特性感兴趣的朋友可以点个关注，大家一起来学习。

随着数据库技术的不断进步，解决了系统稳定性的基础需求之后，管理员很大的一部分精力会放在系统的性能优化上，而 SQL 优化又是系统性能优化中非常重要的一环。在每一个版本中，Oracle 都会推出大量的新特性来提升 SQL 执行效率和稳定性，同时也会引入新的工具来帮助管理员快速诊断和分析问题，今天我们要聊的 SQL 分析报告，就是 23ai 中引入的新工具。

SQL 分析报告

SQL 分析报告的获取有两种方式，第一种方法非常简单，直接从 SQL 语句的执行计划中就可以直接看到。

SQL> select count(p.prod_id), sum(s.amount_sold) from sh.products p, sh.sales s;
COUNT(P.PROD_ID) SUM(S.AMOUNT_SOLD)
---------------- ------------------
               0
SQL> select * from table(dbms_xplan.display_cursor(format=>'typical'));
PLAN_TABLE_OUTPUT
----------------------------------------------------------------------------------------------------------------------------
SQL_ID  a3pb7v2ghbuf0, child number 0
-------------------------------------
select count(p.prod_id), sum(s.amount_sold) from sh.products p, sh.sales s

Plan hash value: 2206656582
----------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                       | Name                     | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
----------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                |                          |       |       |     3 (100)|          |       |       |
|   1 |  SORT AGGREGATE                 |                          |     1 |    13 |            |          |       |       |
|   2 |   MERGE JOIN CARTESIAN          |                          |     1 |    13 |     3   (0)| 00:00:01 |       |       |
|   3 |    PARTITION RANGE ALL          |                          |     1 |    13 |     2   (0)| 00:00:01 |     1 |    15 |
|   4 |     TABLE ACCESS FULL           | SALES                    |     1 |    13 |     2   (0)| 00:00:01 |     1 |    15 |
|   5 |    BUFFER SORT                  |                          |    72 |       |     1   (0)| 00:00:01 |       |       |
|   6 |     BITMAP CONVERSION TO ROWIDS |                          |    72 |       |     1   (0)| 00:00:01 |       |       |
|   7 |      BITMAP INDEX FAST FULL SCAN| PRODUCTS_PROD_STATUS_BIX |       |       |            |          |       |       |
----------------------------------------------------------------------------------------------------------------------------
SQL Analysis Report (identified by operation id/Query Block Name/Object Alias):
-------------------------------------------------------------------------------
PLAN_TABLE_OUTPUT
-------------------------------------------------------------------------------------------------------------------------
   1 -  SEL$1
           -  The query block has 1 cartesian product which may be
              expensive. Consider adding join conditions or removing the
              disconnected tables or views.

28 rows selected.

以上是一条简单的 SQL 语句，在 PLAN_TABLE_OUTPUT 部分给出了这条语句存在笛卡尔积，成本可能比较高，建议加上关联条件或者移除掉相关的表或视图。接下来我们也测试了一些 SQL 语句中常见的规范，比如 UNION 会建议调整为 UNION ALL，WHERE 条件左边有表达式的，会建议对 SQL 语句进行改写。

除了通过执行计划来获取 SQL 分析报告之外，还可以在 SQL Monitor 报告中获取到这部分信息。默认 SQL Monitor 只抓取执行时间超过 1s 的 SQL，这里我们加上了 MONITOR hint，让没有满足条件的 SQL 也会生成监控报告。

select /*+ monitor*/ count(prod_id) from sh.products where substr(prod_id, 1, 2) = 100;

对于这条 SQL 语句，生成了如下图的 SQL 监控报告。

相比于之前版本的 SQL Monitor 报告，23ai 中新增了 SQL Analyze 页面，对于 WHERE 条件左边出现的表达式，给出了改写的建议。

写在最后

综合来看，当前的 SQL 分析报告还比较初级，针对常见的规则能够给出相关的调整优化建议，但是对于更复杂的场景，比如标量子查询等更为深入和隐蔽的情况，没有能够给出相应的建议。但从以往 Oracle 功能演进路线特点来看，往往在某个版本中引入某个新特性，然后结合客户使用反馈在后续版本中快速迭代，使得这些新功能能够很快成熟起来，进而推广到更多的使用场景。尽管当前 SQL 分析报告中所引入的规则还比较有限，对于复杂问题的分析还不是很完善，但是这一部分功能架构已经搭建起来了，接下来只需要在其中添加更多的规则，就能够覆盖更多的场景。

开发人员对于优化规则的掌握通常不如专业的数据库DBA，有了 SQL 分析报告后，开发人员可以更为便捷的获取到 SQL 中存在的问题和相关的调整优化建议，从而在应用上线前规避掉这些常见的错误，避免将劣质的 SQL 引入到生产环境，引发更为严重的问题。

源头上的问题少了，数据库管理员发挥作用的场景更少了，DBA离失业又进一步了 ！