从一条巨慢SQL看基于Oracle的SQL优化(重磅彩蛋+PPT)

本文根据DBAplus社群第110期线上分享整理而成，文末还有好书送哦~

讲师介绍

丁俊

新炬网络首席性能优化专家

SQL审核产品经理

• DBAplus社群联合发起人、《剑破冰山-Oracle开发艺术》副主编

• Oracle ACEA，ITPUB开发版资深版主，十年电信行业从业经验

本次分享的内容是基于Oracle的SQL优化，以一条巨慢的SQL为例，从快速解读SQL执行计划、如何从执行计划中找到SQL执行慢的Root Cause、统计信息与cardinality问题、探索性能杀手Filter操做、如何进行逻辑重写让SQL起飞等多个维度进行解析，最终优化巨慢SQL语句，但愿可以抛砖引玉，和你们一块儿探讨SQL优化方法。

另外，还简单介绍了两种解决疑难SQL优化问题的工具：10053和SQLT，特别是SQLT，每每在机关用尽过程当中，可能创建奇功，建议你们抽空研究下SQLT工具。最后对本次分享进行总结和思考：分享SQL Tuning RoadMap以及SQL Tuning最佳实践的相关内容。

大纲以下：

从一条巨慢的SQL开始

这条巨慢SQL执行预计耗时12小时以上，返回百万行数据。首先咱们接手一条SQL优化问题，至少须要作如下两件事：

1. 了解SQL结构：SQL中使用了哪些语法，这些语法是否是常常会致使性能问题，好比标量子查询的滥用。

2. 获取执行计划：执行计划反应了SQL的执行路径，直接影响了SQL的执行效率。如何从执行计划中找出问题，是SQL Tuning的关键。

言归正传，先揭开巨慢SQL的神秘面纱：

这条语句其实就是查询DEALREC_ERR_201608表，有各类复杂的子查询，初看此子查询，我基本已经了解问题大概出在什么地方了，先卖个关子，看执行计划先：

这种执行计划拿到手，其实很容易找出问题：

（1）分析指标问题：Rows，也就是每步骤的cardinality很小，说明每步返回的结果行数不多。这点值得怀疑。

（2）因为cardinality不多致使了Operation走了一系列Nested Loops操做，咱们知道，NL操做，通常是驱动表返回的结果行数不多，被驱动表走索引，返回的最终结果比较少（通常最多几千行），效率会很高。

以上两点值得注意：若是cardinality是准确的，那么这个执行计划中走一系列Nested Loops的部分应该没有多大问题，可是，若是cardinality不是准确的呢？那就是大问题。这也就是一些初级开发人员的思惟同样，常常喜欢对数据的处理使用循环，若是循环的次数少那还好，若是循环次数不少，那就会很慢。循环操做彻底依赖于循环的次数，从SQL执行计划里看，也就是依赖于驱动表返回的结果行数，很显然，这种不适合大量数据运算。

（3） 在ID=1中有个Filter，这个Filter的子操做是ID=15~18的全表扫描。Filter但是执行计划里的一个大问题，固然，这里的问题Filter必须有2个或2个以上子节点的操做，若是是单节点，那只是简单的过滤条件而已。

对于通常的SQL优化，必须得分析SQL的语法结构，语义以及解读SQL执行计划，以SQL执行计划为基准，分析执行计划中的问题，来进行SQL Tuning，基本能解决大部分SQL优化问题了。

固然，以个人理解，SQL优化不只须要很强的逻辑思惟、正确的理论指导、各类SQL语法的精通、熟悉index的使用、了解CBO相关内容，甚至还需从大局观进行把控：物理模型的设计以及对具体的业务分析。

快速解读执行计划

1

快速解读执行计划要点

SQL执行计划做为SQL优化的一把钥匙，必需要很好地利用起来。常常看到开发人员喜欢用PL/SQL Developer之类的工具来看执行计划。这里我得提醒下，这种内部调用的是Explain Plan For，可能不够准确，特别是有绑定变量的状况下，最重要的一点，对于长的SQL执行计划，简直无法进行分析。我的仍是喜欢文本类型的执行计划，特别是真实的执行计划，能获取A-ROWS，E-ROWS这些指标的执行计划，让我对执行计划中的问题尽收眼底，特别对于巨慢的SQL，也能够运行个几分钟中断后获取部分信息来协助判断。

执行计划要点以下：

