Oracle 的DevOps最佳实践：辅助开发SQL审核

前面我们提到，最终那3%的性能问题会成为工作的核心，跟性能相关的问题正是最经常影响到用户业务连续性、可用性的问题，是对于用户影响最大的问题，也是不容易通过标准化去解决的问题。

在我十多年的职业生涯中，经过我们的分析，我们认为DevOps在Oracle数据库的最佳实践应该是SQL审核。

为什么这样讲？我们知道，其实超过80%的性能问题会是SQL问题导致的，你的一个SQL编写不良、存在性能问题，跑到线上去，在高并发的情况下可能瞬间就会引起雪崩。

在这一周内，我们还在帮一个用户解决问题，在一个运营商的一个系统里，一类非常简单的SQL会占据系统大约70%-80%的资源，这一类问题是很难通过标准化、自动化的手段去解决的，需要DBA在这个方向上去做努力。

在今天Oracle的数据库产品这么成熟的情况下，在SQL、在性能上为什么还存在这么多重要的问题？

通过调研我们发现几乎所有的企业中，开发通常是一个群体非常庞大的队伍，运维团队可能也就三五个人，大公司几十个人，但是你面临的开发团队可能是几百、上千人。

这个庞大的群体变化是非常频繁的，经常的有人员流动，很多新人进来以后会循环往复地将初级问题、低级问题带到系统中来，这是我们在很多用户那里看到的现状。

如何去解决这样的问题，是我们一直在思考的，我们今天把它定义为SQL审核。

SQL审核在我们的视野里也是一个O2O的问题，就是从线上到线下，线上运行的SQL效率和我在开发中的效率。

我如何优化、控制、审计这些SQL，去改善它的性能？这是我们全部要解决的，线上要保证稳定性，线下防范新的问题出现。

对于这些问题，我们的经验是，你不能依赖于开发去解决。所以，我们DevOps的实践中，如果你要推回到开发层去解决这些SQL问题，这个墙又树立起来了，你要帮他去解决。

优化线上、发现问题、审核开发、解决问题；同时给开发进行培训，甚至是说你跟他在一起，帮助他去写这些复杂的SQL。如果经过这样的循环，会达到非常良好的效果。

案例一：从Dev细微处提炼Ops规则

为什么在今天，在Oracle数据库有四十年的历史、SQL功能、SQL标准那么成熟的情况下，还会有那么多的问题出现？

我们通过几个案例来分析一下。如果图示这样一个非常简单的SQL，但是我们发现这里面居然会存在几个问题。

如果去审核执行计划的话，大家可以发现这里面出现了一个隐式转换。

隐式转换在Oracle数据库中可能意味着你传入的参数类型是不对的。

检查这些字段会发现原本定义字符类型现在传入了一个Number，Oracle会进行隐式转换；转换的后果是：即便在查询字段上存在索引，这个索引也不会被用到。这种基础性问题是直到今天也仍然非常普遍的存在。

那么，如何去解决这个问题？如果你给一个正确的传入参数类型，这个SQL可能会走一个正确的执行计划。

但是非常不幸的是，比较谓词上还有另外一个函数是trim，我最早做程序员的时候也经常愿意用这个函数，Oracle还有两个类似函数，可以把左面的空格去掉或者把右面的空格去掉，Trim是把两边的空格都去掉。

对于程序员来说他发现空格的话，首先想的怎么去掉达成一个正确的输出。但是从全局来看，这种做法是不对的。

我们认为，你应该分析这个数据为什么会产生额外的空格？如果能够通过额外的数据清洗、校验把这些冗余的数据去掉，最终的SQL可以是非常精简的，也就会更高效，没有任何意外出现。

所以，从我们遇到的成千上万的案例来看，很多性能问题，你最终回来追溯的话，它的原理可能是非常简单的。

如果把我们的经验落到DevOps领域，我们认为：从细微的地方要去提炼能够被重复执行的规则，把这些规则应用到流程中去，从源头防范类似问题的再次出现。所以，这里如果我们要总结规则的话：

规则1

在开发SQL的时候，要确保传入参数类型一致，避免不必要的隐式转换。所以，Dev和Ops都要非常明确隐式转换可能会带来性能问题。

规则2

要确保数据的标准化和进行必要的清洗，避免在SQL中引入进一步的函数处理，这个函数处理同时会降低性能，多消耗CPU周期。

这是非常简单的一个例子，但是我们的想法是要从这些案例里提炼规则，大道至简。

案例二：Dev编写不规范引发Ops故障

这个案例也是我们在非常重要的运营商环境中遇到的

我们去审核SQL效率的时候，如果去看它的执行计划，这里面有两条标准的低效的执行方式：

·         第一是笛卡尔积，如果一个SQL用了笛卡尔积，它的性能可能会出现问题；

·         第二是全表扫描，如果这个表的数据量很大，效率会很低。

可是为什么会出现这样的问题？在这样的一个查询里，程序员为两个表使用了同样的表别名，我们认为这是开发规范中应该明确禁止的一个动作。

同样的别名在做关联的时候Oracle可能会产生歧义，在这个SQL中，内部子查询的关联条件对接到外部的对象上去，从而在这儿就出现了笛卡尔积。

所以，在这里再总结出一条规则：

规则3

一定要避免在同一个SQL查询中出现同样的别名。除了可能的性能原因，即便是对你理解这段SQL代码，也是不利的，而且它可能还会产生歧义。

如何制定规范和落地规范，也是在一个开发流程中需要管控的。

案例三：从Dev SQL逆向推理应用架构

我们在做很多数据库优化的过程中，可以从一条SQL逆向推出这个应用的一些设计上的问题，更进一步地知道，如果我们能够在设计阶段就参与到一个项目的数据规划、数据架构设计中去，可能是最有益和效率最高的。

这个案例导致了一家运营商客户某个系统中断了服务，这是一个真实的案例。

首先看到这个系统出现问题的时候，它有非常高的latch竞争，消耗了非常多的资源，导致系统阻塞、挂起。

在具体的SQL列表中可以看到，一条SQL消耗了97%的逻辑读，这个问题一目了然，大家一看就知道是一条SQL导致的。

我们看一看到底是什么样的SQL有这么大的威力？

你会看到它有多么的简单，就是一个单表查询，然后加了几个限定条件，但是这个SQL有几个独特的地方。

我常说SQL是比较专业的一个技能，虽然它非常标准化和通用，但是结合数据库处理，它也变得很专业。

大家看到这个SQL中用了一些特殊的写法，比如说for  update来锁定数据，有rownum限定返回值数量，还有一些其他的限定条件。

从执行计划看，这是一个分区表。从这些基本的要素中就可以看到这些内容：基于分区表的限定返回一行记录的查询，然后加锁。

可是它出问题了，这个问题出在什么地方呢？

其实我们有很多可以怀疑的地方，你可以看到，它这里有for update，有一个local索引，有rownum，有 stopkey，问题在什么地方？

客户怀疑是不是rownum传入值发生变化导致出现性能问题？是不是产生了扩大锁？等等。但是分析之后这些问题被排除了。

对于这个SQL，我做了一些标注，标成红色了，可以看到这里面有一些非常奇特的写法，这是我们那一代程序员里经常会写的一种写法，现在一般年轻的程序员不会这么写。