• 找入口：经过最右最上最早执行原则找出执行计划入口操做。对于巨长执行计划Copu到UE里使用光标缩进下探法则可找出入口，因为执行计划是锯齿状结构，父节点的子操做是向右缩进的，所以，从ID=0开始，光标向下向右缩进下探，直到缩进不了中止，而后按照同级别的，也就是格式的垂直线是同一级的，上面的是入口。

• 看关系：各操做之间的关系：Nesed Loops、HASH JOIN、Filter等是否准确，以及操做的顺序是否准确，直接关系此操做甚至影响整个SQL的执行效率。

• 理顺序：一步走错，满盘皆输。经过理清执行计划顺序找出key steps。

• 重操做：执行计划中的Operation和Predicate部分是须要关注的核心内容，从操做中看出不合理部分，以此创建正确索引等优化措施。

• 求真实：执行计划中指标是估算的，估算的指标和实际状况极可能不匹配。因此优化SQL须要了解每步骤真实的基数、真实执行时间和Buffer gets等，从而准确找出问题Root cause。（能够根据谓词手动计算、建议采用display_cursor方式获取A-ROWS、A-TIME等信息，工具备不少，也可使用sql monitor等），若是采用Explain Plan For、SET AUTOTRACE之类的看执行计划，因为指标信息是不许的，要获取真实的信息，还须要手动根据谓词去计算，而后比较估算的和真实的差异，从而判断问题。

• 轻成本：COST虽然是CBO的核心内容，但由于执行计划中COST不必定准确反应SQL快慢，所以不要惟COST论，COST只是一个参考指标，固然能够经过执行计划判断一些COST是否明显存在问题，好比COST很是小，可是SQL执行很慢，可能就是统计信息不许确了。

2

快速解读执行计划实例

以上执行计划入口是ID=6(全表扫描)，返回行数1，以后与ID=7的作Nested Loops操做。详细见分析部分。

• 问题：为何要寻找执行计划入口？为何要分析执行计划各步骤顺序和关系？

各类操做之间的关系是由cardinality等各类因素触发的，不正确的cardinality会致使原本应该走HASH JOIN的走了Nested loops Join。每每入口处就有问题，致使后续执行计划所有错误，因此明确各类步骤的关系，有助于找出影响问题的根源步骤。

理清执行计划顺序，有助于理解SQL内部的执行路径，经过执行的实际状况判断出不合理步骤操做。

• 重操做、求真实、轻成本是经过执行计划优化SQL的重要方法。

这里的入口是ID=6的全表扫描，返回行是1行，不是准确的，很显然，找到入口的问题，已经能够解决一部分问题了。

从执行计划看SQL低效根源

• 主表DEALREC_ERR_201608在ID=6查询条件中经查要返回2000w行，计划中估算只有1行，所以，会致使Nested Loops次数实际执行千万次，致使效率低下。应该走HASH JOIN，须要更新统计信息。

• 另外ID=1是Filter，它的子节点是ID=2和ID=1五、1六、1七、18，一样的ID 15-18也被驱动千万次。

找出问题根源后，逐步解决。

第一次分析：解决ID=6步骤估算的cardinality不许确问题。

统计信息与cardinality

1

解决cardinality估算不许确问题

• 找出入口操做ID=6,因为ID=6操做的cardinality估算为1致使后续走一系列Nested Loops影响效率。

• cardinality的计算与谓词紧密相关，因此要找出ID=6的谓词，根据谓词手动计算真实card与估算card之间的区别。

• 尝试收集统计信息，检验效果。

如今的问题，也就是转为对表DEALREC_ERR_201608统计信息准确性的问题，特别是统计信息对谓词计算的准确性。

2

解决cardinality估算不许确问题-扩展统计信息收集

• 尝试更新统计信息：

发现使用size auto,size repeat,对other_class收集直方图均无效果，执行计划中对other_class的查询条件返回行估算仍是1（实际返回2000w行）。如何解决？card的计算和谓词紧密相关，查看谓词：

substr(other_class, 1, 3) NOT IN (‘147’,‘151’, …)

怎么办？思绪万千，灵光乍现！

Hints:cardinality(a,20000000)，use_hash等能够。

还有更好的办法吗？

忽然想起11g有个统计信息收集新特性：扩展统计信息收集。

exec DBMS_STATS.GATHER_TABLE_STATS(ownname=>‘xxx',tabname=>‘DEALREC_ERR_201608',method_opt=>'for columns (substr(other_class, 1, 3)) size skewonly',estimate_percent=>10,no_invalidate=>false,cascade=>true,degree => 10);