你会看到，他在这里对时间上加了一个0，对这两个字段上并了NULL进去，这是很奇怪的写法，因为你对一个时间加了一个0，实际上不改变结果，并了空值结果仍然不变，但是这两者等同于做了一次运算。

做了一次运算的结果是，如果这些字段的初始值上有索引的话，这个索引就不会用了，因为它已经变成了一个新的输出字段，这也是隐式转换。

为什么会加这个条件呢？这是我们那一代程序员经常做的事，比如说这些字段上有索引，但是可能效率不好，就通过这样的方式把它规避掉，让它精确地走一个我明确定义倾向的索引，是这样的一种逻辑。

可是就是这样精确控制的逻辑，现在把系统搞挂了。

我们当时分析这个问题，排除了这些之外，注意到关键因素是在这儿。其实对于所有数据库都一样，当数据量足够大以后就是分表、分区、分库，Oracle的专利技术就是分区，将一个表拆成多个单元。

但是这是一个散列分区，如果这个查询中没有用到分区键值的话会怎么样？

你看到执行计划里面访问的是第一到第八个分区，它可能会访问所有分区，这就意味着SQL没有用到分区键值以及分区剪裁，如果没有用到分区键值，rownum是小于等于1的，返回一条记录，Oracle实际上做的就是找到一条满足条件的记录就返回，这就是Stopkey。

大家看明白了，这样的一个SQL简单也可以说是简单，但是它暗含了这么多因素、知识。

用户曾经分析这条SQL的时候很困惑，SQL的执行计划跟之前没有任何变化，它所消耗的资源基本上相当，但就是在某一天突然之间这个系统就停转了。

当我把刚才的问题拆解出来的时候，我们就有了这样一个猜测：它的效率如何，取决于什么时候能够找到这条记录。

我们把这个SQL拆解开，Oracle可以按照这样的方式拆解：

1.    我先看看在什么地方可以找到满足条件的记录，实际上这是发一张卡，要找到一张卡。

2.    在1、2、3、4分区中没有找到满足特定状态的记录，一直访问到第5个分区的时候，才能找到一条满足条件的记录。

这意味着这个系统的性能是逐渐衰减的，也就是说，在程序员最早写出这条SQL的时候，这个SQL是非常快的，它在第1个分区中就能够找到记录。

可是当数据逐渐向后推移发生变化之后，它的性能会越来越慢，最终达到一个瓶颈点之后，这个系统就彻底挂掉了，而就是一条SQL产生这样的影响。

我后来总结了一下，这是基于应用逻辑、数据结构实现的一个逻辑炸弹。它一定会出现问题，只是不知道哪一天会出现问题。

所以，我们可以从一条SQL反过来去推它的数据架构是不是合理的，如果数据架构设计时有定期的归档机制就可以避免这样的问题。

但是就怕没有归档等机制，数据就是顺序地向后使用，性能会越来越慢，直到有一天崩溃，这就是DBA运维接到的一个炸弹。

我们做运维，做DBA，就是尽快把问题消除掉，临时的解决方案就是要把这个程序员聪明地规避掉的这些字段全部拿回来，让它们参与到索引的计算中，快速地找到这条满足条件的记录。

因为现有的索引已经不能够快速地筛选记录了，我们要做的只能是通过索引的方式，把这些条件根据选择性构建了一个复合索引，这时候性能改变了。

可以看到，从原来单次执行的效率是5秒到了240个毫秒，基本上满足业务需要；从单次的IO  24000多到3000多，把这个问题就消除掉了。

我做了一个总结，这是我在给用户的一个咨询项目上写的一句话，在设计一个系统的时候要有这样一个准则：我们要尽量设计一个『线性可扩展的、性能弱衰减』的系统。

当然，这个也是弱衰减，它已经弱了两年多，最后衰减到不可用了。我们设计系统时就要考虑，如果当我的容量扩大的时候或者需要扩展的时候：

第一、如何保证系统是可以弹性扩展的；

第二、在设计之初要考虑到性能，如何保证系统性能不衰减（是最理想的，但是不太可能），或者衰减的话，保证它是弱衰减的，并且我们要建立一定的预警机制，在达到一定条件的时候要提醒我进行重构或者数据整理。

所以，我们可以根据经验去设定一些预警指标，从这个案例中我们总结：

规则4

考察单行记录的返回效率，如果返回一行记录，那么去找到这条记录，它到底应该消耗多少IO？

你自己可以根据你的典型业务去做评判，比如，我认为单行记录返回不能多于5000个IO，如果超过这样的值，就要把这些SQL拿出来进行预警，进行分析。

尤其是这个SQL查询，返回一条记录消耗了25000个IO。所以，这也可以形成我们的一个审核规则，当然也可以作为性能规则。

案例四：Dev&Ops理解数据，理解索引

这是一个跟开发、运维都有关系的案例，有时候觉得很不容易，简单的事情里面蕴含着很多复杂的道理。

这条SQL非常简单，仍然是单表的，今天我举的几个例子基本上都是单表的查询，我相信大家都能够很好地理解它。

这个SQL很简单，我从这个表里面 SELECT 查询，有几个限定条件。

很遗憾的是，十年前我们在跟全表扫描做斗争，可是十年之后我们还是在和全表扫描做斗争，当这个SQL出现性能问题的时候走了全表扫描，几乎把所有的系统资源消耗尽了。

我们去看这个SQL，条件非常简单，里面两个关键的条件：第一个是时间 DEALDATE，它查询 DEALDATE 在5分钟之内的数据，继续向下看，当你看到一个OR的时候可能会心凉了半截，一个OR的NULL值判断会把查询展开。

上一个案例我们讲到，如果在前期规划里面有数据归档的规则、有其他的设计，可以避免问题。

在这个问题中，如果在数据结构设计的时候给DEALDATE一个非空值（Default值），这里就不会存在OR的条件，一个程序员写OR非常容易，但是到了数据库端可能是一个灾难。

第二个条件是对于UIN_ID的MOD运算，结果BETWEEN 6和7之间。就是这两个条件惹的祸。

可以看到，在这个对象上的索引，首先在日期上有索引，但是因为日期是可以存在空值的，Oracle不能索引全null值的这些列，所以这个索引没有用，它不包含null值，所以它被pass掉了。

你会看到第二个索引是基于UNI_ID和DEALDATE的复合索引，但是这个UNI_ID也允许为空值，这两个加起来，如果碰到空对空，这个索引仍然是无效，所以这个索引仍然不被用到。原本为了这个查询所创建的两个索引在这里全部失效了。

如何去正确理解Oracle的空值，以及空值在索引和查询中发挥的作用，我觉得这应该在开发团队中深刻地普及和培训，让大家认识到它可能存在的影响。

所以，我这里列了又一个规则

规则5

在数据结构设计的时候，应该尽量避免一些比如日期类的空值，可以给它一个default值，不输入的时候，它仍然给一个当前的时间。

这样，你可能就会避免掉让我们觉得很痛苦的一些写法。

解决方案，我们如何去把它改好，用尽量最小的调整去改变这个SQL？

我们用尽量最小的调整去改变这个SQL，所以我们在这里加了一个条件：UNI_ID  is  not null ，为什么我加这样一个限定呢？

因为我要求的返回值是在6和7之间，6和7之间没有NULL值，用户也不期望找到NULL，我们人为地加了一个限定做到等效改写，加了限定之后这两个字段的复合索引就可以用到了，这个复合索引用到之后，这个查询的效率就提升了，CPU负载 100% 的问题就消除了。

可以看到，在高并发的情况下，一个细微SQL的性能波动都可能会导致一个业务系统的灾难，SQL的影响就是这么厉害。

我们这样的一个用户系统里有大于6000个并发在上面跑业务，非常繁忙。

小结

我们认为，在Oracle数据库领域，在将来变革的环境之下，可能绝大部分传统DBA所做的底层跟系统级相关的事情在未来会被替代，但是我认为最有价值的部分就是那3%跟性能相关的千奇百怪的各种问题。

那么，这些问题如何去解决呢？

我们认为，通过SQL审核，通过SQL的规范化，可以认为是DevOps或者说我看到的在数据库领域最佳的一个落地。那么，如何去实践它呢？

其实我刚才讲的几个案例就隐含了我的思路，如果我们能够从案例总结出规则，从规则中总结出规范。

你有一个开发规范，就可以帮助一个开发团队，共同构建高质量的SQL代码。

当然，终极目标，DevOps的精髓也就是，要通过自动化的工具降低人的劳动，最终能够从规范进化到工具，可能会更好地解放人，从而也让大家把注意力集中在那些有价值的工作上。

我认为今天在数据库领域DBA的发展路径会有一些变化，从传统运维的DBA到产品DBA再到今天，真的有一个角色叫开发DBA，也就是DevOps在运维侧能做开发的人。

这些人可能要做什么呢？通过开发自动化的工具去解决数据库运维中的一些重要问题，提升系统的稳定性。

甚至是说，如果我们用开源产品的时候，这些人可能还要负责修改数据库的底层代码去解决问题。我认为，这类角色在未来会变得更加重要。

大家可以看到，我们在这方面做了很多思考，可以把我们很多经验和成果跟大家分享。

DevOps-以自动化工具提升运维效率

这是一个SQL审核工具，把发现的问题总结成规则，规则再到规范，最后把它变成算法放到软件中去，软件通过持续地数据采样，监控后端运行的数据库，把这些数据全部采集出来，从SQL视角形成归档和SQL生命周期管理。

如果SQL在生命周期中发生性能的急剧衰减或者波动，可以一目了然地看到什么时间出现什么问题。

Z3 工具的实现原理非常简单，我们大家跟数据库、跟SQL斗了那么多年，其实我们就是解决这样的问题。比如说

·         我的SQL里是不是有笛卡尔积

·         是不是全表扫

·         是不是外键上没有索引、存在索引跳扫

·         未绑定变量、隐式转换

·         …….

绝大多数情况下我们遇到的都是这些问题。那么，我就把这些问题全部变成一个一个的算法，通过这个算法去筛选SQL，把我们DBA以前最棘手的、绝大部分通过人肉来做的事情，全部通过一个工具来做出来，筛选出来再提供建议解决方案。

当然，我们还做了一个非常有意思的事情，我们做了一个积分，运维怎么跟开发斗呢？

你说开发的程序质量问题多，经常给我埋雷，我现在就把这些规则做一个积分，我来持续筛选一个SQL，通过加权来告诉你当前SQL积分现变成什么样子，你的积分如果一直下降，说明你的开发质量是有问题的，而且在往下走；

如果你是不断地提升改善，SQL积分往上走，大家可以形成一个良好的互动。

这是非常简单的一些思想，把这些我们最常做的事情固化成一个算法，这个工具已经开放了接口，你想增加规则，写一个代码扔进去，就能把SQL筛出来。

从开发到治理：纵深的数据服务理念

我们认为，未来的数据服务或者在数据层做的事情，无论是从开发端还是到运维端，会是一个纵深的服务体系，其实也是DevOps的精髓，大家要学会从全局的观点去看。

然后，我们希望能够关注在一些细节上，把一些关键点的问题解决掉，如果你的注意力过于分散，你还不一定能做好一件事情。

所以，从开发端来看，一个软件的开发的流程包括需求分析、数据建模、SQL开发、算法设计，再到数据挖掘、展现，其实每个环节大家做出一些提炼和最佳实践，解决其中的核心问题，都能够为企业带来帮助。

我刚才提的SQL审核、SQL开发就是我们在做的事情，在一些我们客户的开发环境里，我们甚至有团队去帮它写代码，复杂的SQL我帮你写好，你几百行、上千行的，我用最高的效率帮你实现。

如果向纵深、向底层做，无论是从性能优化还是数据治理、数据规范化上，其实都能够做很多很精细化的事情，解决用户实实在在的问题。所以，从云端到现实，这就是我们要做的事。

Q&A
1. 提问：盖老师，您好，我是做互联网的，我是07年到08年才用Oracle，我自己本身也不做数据库，但是我的团队下面DBA是属于我这边。我的第一个问题：SQL审核，专家能力的规范聚焦形成产品，Oracle官方为什么不做？这是一个很神奇的问题。第二个问题：我们自己本身有MySQL的云数据库，我们有1500个实例，我们只有一个DBA，我们的平台现在没有做得像盖老师这样很细化地对每一个SQL审核，但是我们做了一个比较简单的，对SQL的CPU使用率、慢查询等东西做一个打分，也能够做到一定程度上可以分析这个产品的问题。我想要的是什么结果呢？就是能够快速地定位到一个慢SQL，在SQL执行、审查阶段就把你咔碴掉，第二个阶段是做了这个慢SQL，抓到这个慢SQL，生成一条优化好的SQL，告诉你帮你执行了。不知道我后面这个想法能不能在MySQL领域去实现，或者有什么样的技术能够支撑这个想法？谢谢。

盖国强：两个很好的问题，
第一个问题，这样的事情一定是对很多人有帮助的，为什么Oracle没有做。其实你会注意到Oracle关于服务层的事情很少做，Oracle是集中全力把它的数据库产品的内核做好。

其实Oracle对服务根本不关心，这部分对它来说利润率太低了，服务这块都是由第三方的生态来做的，这就导致服务相关的东西对Oracle来说不是迫切的事。我认为，这可能是原因之一。

第二个问题，我也知道在MySQL上其实很多团队也在做SQL审核的事情，也做了一些产品，像腾讯、去哪儿网等都在做，MySQL上为什么能够实现通过简单的审核筛查出来？

一方面可能是因为它的SQL简单，简单就是美，简单的架构是美，简单的编写方式是美，MySQL的SQL功能还是比较弱的，这就使得SQL问题比较容易筛查和筛选的。

而像Oracle，我刚才所举的都是最简单的例子，10表联合、20表联合、SQL上到几千行的时候，你会发现已经完全超越了MySQL的那种简单逻辑。

正是因为复杂性，才会导致了在这块做这件事会复杂很多，而MySQL或者开源的产品可能会容易一点。

但是大家在讲Hadoop等大数据的产品，都在不断地加强SQL的支持能力，如果不支持事务，很多人觉得不爽，如果不支持标准的SQL，大家觉得不爽，所以大家都在朝这个方向努力。

所以，将来如果MySQL的SQL支持越来越复杂的时候，同样你会遇到和Oracle类似的问题，不同产品现在所处的阶段不一样，我认为开源产品还是在一个野蛮生长的状态，大家在疯狂创造的时代，再向后发展，如果在谋求商业化等等的过程中，我觉得会看到走类似的过程。这是我的一点看法。