扩展统计信息一收集，执行计划以下：

• DEALREC_ERR_201608与B_DEALING_DONE_TYPE原来走NL的如今正确走HASH JOIN。Build table是小结果集，probe table是ERR表大结果集，正确。

• 可是ID=2与ID=11到14，也就是与TMI_NO_INFOS的OR子查询，仍是FILTER,驱动数千万次子节点查询，下一步优化要解决的问题。

• 性能从12小时到2小时。到这里结束了吗？

统计信息的问题仍是不少的，一个表的统计信息收集，特别是自动收集，不必定能让全部相关SQL找到最佳执行路径，特别是SQL条件复杂、数据倾斜、表类型定义不许确等状况，特别是使用了复杂条件，CBO没法准确计算对应谓词的card，或者类型定义不许确，原本是日期的用了VARCHAR2，内部所有要转为数字来计算选择性，很显然，乱定义列类型也是有问题的。因此有针对性地修正收集的统计信息，是颇有必要的。

3

解决cardinality估算不许确问题-有关统计信息的那些疑问

• 疑问1：100%收集为何尚未走正确执行计划？

统计信息收集比例高不表明就能够翻译对应谓词的特征，并且统计信息内部有不少算法限制以及不完善的状况，好比11g的扩展统计信息来继续完善，12c也有不少统计信息完善的特性。因此并非比例低就很差，比例高就好！统计信息的收集要知足核心SQL的执行效率，对于非核心SQL必定程度上能够不用过分关注，由于统计信息很难知足全部相关SQL的最佳执行。

• 疑问2：统计信息各类维度收集了包括直方图都收集了怎么不起做用？

直方图有不少限制，12c以前，只有频度直方图和等高直方图两种，对不少值的分布不能精确表示，因此有不少限制。所以，12c又增长了2种直方图：顶级频度直方图和混合直方图。另外直方图还有只存储前32位字符的限制。

• 疑问3：直方图只对走索引的有做用？

很显然不对，直方图只是反应数据的分布，数据的分布正确，对应谓词能够查询出比较准确的cardinality，从而影响执行计划，因此对全表也是有用的。

• 疑问4：收集或更新了统计信息，执行计划怎么变得更差了？

颇有可能，好比把原来的直方图给去掉了可能致使执行计划变差。所以，通常更新使用size repeat，除非是确认须要修改某些直方图，另外谓词和统计信息紧密相关，某些谓词条件一旦收集统计信息，可能就计算不许确了。

• 疑问5：执行计划中cardinality显示的和已有统计信息计算不一致？

Oracle CBO内部算法很复杂，并且Bug众多，遇到问题要大胆怀疑。

• 疑问6：统计信息应该按照Oracle建议自动收集？

具体问题具体分析，是让Oracle自动仍是本身写脚本收集，都须要长期实践总结，对于一个复杂系统来讲采样比例和method_opt不少须要定制设置。

• 疑问7：为何惟一性很好的列，还须要收集直方图？

选择性的内部计算是要转成数字的：CBO内部计算选择性会先将字符串转为RAW，而后RAW转为数字，左起ROUND15位。若是字符串的惟一性好， 可是计算成数字后惟一性很差，则会致使执行计划错误，这时候也须要收集直方图。

• 疑问8：我须要根据统计信息以及CBO公式去计算COST吗？

不须要，除非你很喜欢研究，这样作只会得不偿失。了解各类JOIN算法、查询转换特性、索引等效率和哪些有关便可，COST不是最须要关心的指标，咱们应该关心SQL高效运行所需的执行路径和执行方法，是否能够达到及早过滤大量数据，JOIN方法和顺序是否正确，是否能够创建高效访问对象等。

探索性能杀手Filter

1

性能杀手Filter造成机制

• 为何会造成Filter操做？（多子节点，单子节点纯粹过滤操做）

Filter造成于查询转换期间，若是对于子查询没法进行unnest转换来消除子查询，则会走Filter。走Filter说明子查询是受外表结果驱动，相似循环操做！很显然，若是驱动的次数越多，效率越低！

查询转换是可以生成高效SQL执行计划的重要步骤，查询转换不能作好，后面的不少执行路径就无法走了。掌握查询转换机制，对如何写高效的SQL，调优SQL相当重要，了解的越深，对CBO就越了解。