2. 提问：你刚开始说2014年、2015年Oracle都是在做云端的工作，现在它有哪些成果？比如说，PPT中也说到Oracle有一个很大的问题在安装上，它的一些兼容，和操作系统的配置等，比如说，在云端可以和Docker结合，一个容器可以执行的东西等。

盖国强：你想了解的是说，Oracle做了那么多年，在云上到底有什么东西？我可以告诉大家全都有了。

比如说Oracle云端数据库，如果你不想在企业内部安装一个数据库，你在Oracle云上买一个它的云数据库就可以用，它全是自助式的，点点按钮就可以了，全部已经准备好了，而且它在Docker上也做了很多东西，OpenStack，全都做了。

但是问题是，它的价格比较贵，Oracle即便是提供云上的服务，它的价格仍然是很贵的，如果你去计算一下，觉得可能不一定能够用得起、不一定要用它。

另外一方面，我在北美真正感受到一点，企业和互联网是有很大差异的，企业级用户的变革非常稳健，虽然他们也想拥抱云，也想到云上去，但是它的变革会稳步进行，这无形中实际上是给了Oracle时间。

如果都像是互联网的速度，你不给我，我就自己做，那对于Oracle的压力可能就大了。当企业级用户真的要进行云上迁移，大步伐变革的时候，可能Oracle的云就已经成熟了。所以说，这是对Oracle最大的机会。

3. 提问：你提到现在在做SQL的审核工具，也会给一些优化的建议。我们有没有一种方式，比如代替用户做一个模拟或者代替开发团队做一个模拟，告诉他你用我的方式做完以后可以有多大程度提升，此外对你的业务没有影响？很多时候我们做一个SQL优化，必须要考虑我不可能做一个很大的变化或者改很多逻辑去对业务产生影响，保证业务的可用性应该是一个最基本的原则，有的时候不可用马上就可以恢复，长期的可以慢慢再看。这方面有没有尝试如何去让用户或者产品团队立马感受到这个效果？或者在一个模拟环境。

盖国强：为什么我把我这个主题也定义成DevOps，其实是什么呢？我们所做的SQL审核的事情，我们一直想把它放在开发端，因为你等到一个应用上线出现问题，这已经是运维的人背锅、踩雷了。

上线以后出现问题，用户的业务已经遭受到损失了。我们要做的问题是在事前就消灭在无形当中，所以我们希望在开发、测试环节多投入，所以我叫DevOps，运维做的产品，让开发在开发阶段过程中把问题找出来、优化掉。

你刚才讲到如何让用户体验到这种价值，我们现在一些用户那里就是在跟华为合作，我刚才的流程图是真实的，如果最早把问题找出来，你说我找到一百个问题给开发，开发才不理呢，给你扔出来，“你怎么说有问题？没有问题！”。

我们在跟开发商配合的过程中，最开始大家是矛盾冲突很激烈的，但是当一个阶段之后，大家发现彼此的价值之后，一切就改变了。

我们的客户是运营商，工作确实很繁重，而且它的系统非常重要，核心系统一年有40次大的变更、1000多次小的变更，几乎就是每周一次大变更。

以前客户面临的问题是变更以后系统资源明显就上去了，80%、90%、CPU跑满了，怎么办？优化，优化了一周资源消耗下来以后，第二周变更又上来，循环往复。

后来我们SQL提前审核优化以后，CPU平稳了，这是真实的用户体验，大家该放假的放假，以前变更的时候都得值夜班在机房蹲着，现在变更的时候大家可以回家了，真实地让大家感觉到生活和工作指数提升了，大家觉得这种方式确实有帮助，然后投入不大，大家都可以平稳地生活了，真实地体验到了，很愉快。

再后来，当有变更的时候，开发团队会主动地将SQL提交给我们去做审核，审核有问题的时候就来修改。尤其是我刚才提到的几条，还有一类类似的SQL，如何彻底优化？我们甚至提过专题讨论，我们所有专家来给方案，最后找到一个最佳的方案，把这个系统60%、70%的压力全部打下去，这就立竿见影。

4. 提问：我有两个问题，首先，你今天讲的Oracle的DevOps这边的实践，与其说是介绍SQL优化的工具或者上线前审计的工具来说，更多的可能是传递开发和运维一体化的一种思想。与其在事后做一些事情或者做一些优化，可能还要往前走一点，包括我们后台运维人员要配合开发人员做一些SQL模型的规范、SQL设置的一些规范，我是这么认为的。我想问的是，最近三年的时间，一些传统企业的去小机化和去Oracle，其实有一些客户在做这个动作了。请问在你的角度来看，怎么看这个趋势？目前来说，Oracle还是最重要的一个数据库。第二个问题，以你的角度，Oracle的一体机目前的市场情况覆盖率是怎样的？

盖国强：第一个问题，在去IOE的浪潮之下，Oracle的前景是什么样的。我用一句话可以概括，我个人的观点，我认为道路是曲折的、迂回的。一定是这样的，历史从来不是一面倒的，一定是曲折的，互有攻守、各有得失的一个阶段，就像看到微软，也有时能超Oracle一头。

Oracle的很多战斗力还没有发挥出来，不管是这个市场上竞争有多激烈，还没有人能够让Oracle去降价，我不认为市场上已经对它形成足够的威胁。

比如说，之前大家讲阿里在倡导去IOE，但是为什么只有阿里提倡腾讯不提倡？因为像这些早期的互联网企业，只有阿里在IOE的路线上，别人没有在这条路上。所以，这是我个人一方面的看法。

总结一下，我认为在这条路上会有变化，今天在数据库领域也是百花齐放的，有很多产品可以选，还有国产的，但是这个竞争一定是互有攻守、各有得失，不会是短期就能够看到巨大变化的一个市场，除非有一种颠覆性的理论出现，至少目前还没有一个颠覆关系型数据库的理论，像关系型数据库理论出现的时候那样，还没有到这一步。所以，我认为Oracle的路还有很长的时期要走。

第二，你说Oracle的一体机，Oracle的一体机已经被公认为这个市场上的一个非常具有创新性的产品，它已经在Gartner的分析报告中占据了独立开创的分析领域，它目前的数据在全球已经突破12000多台。

你可以看到，这种趋势引发了全球模仿的浪潮，大家都在学Oracle，像华为也在做数据库的一体机。云和恩墨也在做数据库的一体机，很便宜，跟Exadata的架构是一样的，你也可以用，开放式的去IE，把I和E全部去掉。所以，你可以看到有很多厂商都在学习Oracle，这恰恰说明它的这个方向很成功。

那么，就单从一体机的角度来说，Oracle有很多事情可以做，只不过它没有做，它仍然是在这个市场里面获得了高额的利润，如果它愿意降价的话，其实是具有压倒性优势的，我觉得国内做一体机的谁也打不过Oracle。

而且Oracle还可以有很多重要的杀手锏——它可以把它的某些产品变成国产的，比如国产的一体机，就像和腾讯的合作一样，Oracle可以和一个国内厂商合作。

今天IBM和国内厂商合作、惠普也在合作，大家都在合资合作，Oracle也会做，只不过它是受到这个压力最小的一家，还没有去更快速地推进，所以它跟腾讯的合作是第一步，明天它要说和华为合作做一个国产的一体机也有这种可能性。

所以，我认为Oracle有很多后招没有使用出来，在云时代它可能会重新崛起，因为它的资源太丰富了，它有Java，它有中间件、数据库，所有的东西它几乎都是自有的。谢谢。

（盖国强原创）

Oracle 的DevOps最佳实践：辅助开发SQL审核

前面我们提到，最终那3%的性能问题会成为工作的核心，跟性能相关的问题正是最经常影响到用户业务连续性、可用性的问题，是对于用户影响最大的问题，也是不容易通过标准化去解决的问题。

在我十多年的职业生涯中，经过我们的分析，我们认为DevOps在Oracle数据库的最佳实践应该是SQL审核。

为什么这样讲？我们知道，其实超过80%的性能问题会是SQL问题导致的，你的一个SQL编写不良、存在性能问题，跑到线上去，在高并发的情况下可能瞬间就会引起雪崩。

在这一周内，我们还在帮一个用户解决问题，在一个运营商的一个系统里，一类非常简单的SQL会占据系统大约70%-80%的资源，这一类问题是很难通过标准化、自动化的手段去解决的，需要DBA在这个方向上去做努力。

在今天Oracle的数据库产品这么成熟的情况下，在SQL、在性能上为什么还存在这么多重要的问题？

通过调研我们发现几乎所有的企业中，开发通常是一个群体非常庞大的队伍，运维团队可能也就三五个人，大公司几十个人，但是你面临的开发团队可能是几百、上千人。

这个庞大的群体变化是非常频繁的，经常的有人员流动，很多新人进来以后会循环往复地将初级问题、低级问题带到系统中来，这是我们在很多用户那里看到的现状。

如何去解决这样的问题，是我们一直在思考的，我们今天把它定义为SQL审核。

SQL审核在我们的视野里也是一个O2O的问题，就是从线上到线下，线上运行的SQL效率和我在开发中的效率。

我如何优化、控制、审计这些SQL，去改善它的性能？这是我们全部要解决的，线上要保证稳定性，线下防范新的问题出现。

对于这些问题，我们的经验是，你不能依赖于开发去解决。所以，我们DevOps的实践中，如果你要推回到开发层去解决这些SQL问题，这个墙又树立起来了，你要帮他去解决。

优化线上、发现问题、审核开发、解决问题；同时给开发进行培训，甚至是说你跟他在一起，帮助他去写这些复杂的SQL。如果经过这样的循环，会达到非常良好的效果。

案例一：从Dev细微处提炼Ops规则

为什么在今天，在Oracle数据库有四十年的历史、SQL功能、SQL标准那么成熟的情况下，还会有那么多的问题出现？

我们通过几个案例来分析一下。如果图示这样一个非常简单的SQL，但是我们发现这里面居然会存在几个问题。

如果去审核执行计划的话，大家可以发现这里面出现了一个隐式转换。

隐式转换在Oracle数据库中可能意味着你传入的参数类型是不对的。

检查这些字段会发现原本定义字符类型现在传入了一个Number，Oracle会进行隐式转换；转换的后果是：即便在查询字段上存在索引，这个索引也不会被用到。这种基础性问题是直到今天也仍然非常普遍的存在。

那么，如何去解决这个问题？如果你给一个正确的传入参数类型，这个SQL可能会走一个正确的执行计划。

但是非常不幸的是，比较谓词上还有另外一个函数是trim，我最早做程序员的时候也经常愿意用这个函数，Oracle还有两个类似函数，可以把左面的空格去掉或者把右面的空格去掉，Trim是把两边的空格都去掉。

对于程序员来说他发现空格的话，首先想的怎么去掉达成一个正确的输出。但是从全局来看，这种做法是不对的。

我们认为，你应该分析这个数据为什么会产生额外的空格？如果能够通过额外的数据清洗、校验把这些冗余的数据去掉，最终的SQL可以是非常精简的，也就会更高效，没有任何意外出现。

所以，从我们遇到的成千上万的案例来看，很多性能问题，你最终回来追溯的话，它的原理可能是非常简单的。

如果把我们的经验落到DevOps领域，我们认为：从细微的地方要去提炼能够被重复执行的规则，把这些规则应用到流程中去，从源头防范类似问题的再次出现。所以，这里如果我们要总结规则的话：

规则1

在开发SQL的时候，要确保传入参数类型一致，避免不必要的隐式转换。所以，Dev和Ops都要非常明确隐式转换可能会带来性能问题。

规则2

要确保数据的标准化和进行必要的清洗，避免在SQL中引入进一步的函数处理，这个函数处理同时会降低性能，多消耗CPU周期。

这是非常简单的一个例子，但是我们的想法是要从这些案例里提炼规则，大道至简。

案例二：Dev编写不规范引发Ops故障

这个案例也是我们在非常重要的运营商环境中遇到的

我们去审核SQL效率的时候，如果去看它的执行计划，这里面有两条标准的低效的执行方式：

·         第一是笛卡尔积，如果一个SQL用了笛卡尔积，它的性能可能会出现问题；

·         第二是全表扫描，如果这个表的数据量很大，效率会很低。

可是为什么会出现这样的问题？在这样的一个查询里，程序员为两个表使用了同样的表别名，我们认为这是开发规范中应该明确禁止的一个动作。

同样的别名在做关联的时候Oracle可能会产生歧义，在这个SQL中，内部子查询的关联条件对接到外部的对象上去，从而在这儿就出现了笛卡尔积。

所以，在这里再总结出一条规则：

规则3

一定要避免在同一个SQL查询中出现同样的别名。除了可能的性能原因，即便是对你理解这段SQL代码，也是不利的，而且它可能还会产生歧义。

如何制定规范和落地规范，也是在一个开发流程中需要管控的。

案例三：从Dev SQL逆向推理应用架构

我们在做很多数据库优化的过程中，可以从一条SQL逆向推出这个应用的一些设计上的问题，更进一步地知道，如果我们能够在设计阶段就参与到一个项目的数据规划、数据架构设计中去，可能是最有益和效率最高的。

这个案例导致了一家运营商客户某个系统中断了服务，这是一个真实的案例。

首先看到这个系统出现问题的时候，它有非常高的latch竞争，消耗了非常多的资源，导致系统阻塞、挂起。

在具体的SQL列表中可以看到，一条SQL消耗了97%的逻辑读，这个问题一目了然，大家一看就知道是一条SQL导致的。

我们看一看到底是什么样的SQL有这么大的威力？

你会看到它有多么的简单，就是一个单表查询，然后加了几个限定条件，但是这个SQL有几个独特的地方。

我常说SQL是比较专业的一个技能，虽然它非常标准化和通用，但是结合数据库处理，它也变得很专业。

大家看到这个SQL中用了一些特殊的写法，比如说for  update来锁定数据，有rownum限定返回值数量，还有一些其他的限定条件。

从执行计划看，这是一个分区表。从这些基本的要素中就可以看到这些内容：基于分区表的限定返回一行记录的查询，然后加锁。

可是它出问题了，这个问题出在什么地方呢？

其实我们有很多可以怀疑的地方，你可以看到，它这里有for update，有一个local索引，有rownum，有 stopkey，问题在什么地方？

客户怀疑是不是rownum传入值发生变化导致出现性能问题？是不是产生了扩大锁？等等。但是分析之后这些问题被排除了。

对于这个SQL，我做了一些标注，标成红色了，可以看到这里面有一些非常奇特的写法，这是我们那一代程序员里经常会写的一种写法，现在一般年轻的程序员不会这么写。