下面是CBO组件图，熟悉对应组件是SQL优化必须的内容：

• Filter何时高效？

Filter自己会构建HASH表来保存输入/输出对，以备后续减小子查询执行次数，这是与纯粹Nesed Loops操做的典型区别，好比from a where a.status In(select b.staus from b…)。 若是status前面已经查过，则后续不须要再次执行子查询，而是直接从保存的HASH表中获取结果，这样减小了子查询执行次数，从而提升效率。也就是说，若是子查询关联条件的重复值不少，Filter仍是有必定的优点，不然就是灾难！

• Filter与push_subq hints

若是走Filter则子查询是受制于子查询外结果集驱动，也就是子查询是最后执行，可是实际有时候子查询应该先执行效率更好，这时候可使用push_subq hints。

2

性能杀手Filter造成机制实例

• 简化前面的语句关键部分以下：

• Oracle内部改写以下，没法unnest,若是unnest：

执行计划以下：

从执行计划里能够看到，Filter多子节点通常有以下特色：

1. 自动生成的绑定变量：B1，由于须要执行循环操做

2. 转为EXISTS

因此，之后看到有自动生成的绑定变量的执行计划，都是相似Filter的操做，好比标量子查询，UPDATE关联子查询，优化的话，都须要干掉（类）Filter来优化。

这里的例子实际上是一个CBO的限制：

• 含有OR的子查询，常常性没法unnest，Oracle大多没法给转换成UNION/UNION ALL形式的查询

• 因此，针对这样的语句优化：

  1）改写为UNION/UNION ALL形式

  2）根据语义、业务含义完全重写

也就是说，须要重构查询，消除Filter！慢的根源以下，这里7万多行，只执行了116行打印的执行计划！ID=3~6的执行次数依赖于ID=2的结果行数，ID=3~6全表扫描次数太多。

逻辑重写让SQL起飞

1

逻辑改写-构造高效HASH JOIN代替低效Filter

• 回到原来的SQL中，看如何改写，经过分析，能够改成JOIN形式：

• 改写后执行时间从2小时到8分钟，返回360w行+。虽然执行计划更复杂了，可是充分利用了HASH JOIN、MERGE JOIN这种大数据量处理算法代替原来的Filter，更高效。若是不走OR扩展走什么？（走Nested Loops，对IMS_NUM_INFO扫描从4次到1次，也很慢）。

• OR扩展存在缺点，大表仍是屡次被访问，还能继续优化吗？

2

完全重写-消除OR扩展的HASH JOIN重写思路

• 上一次重写，等于使用了第一种方法，用UNION/UNION ALL消除Filter，那么如何消除UNION/UNION ALL呢，也就是要将OR语句合并为AND！

追本溯源，从SQL含义出发，上面含义是ERR表的TMISID截取前8,9,10,11位与TMI_NO_INFOS.BILLID_HEAD匹配，对应匹配BILLID_HEAD长度正好为8,9,10,11。很显然，语义上能够这样改写：

ERR表与TMI_NO_INFOS表关联，ERR.TMISID前8位与ITMI_NO_INFOS.BILLID_HEAD长度在8-11之间的前8位彻底匹配，在此前提下，TMISID like BILLID_HEAD||’%’。

如今就动手完全改变多个OR子查询，让SQL更加精简，效率更高。

3

完全重写-消除OR扩展的HASH JOIN让SQL起飞

经过上一节的思路，改写SQL以下：

执行计划以下：

• 如今的执行计划终于变的更短，更易读，经过逻辑改写走了HASH JOIN，那速度，杠杠的，最终一条返回300多万行数据的SQL原先须要12小时运行的SQL，如今3分钟就执行完了。

• 思考：结构良好，语义清晰的SQL编写，有助于优化器选择更合理的执行计划，看来编写SQL真的有不少值得注意的地方。

两个工具提高疑难SQL优化效率

1

两个工具提高疑难SQL优化效率-10053分析执行计划生成缘由

• 一条SQL执行12分钟没有结果：其中object_id有索引，从查询结构来看，内层查询彻底能够独立执行（最多100行），而后与外层的表进行关联，走NL，这样能够利用到object_id索引，然而，事与愿违，ID=4出现Filter，这样内层查询会驱动N次，问题出在何处？

下面就使用10053探索优化器行为来研究此问题。

*****************************

Cost-Based Subquery Unnesting

*****************************