你会看到，他在这里对时间上加了一个0，对这两个字段上并了NULL进去，这是很奇怪的写法，因为你对一个时间加了一个0，实际上不改变结果，并了空值结果仍然不变，但是这两者等同于做了一次运算。

做了一次运算的结果是，如果这些字段的初始值上有索引的话，这个索引就不会用了，因为它已经变成了一个新的输出字段，这也是隐式转换。

为什么会加这个条件呢？这是我们那一代程序员经常做的事，比如说这些字段上有索引，但是可能效率不好，就通过这样的方式把它规避掉，让它精确地走一个我明确定义倾向的索引，是这样的一种逻辑。

可是就是这样精确控制的逻辑，现在把系统搞挂了。

我们当时分析这个问题，排除了这些之外，注意到关键因素是在这儿。其实对于所有数据库都一样，当数据量足够大以后就是分表、分区、分库，Oracle的专利技术就是分区，将一个表拆成多个单元。

但是这是一个散列分区，如果这个查询中没有用到分区键值的话会怎么样？

你看到执行计划里面访问的是第一到第八个分区，它可能会访问所有分区，这就意味着SQL没有用到分区键值以及分区剪裁，如果没有用到分区键值，rownum是小于等于1的，返回一条记录，Oracle实际上做的就是找到一条满足条件的记录就返回，这就是Stopkey。

大家看明白了，这样的一个SQL简单也可以说是简单，但是它暗含了这么多因素、知识。

用户曾经分析这条SQL的时候很困惑，SQL的执行计划跟之前没有任何变化，它所消耗的资源基本上相当，但就是在某一天突然之间这个系统就停转了。

当我把刚才的问题拆解出来的时候，我们就有了这样一个猜测：它的效率如何，取决于什么时候能够找到这条记录。

我们把这个SQL拆解开，Oracle可以按照这样的方式拆解：

1.    我先看看在什么地方可以找到满足条件的记录，实际上这是发一张卡，要找到一张卡。

2.    在1、2、3、4分区中没有找到满足特定状态的记录，一直访问到第5个分区的时候，才能找到一条满足条件的记录。

这意味着这个系统的性能是逐渐衰减的，也就是说，在程序员最早写出这条SQL的时候，这个SQL是非常快的，它在第1个分区中就能够找到记录。

可是当数据逐渐向后推移发生变化之后，它的性能会越来越慢，最终达到一个瓶颈点之后，这个系统就彻底挂掉了，而就是一条SQL产生这样的影响。

我后来总结了一下，这是基于应用逻辑、数据结构实现的一个逻辑炸弹。它一定会出现问题，只是不知道哪一天会出现问题。

所以，我们可以从一条SQL反过来去推它的数据架构是不是合理的，如果数据架构设计时有定期的归档机制就可以避免这样的问题。

但是就怕没有归档等机制，数据就是顺序地向后使用，性能会越来越慢，直到有一天崩溃，这就是DBA运维接到的一个炸弹。

我们做运维，做DBA，就是尽快把问题消除掉，临时的解决方案就是要把这个程序员聪明地规避掉的这些字段全部拿回来，让它们参与到索引的计算中，快速地找到这条满足条件的记录。

因为现有的索引已经不能够快速地筛选记录了，我们要做的只能是通过索引的方式，把这些条件根据选择性构建了一个复合索引，这时候性能改变了。

可以看到，从原来单次执行的效率是5秒到了240个毫秒，基本上满足业务需要；从单次的IO  24000多到3000多，把这个问题就消除掉了。

我做了一个总结，这是我在给用户的一个咨询项目上写的一句话，在设计一个系统的时候要有这样一个准则：我们要尽量设计一个『线性可扩展的、性能弱衰减』的系统。

当然，这个也是弱衰减，它已经弱了两年多，最后衰减到不可用了。我们设计系统时就要考虑，如果当我的容量扩大的时候或者需要扩展的时候：

第一、如何保证系统是可以弹性扩展的；

第二、在设计之初要考虑到性能，如何保证系统性能不衰减（是最理想的，但是不太可能），或者衰减的话，保证它是弱衰减的，并且我们要建立一定的预警机制，在达到一定条件的时候要提醒我进行重构或者数据整理。

所以，我们可以根据经验去设定一些预警指标，从这个案例中我们总结：

规则4

考察单行记录的返回效率，如果返回一行记录，那么去找到这条记录，它到底应该消耗多少IO？

你自己可以根据你的典型业务去做评判，比如，我认为单行记录返回不能多于5000个IO，如果超过这样的值，就要把这些SQL拿出来进行预警，进行分析。

尤其是这个SQL查询，返回一条记录消耗了25000个IO。所以，这也可以形成我们的一个审核规则，当然也可以作为性能规则。

案例四：Dev&Ops理解数据，理解索引

这是一个跟开发、运维都有关系的案例，有时候觉得很不容易，简单的事情里面蕴含着很多复杂的道理。

这条SQL非常简单，仍然是单表的，今天我举的几个例子基本上都是单表的查询，我相信大家都能够很好地理解它。

这个SQL很简单，我从这个表里面 SELECT 查询，有几个限定条件。

很遗憾的是，十年前我们在跟全表扫描做斗争，可是十年之后我们还是在和全表扫描做斗争，当这个SQL出现性能问题的时候走了全表扫描，几乎把所有的系统资源消耗尽了。

我们去看这个SQL，条件非常简单，里面两个关键的条件：第一个是时间 DEALDATE，它查询 DEALDATE 在5分钟之内的数据，继续向下看，当你看到一个OR的时候可能会心凉了半截，一个OR的NULL值判断会把查询展开。

上一个案例我们讲到，如果在前期规划里面有数据归档的规则、有其他的设计，可以避免问题。

在这个问题中，如果在数据结构设计的时候给DEALDATE一个非空值（Default值），这里就不会存在OR的条件，一个程序员写OR非常容易，但是到了数据库端可能是一个灾难。

第二个条件是对于UIN_ID的MOD运算，结果BETWEEN 6和7之间。就是这两个条件惹的祸。

可以看到，在这个对象上的索引，首先在日期上有索引，但是因为日期是可以存在空值的，Oracle不能索引全null值的这些列，所以这个索引没有用，它不包含null值，所以它被pass掉了。

你会看到第二个索引是基于UNI_ID和DEALDATE的复合索引，但是这个UNI_ID也允许为空值，这两个加起来，如果碰到空对空，这个索引仍然是无效，所以这个索引仍然不被用到。原本为了这个查询所创建的两个索引在这里全部失效了。

如何去正确理解Oracle的空值，以及空值在索引和查询中发挥的作用，我觉得这应该在开发团队中深刻地普及和培训，让大家认识到它可能存在的影响。

所以，我这里列了又一个规则

规则5

在数据结构设计的时候，应该尽量避免一些比如日期类的空值，可以给它一个default值，不输入的时候，它仍然给一个当前的时间。

这样，你可能就会避免掉让我们觉得很痛苦的一些写法。

解决方案，我们如何去把它改好，用尽量最小的调整去改变这个SQL？

我们用尽量最小的调整去改变这个SQL，所以我们在这里加了一个条件：UNI_ID  is  not null ，为什么我加这样一个限定呢？

因为我要求的返回值是在6和7之间，6和7之间没有NULL值，用户也不期望找到NULL，我们人为地加了一个限定做到等效改写，加了限定之后这两个字段的复合索引就可以用到了，这个复合索引用到之后，这个查询的效率就提升了，CPU负载 100% 的问题就消除了。