SU: Unnesting query blocks in query block SEL$1 (#1) that are valid to unnest.

Subquery removal for query block SEL$3 (#3)

RSW: Not valid for subquery removal SEL$3 (#3)

Subquery unchanged.

Subquery Unnesting on query block SEL$2 (#2)SU: Performing unnesting that does not require costing.

SU: Considering subquery unnest on query block SEL$2 (#2).

SU: Checking validity of unnesting subquery SEL$3 (#3)

SU: SU bypassed: Subquery in a view with rowid reference.

SU: Validity checks failed.

• 从10053中能够看出，查询转换失败，由于遇到了rowid,固然把Rowid改别名是能够，可是此SQL要求必须用Rowid名字。

• 经过改写消除Filter运算以下：

2

两个工具提高SQL优化效率-SQLT找出正确执行计划需设置的参数

• SQL可否生成正确执行计划，不光和统计信息、索引等有关，可否正确执行查询转换是相当重要的，因为各类复杂的查询转换机制致使Bug不少，Oracle对这些已知Bug经过fix control参数管理，有的默认打开，有的默认关闭。因此，若是遇到复杂的SQL，特别包含复杂视图的SQL，好比谓词没法推入这种查询转换，收集统计信息无效，这时候能够考虑是否遇到了Bug。

• Bug那么多，我怎么知道是哪一个？SQLT神器来帮你！使用SQLT里面的XPLORE工具，能够把参数打开关闭一遍，而且生成对应执行计划，这样经过生成的报告，能够一眼定位问题。（固然，是已知Bug，好比前面的Rowid问题，也是定位不到的）

• 问题背景：11.2.0.2升级到11.2.0.4出现此问题，性能杀手Filter操做，SQL跑不出来，Filter产生缘由，没法unnest subquery，其中11g _optimizer_null_aware_antijoin参数为true。

执行计划以下所示：

很显然，这两个Filter有问题，按理说应该走ANTI JOIN。

下面看看使用SQLT的XPLORE来找出问题，先来看下SQLT介绍：

跑一下XPLORE，只须要调用XPLAIN方法便可，提升效率，不实际执行SQL：

能够看到和对应的隐含参数_optimizer_squ_bottomup设置有关，这是一个和子查询的查询转换有关的隐含参数。

修正以后的执行计划：

走回ANTI JOIN，正确了。终于从跑不出来到几秒搞定，其实还能够优化，可是那已经不是最重要的事了！

SQLT XPLORE的一些限制：

• 只能单个参数测试是否有效；

• 作XPLORE使用XPLAIN方法，内部调用explain plan for,不须要执行从而提升效率和避免修改数据；

• 只有是已知参数或者Bug fix control才会有用，对于未知Bug无用，固然修改参数须要作足测试，若是非批量问题，建议找出缘由，使用SQL PROFILE搞定，批量问题须要作足测试再实施修改！

SQL Tuning思考之RoadMap

• 获取问题SQL制定优化目标

从AWR、ASH、SQL CHECK S等主动发现有问题的SQL、用户报告有性能问题时DBA介入等，经过对SQL的执行状况分析，制定SQL的优化目标。

• 检查执行计划

explain工具、sql*plus autotrace、dbms_xplan、1004六、1005三、awrsqrpt.sql等。

• 检查统计信息

Oracle使用DBMS_STATS包对统计信息进行管理，涉及系通通计信息、表、列、索引、分区等对象的统计信息，统计信息是SQL可以走正确执行计划的保证。

• 检查高效访问结构

重要的访问结构，诸如索引、分区等可以快速提升SQL执行效率。表存储的数据自己，如碎片过多、数据倾斜严重、数据存储离散度大，也会影响效率。

• 检查影响优化器的参数

optimizer_mode、optimizer_index_cost_adj、optimizer_dynamic sampling、_optimizer_mjc_enabled、_optimizer_cost_based_transformation、hash_join_enable等对SQL执行计划影响较大。

• 优化器新特性、Bug

如11g的ACS、cardinality feedback、automatic serial direct path、extended statistics、SQL query result cache等。有的新特性会致使问题，需谨慎使用。

• SQL语句编写问题

SQL语句结构复杂、使用了不合理的语法，好比UNION代替UNION ALL可能致使性能低下。

• 优化器限制

没法收集准确的统计信息、没法正确进行查询转换操做等，如SEMI JOIN、ANTI JOIN与or连用会走Filter操做。

• 其余

主要涉及设计问题，如应用在业务高峰期运行，实际上能够放到较空闲状态运行。表、索引、分区等设计不合理。

SQL Tuning最佳实践：

SQL性能管理平台

应用系统SQL众多，若是老是做为救火队员角色解决线上问题，显然不能知足当今IT系统高速发展的需求，基于数据库的系统，主要性能问题在于SQL语句，若是能在开发测试阶段就对SQL语句进行审核，找出待优化SQL，并给予智能化提示，快速辅助优化，则能够避免众多线上问题。另外，还能够对线上SQL语句进行持续监控，及时发现性能存在问题的语句，从而达到SQL的全生命周期管理目的。

针对以上种种，咱们新炬网络以多年运维和优化经验自主研发出了一款SQL审核工具，经过SQL采集—SQL分析—SQL优化—上线跟踪这四步SQL审核法则， 极大地提高了SQL审核优化和性能监控处理效率。有别于传统的SQL优化方法，它是着眼于系统上线前的SQL分析和优化，重点解决SQL问题于系统上线以前，将性能问题扼杀于襁褓之中。

首页审核整体状况尽收眼底：

审核页面展示详细SQL审核状况：

SQL审核结果多维护分析：

优化建议详细准确：

内置上百种规则集，可按需选择：

SQL性能管理平台必须解决事前事中过后的SQL全生命周期管理问题。

• 事前：上线前SQL性能审核，扼杀性能问题于襁褓之中。

• 事中：SQL性能监控处理，及时发现上线后SQL性能发生的变化，在SQL性能变化而且没有引发严重问题时，及时解决。

• 过后：核心SQL监控，及时告警处理。

SQL性能管理平台实现了SQL性能的360度全生命周期管控，而且经过各类智能化提示和处理，将绝大多数原本因SQL引起的性能问题，解决在问题发生以前，提升系统稳定度。

另外对SQL性能的分析，从SQL写法、SQL执行信息、执行计划、统计信息等多方面定义规则，多维度进行分析，提供智能化的建议，提高优化速度和准确性。

SQL性能管理平台特色-自动化采集、分析、跟踪，减小DBA分析时间，提升管控效率：

SQL审核是新炬网络数据库性能管理平台DPM的一个模块，你们若想了解更多关于DPM的信息，可加邹德裕大师微信carydy交流探讨。

Q&A

Q1：merge join、nested loops、hash join何时走什么样的链接呢？

A1：Nested loops适合各类关联条件的查询，=,<>,>,<等等，主要是驱动行数少，被驱动的若是有高效索引，返回结果集不大的状况下高效，侧重于CPU消耗。

HASH JOIN是必需要等值链接的，侧重于大数据量运算，本次分享的巨慢SQL就是经过将OR子查询经过SUBSTR函数构造等值链接，实现HASH JOIN运算，侧重于内存消耗。

SORT MERGE JOIN主要适合<,>之类的大数据量运算，须要排序，侧重于内存消耗。

Q2：收集统计信息用analyze仍是dbms_stats？

A2：很显然收集统计信息要用DBMS_STATS，ANALYZE有些功能DBMS_STATS没有，好比validate structure等。

Q3：SQL第一次快，以后执行慢大概什么缘由？

A3：这种问题须要具体分析了，若是是11g，大可能是执行计划频繁变化致使的，11g有cardinality feedback和adaptive cursor sharing,BUG较多，常常会致使SQL忽快忽慢，能够经过执行计划来进行分析，若是是这样的缘由，能够关闭此特性。若是不是新特性致使的，能够经过分析物理读，逻辑读，或者10046跟踪来找出缘由加以解决。

下载连接

一、分享PPT下载：

点击文末【阅读原文】或登陆云盘：http://pan.baidu.com/s/1kVSLFlt，便可下载本次分享PPT。

二、直播连接：

https://m.qlchat.com/topic/220000485078915.htm?preview=Y&intoPreview=Y

密码：006

好书相送

在本文微信订阅号（dbaplus）评论区留下足以引发共鸣的真知灼见，并在本文发布后的隔天中午12点成为点赞数最多的1名，可得到绝版译著《Oracle核心技术》一本~

精选专题（官网：dbaplus.cn）

◆ 近期活动 ◆

DAMS中国数据资产管理峰会上海站

峰会官网：www.dams.org.cn返回搜狐，查看更多

声明：该文观点仅表明做者本人，搜狐号系信息发布平台，搜狐仅提供信息存储空间服务。