可以看到，在高并发的情况下，一个细微SQL的性能波动都可能会导致一个业务系统的灾难，SQL的影响就是这么厉害。

我们这样的一个用户系统里有大于6000个并发在上面跑业务，非常繁忙。

小结

我们认为，在Oracle数据库领域，在将来变革的环境之下，可能绝大部分传统DBA所做的底层跟系统级相关的事情在未来会被替代，但是我认为最有价值的部分就是那3%跟性能相关的千奇百怪的各种问题。

那么，这些问题如何去解决呢？

我们认为，通过SQL审核，通过SQL的规范化，可以认为是DevOps或者说我看到的在数据库领域最佳的一个落地。那么，如何去实践它呢？

其实我刚才讲的几个案例就隐含了我的思路，如果我们能够从案例总结出规则，从规则中总结出规范。

你有一个开发规范，就可以帮助一个开发团队，共同构建高质量的SQL代码。

当然，终极目标，DevOps的精髓也就是，要通过自动化的工具降低人的劳动，最终能够从规范进化到工具，可能会更好地解放人，从而也让大家把注意力集中在那些有价值的工作上。

我认为今天在数据库领域DBA的发展路径会有一些变化，从传统运维的DBA到产品DBA再到今天，真的有一个角色叫开发DBA，也就是DevOps在运维侧能做开发的人。

这些人可能要做什么呢？通过开发自动化的工具去解决数据库运维中的一些重要问题，提升系统的稳定性。

甚至是说，如果我们用开源产品的时候，这些人可能还要负责修改数据库的底层代码去解决问题。我认为，这类角色在未来会变得更加重要。

大家可以看到，我们在这方面做了很多思考，可以把我们很多经验和成果跟大家分享。

DevOps-以自动化工具提升运维效率

这是一个SQL审核工具，把发现的问题总结成规则，规则再到规范，最后把它变成算法放到软件中去，软件通过持续地数据采样，监控后端运行的数据库，把这些数据全部采集出来，从SQL视角形成归档和SQL生命周期管理。

如果SQL在生命周期中发生性能的急剧衰减或者波动，可以一目了然地看到什么时间出现什么问题。

Z3 工具的实现原理非常简单，我们大家跟数据库、跟SQL斗了那么多年，其实我们就是解决这样的问题。比如说

·         我的SQL里是不是有笛卡尔积

·         是不是全表扫

·         是不是外键上没有索引、存在索引跳扫

·         未绑定变量、隐式转换

·         …….

绝大多数情况下我们遇到的都是这些问题。那么，我就把这些问题全部变成一个一个的算法，通过这个算法去筛选SQL，把我们DBA以前最棘手的、绝大部分通过人肉来做的事情，全部通过一个工具来做出来，筛选出来再提供建议解决方案。

当然，我们还做了一个非常有意思的事情，我们做了一个积分，运维怎么跟开发斗呢？

你说开发的程序质量问题多，经常给我埋雷，我现在就把这些规则做一个积分，我来持续筛选一个SQL，通过加权来告诉你当前SQL积分现变成什么样子，你的积分如果一直下降，说明你的开发质量是有问题的，而且在往下走；

如果你是不断地提升改善，SQL积分往上走，大家可以形成一个良好的互动。

这是非常简单的一些思想，把这些我们最常做的事情固化成一个算法，这个工具已经开放了接口，你想增加规则，写一个代码扔进去，就能把SQL筛出来。

从开发到治理：纵深的数据服务理念

我们认为，未来的数据服务或者在数据层做的事情，无论是从开发端还是到运维端，会是一个纵深的服务体系，其实也是DevOps的精髓，大家要学会从全局的观点去看。

然后，我们希望能够关注在一些细节上，把一些关键点的问题解决掉，如果你的注意力过于分散，你还不一定能做好一件事情。

所以，从开发端来看，一个软件的开发的流程包括需求分析、数据建模、SQL开发、算法设计，再到数据挖掘、展现，其实每个环节大家做出一些提炼和最佳实践，解决其中的核心问题，都能够为企业带来帮助。

我刚才提的SQL审核、SQL开发就是我们在做的事情，在一些我们客户的开发环境里，我们甚至有团队去帮它写代码，复杂的SQL我帮你写好，你几百行、上千行的，我用最高的效率帮你实现。

如果向纵深、向底层做，无论是从性能优化还是数据治理、数据规范化上，其实都能够做很多很精细化的事情，解决用户实实在在的问题。所以，从云端到现实，这就是我们要做的事。

Q&A
1. 提问：盖老师，您好，我是做互联网的，我是07年到08年才用Oracle，我自己本身也不做数据库，但是我的团队下面DBA是属于我这边。我的第一个问题：SQL审核，专家能力的规范聚焦形成产品，Oracle官方为什么不做？这是一个很神奇的问题。第二个问题：我们自己本身有MySQL的云数据库，我们有1500个实例，我们只有一个DBA，我们的平台现在没有做得像盖老师这样很细化地对每一个SQL审核，但是我们做了一个比较简单的，对SQL的CPU使用率、慢查询等东西做一个打分，也能够做到一定程度上可以分析这个产品的问题。我想要的是什么结果呢？就是能够快速地定位到一个慢SQL，在SQL执行、审查阶段就把你咔碴掉，第二个阶段是做了这个慢SQL，抓到这个慢SQL，生成一条优化好的SQL，告诉你帮你执行了。不知道我后面这个想法能不能在MySQL领域去实现，或者有什么样的技术能够支撑这个想法？谢谢。

盖国强：两个很好的问题，
第一个问题，这样的事情一定是对很多人有帮助的，为什么Oracle没有做。其实你会注意到Oracle关于服务层的事情很少做，Oracle是集中全力把它的数据库产品的内核做好。

其实Oracle对服务根本不关心，这部分对它来说利润率太低了，服务这块都是由第三方的生态来做的，这就导致服务相关的东西对Oracle来说不是迫切的事。我认为，这可能是原因之一。

第二个问题，我也知道在MySQL上其实很多团队也在做SQL审核的事情，也做了一些产品，像腾讯、去哪儿网等都在做，MySQL上为什么能够实现通过简单的审核筛查出来？

一方面可能是因为它的SQL简单，简单就是美，简单的架构是美，简单的编写方式是美，MySQL的SQL功能还是比较弱的，这就使得SQL问题比较容易筛查和筛选的。

而像Oracle，我刚才所举的都是最简单的例子，10表联合、20表联合、SQL上到几千行的时候，你会发现已经完全超越了MySQL的那种简单逻辑。

正是因为复杂性，才会导致了在这块做这件事会复杂很多，而MySQL或者开源的产品可能会容易一点。

但是大家在讲Hadoop等大数据的产品，都在不断地加强SQL的支持能力，如果不支持事务，很多人觉得不爽，如果不支持标准的SQL，大家觉得不爽，所以大家都在朝这个方向努力。

所以，将来如果MySQL的SQL支持越来越复杂的时候，同样你会遇到和Oracle类似的问题，不同产品现在所处的阶段不一样，我认为开源产品还是在一个野蛮生长的状态，大家在疯狂创造的时代，再向后发展，如果在谋求商业化等等的过程中，我觉得会看到走类似的过程。这是我的一点看法。

2. 提问：你刚开始说2014年、2015年Oracle都是在做云端的工作，现在它有哪些成果？比如说，PPT中也说到Oracle有一个很大的问题在安装上，它的一些兼容，和操作系统的配置等，比如说，在云端可以和Docker结合，一个容器可以执行的东西等。

盖国强：你想了解的是说，Oracle做了那么多年，在云上到底有什么东西？我可以告诉大家全都有了。

比如说Oracle云端数据库，如果你不想在企业内部安装一个数据库，你在Oracle云上买一个它的云数据库就可以用，它全是自助式的，点点按钮就可以了，全部已经准备好了，而且它在Docker上也做了很多东西，OpenStack，全都做了。

但是问题是，它的价格比较贵，Oracle即便是提供云上的服务，它的价格仍然是很贵的，如果你去计算一下，觉得可能不一定能够用得起、不一定要用它。

另外一方面，我在北美真正感受到一点，企业和互联网是有很大差异的，企业级用户的变革非常稳健，虽然他们也想拥抱云，也想到云上去，但是它的变革会稳步进行，这无形中实际上是给了Oracle时间。

如果都像是互联网的速度，你不给我，我就自己做，那对于Oracle的压力可能就大了。当企业级用户真的要进行云上迁移，大步伐变革的时候，可能Oracle的云就已经成熟了。所以说，这是对Oracle最大的机会。

3. 提问：你提到现在在做SQL的审核工具，也会给一些优化的建议。我们有没有一种方式，比如代替用户做一个模拟或者代替开发团队做一个模拟，告诉他你用我的方式做完以后可以有多大程度提升，此外对你的业务没有影响？很多时候我们做一个SQL优化，必须要考虑我不可能做一个很大的变化或者改很多逻辑去对业务产生影响，保证业务的可用性应该是一个最基本的原则，有的时候不可用马上就可以恢复，长期的可以慢慢再看。这方面有没有尝试如何去让用户或者产品团队立马感受到这个效果？或者在一个模拟环境。

盖国强：为什么我把我这个主题也定义成DevOps，其实是什么呢？我们所做的SQL审核的事情，我们一直想把它放在开发端，因为你等到一个应用上线出现问题，这已经是运维的人背锅、踩雷了。

上线以后出现问题，用户的业务已经遭受到损失了。我们要做的问题是在事前就消灭在无形当中，所以我们希望在开发、测试环节多投入，所以我叫DevOps，运维做的产品，让开发在开发阶段过程中把问题找出来、优化掉。

你刚才讲到如何让用户体验到这种价值，我们现在一些用户那里就是在跟华为合作，我刚才的流程图是真实的，如果最早把问题找出来，你说我找到一百个问题给开发，开发才不理呢，给你扔出来，“你怎么说有问题？没有问题！”。

我们在跟开发商配合的过程中，最开始大家是矛盾冲突很激烈的，但是当一个阶段之后，大家发现彼此的价值之后，一切就改变了。

我们的客户是运营商，工作确实很繁重，而且它的系统非常重要，核心系统一年有40次大的变更、1000多次小的变更，几乎就是每周一次大变更。

以前客户面临的问题是变更以后系统资源明显就上去了，80%、90%、CPU跑满了，怎么办？优化，优化了一周资源消耗下来以后，第二周变更又上来，循环往复。

后来我们SQL提前审核优化以后，CPU平稳了，这是真实的用户体验，大家该放假的放假，以前变更的时候都得值夜班在机房蹲着，现在变更的时候大家可以回家了，真实地让大家感觉到生活和工作指数提升了，大家觉得这种方式确实有帮助，然后投入不大，大家都可以平稳地生活了，真实地体验到了，很愉快。

再后来，当有变更的时候，开发团队会主动地将SQL提交给我们去做审核，审核有问题的时候就来修改。尤其是我刚才提到的几条，还有一类类似的SQL，如何彻底优化？我们甚至提过专题讨论，我们所有专家来给方案，最后找到一个最佳的方案，把这个系统60%、70%的压力全部打下去，这就立竿见影。

4. 提问：我有两个问题，首先，你今天讲的Oracle的DevOps这边的实践，与其说是介绍SQL优化的工具或者上线前审计的工具来说，更多的可能是传递开发和运维一体化的一种思想。与其在事后做一些事情或者做一些优化，可能还要往前走一点，包括我们后台运维人员要配合开发人员做一些SQL模型的规范、SQL设置的一些规范，我是这么认为的。我想问的是，最近三年的时间，一些传统企业的去小机化和去Oracle，其实有一些客户在做这个动作了。请问在你的角度来看，怎么看这个趋势？目前来说，Oracle还是最重要的一个数据库。第二个问题，以你的角度，Oracle的一体机目前的市场情况覆盖率是怎样的？

盖国强：第一个问题，在去IOE的浪潮之下，Oracle的前景是什么样的。我用一句话可以概括，我个人的观点，我认为道路是曲折的、迂回的。一定是这样的，历史从来不是一面倒的，一定是曲折的，互有攻守、各有得失的一个阶段，就像看到微软，也有时能超Oracle一头。

Oracle的很多战斗力还没有发挥出来，不管是这个市场上竞争有多激烈，还没有人能够让Oracle去降价，我不认为市场上已经对它形成足够的威胁。

比如说，之前大家讲阿里在倡导去IOE，但是为什么只有阿里提倡腾讯不提倡？因为像这些早期的互联网企业，只有阿里在IOE的路线上，别人没有在这条路上。所以，这是我个人一方面的看法。

总结一下，我认为在这条路上会有变化，今天在数据库领域也是百花齐放的，有很多产品可以选，还有国产的，但是这个竞争一定是互有攻守、各有得失，不会是短期就能够看到巨大变化的一个市场，除非有一种颠覆性的理论出现，至少目前还没有一个颠覆关系型数据库的理论，像关系型数据库理论出现的时候那样，还没有到这一步。所以，我认为Oracle的路还有很长的时期要走。

第二，你说Oracle的一体机，Oracle的一体机已经被公认为这个市场上的一个非常具有创新性的产品，它已经在Gartner的分析报告中占据了独立开创的分析领域，它目前的数据在全球已经突破12000多台。

你可以看到，这种趋势引发了全球模仿的浪潮，大家都在学Oracle，像华为也在做数据库的一体机。云和恩墨也在做数据库的一体机，很便宜，跟Exadata的架构是一样的，你也可以用，开放式的去IE，把I和E全部去掉。所以，你可以看到有很多厂商都在学习Oracle，这恰恰说明它的这个方向很成功。

那么，就单从一体机的角度来说，Oracle有很多事情可以做，只不过它没有做，它仍然是在这个市场里面获得了高额的利润，如果它愿意降价的话，其实是具有压倒性优势的，我觉得国内做一体机的谁也打不过Oracle。

而且Oracle还可以有很多重要的杀手锏——它可以把它的某些产品变成国产的，比如国产的一体机，就像和腾讯的合作一样，Oracle可以和一个国内厂商合作。

今天IBM和国内厂商合作、惠普也在合作，大家都在合资合作，Oracle也会做，只不过它是受到这个压力最小的一家，还没有去更快速地推进，所以它跟腾讯的合作是第一步，明天它要说和华为合作做一个国产的一体机也有这种可能性。

所以，我认为Oracle有很多后招没有使用出来，在云时代它可能会重新崛起，因为它的资源太丰富了，它有Java，它有中间件、数据库，所有的东西它几乎都是自有的。谢谢。

（盖国强原创）