我的职业生涯大致可以概括为两个阶段，用今天的语言来说就是：O2O，即从线上到线下。
我的前半段技术生涯基本是在线上完成的，大学毕业后，我有幸参与到ITPUB论坛的建设中，最终成为其中主要的成员之一。ITPUB论坛聚集和培养了那个时代一大批数据库人才；然后我开始写作了一系列的Oracle技术书籍，使得我可以接触到那些各在天涯的读者朋友。
我当年来到北京的时候就立下志愿，每年要出版一本书，所以在那些年里我写作编辑出版了一个系列的Oracle相关技术书籍，从基础到优化和安全，基本都涉及了。接下来，我们又做ACOUG用户组，传播Oracle技术。这基本是我线上的技术生涯。
由于我在社区上的努力，获得了Oracle的一个荣誉称号——Oracle ACE总监。Oracle ACED这个称号至今也是比较少的，在国内Oracle用了十年时间一共发展了十位左右，而我是当时的第一位。
我的第二段职业生涯在线下。我们汇聚了在线上结识的技术专家，成立了云和恩墨公司，在国内提供数据库方面的咨询和服务。这其中，我们汇聚了6位Oracle ACED 专家，2位 Oracle ACE，这是我们的骄傲。
聚专业的人，做专业的事。到今天，云和恩墨已经服务于金融、电信、能源、互联网等行业300多家企业客户。
正式内容从一则谣言开始：近日，由于苹果的App Store出现问题，很多人在传消息说苹果下架了腾讯的所有产品，证据是搜索不到。
这其实是不可能的，从商业的角度来看也不会出现。我开玩笑说：可能是苹果升级了Oracle数据库，检索的排序出现了问题。
从我的检索来看，搜索Tencent可以找到腾讯的产品，从分类里也可以找到微信。而且苹果App Store的后台确实是Oracle数据库。那么，全球用户访问的压力，如何通过集中、单一的Oracle数据库支持这海量并发的请求呢？
这就属于数据架构层必须解决的问题。在Oracle的体系结构里，可以通过读写分离的设计，分担对于单一共享存储的密集I/O访问。
我认为这也是今天企业CIO需要关心的一个方向，即：如何持续提高业务连续性？甚至在极端情况下，如何实现有限度降级的服务提供？
如果业务和数据是持续甚至爆发式增长的，那么分散负载的架构设计必不可少，在数据库技术里，读写分离是很常见的设计。要读写分离，就要涉及到数据同步和复制，这在技术实现细节上需要仔细探讨。
在Oracle数据库里，可以通过日志（Redo Log）的传递，实现一个同步的备库机制，这被称为Data Guard技术。备库可以经由日志保持和主库的同步。尤其是在Oracle 11g的版本中，支持了称为Active Data Guard的机制。
备库在恢复时可以同时被读取，这看起来轻而易举，但是在11g之前备库在恢复时是不可读取的。Oracle自1992年Oracle 7开始引入备库的概念，到2007年11g第一版本开始支持ADG，而且这是一个收费的功能选件。
技术进步确实是市场和用户推动的，当用户的真实需求涌现出来，厂商才会以较大力度去支持和改变。
图中所示是苹果公司采用ADG实现的读写分离架构，国内的阿里巴巴当年在11g的第一版本同样采用了这一功能，可见这一功能实现的广泛用户真实之需求。回顾过去，借鉴当下，在今天我们设计企业数据架构时，应当从初始阶段就开始考虑读写分离的架构设计和实现。
此前，我曾提到，数据库的变化真的会影响到查询检索的输出吗？答案是：真的会。
这样的变化可能来自于细节的技术改变。以此次苹果商店发生的情况为例，大家看到同样的查询，第一个查询的结果是按照字母排序的输出，第二个查询的输出就没有排序。这是Oracle数据库9i到10g时很多用户升级之后遇到的问题，原本有序的输出忽然变成乱序的，就像苹果昨晚出现的问题。
这个变化是因为Oracle的内部算法发生了变化，原本分组使用了Sort Group，也就是先排序再分组，其结果是自然有序的；后来为了提升性能，采用了Hash算法，在分组时就不需要排序，结果表现的输出就是乱序。
本源应该是什么样呢？其实用户需要排序时，应该引入Sort进行排序。原来的分组排序是通过一次分组完成了，这算是“搭车”，一旦算法发生改变，这些“搭车”的程序就可能出现问题了，所以该排序的时候，就应该进行排序。
之前的部分，我们深入分析了架构，在这里将强调开发和测试。
1.在开发阶段，应该建立明确的规范，以严谨的逻辑和算法来实现。一切小聪明，可能终会成为大麻烦。
2.在测试环节，重要的变更需要进行详尽的测试和演练，防患于未然。
2014年曾有一个新闻事件，美国国务院负责审批旅游证件的全球资料库发生故障，令美国护照和签证工作受到严重影响，全球申领美国签证或美国护照全部受到延误。当时的故障原因是数据库从10.2.0.3到10.2.0.5进行升级，测试不足衍生的一系列问题。
再举一个例子，这是一个非常重要的系统，真实的生产事故。客户进行了一个非常“小的变更”，将数据库从11.2.0.1升级到11.2.0.3，很小的版本变化，但是引发了一系列故障，最后也是客户的高层找到我来分析这个事故。
何以生故障？仅仅是程序员的一个“搭便车”。
Oracle有一个非标准函数（是Oracle自己内部使用的），这个函数是 wmsys.wm_concat ，首先Oracle不推荐用户用，而且这是基于Oracle一个产品功能安装的，很多用户不需要这个功能。
但是这个函数用于行列转换很方便，结果被非正式地广泛使用了。Oracle在升级时做了一个调整，将返回值类型由原来的字符改为了CLOB，而CLOB会使用临时段，导致了系统的空间耗尽，出现故障，最终不得不修改这个调用函数。
Oracle和苹果的关系不仅如此，如果用Google去搜索“乔布斯最好的朋友”，你可以看到是Oracle的创始人“Larry Ellison”。我十分不推荐用百度，其结果完全不同，最可怕的是还可能致命。
当然乔布斯和埃里森的关系不仅仅是小报说的这些。在《乔布斯传》里曾经提到一个细节，拉里•埃利森说：“我都没法儿跟你说我在《玩具总动员》出品前总共看了多少个版本，到最后，这就变成了一种折磨。我要去他家看最新的那10%改进的内容。史蒂夫执迷于把一切都做好——无论是情节还是技术，任何不完美的东西他都不会满意。”
乔帮主的完美主义为我们呈现了极致的产品，其实Larry Ellison也一直致力于打造和苹果一样的生态体系及产品，在Oracle发布的第一个一体机Exadata版本时，Larry就在演讲中调侃：“我的一台机器比乔布斯最大的iPod还大1400倍。”而Exadata正是Oracle致力于打造的一体化产品。
当然Oracle在数据库市场上的地位毫不逊色于苹果在其领域的地位，Oracle在商用数据库领域一直占有半壁江山，但是如何持续去优化Oracle的产品，提供整合服务是Oracle一直在努力的方向。图示是2013年Gartner的数据，Oracle占有率是47.4% 。
2015年的占有率大约是45.6%，可见Oracle在这个领域的地位是非常稳固的。在中国市场的占有率还要更高，超过了半数。
我认为Oracle在最近十年间最重要的产品革新还不是数据库，而是一体机集成系统，就是前面提到的Exadata一体机——Larry Ellison打造的和苹果类似的整合系统。
在一体机中，Oracle第一次在外存和内存中间，引入了一层Flash Cache，从而加速了数据访问，当然在数据库端Oracle也做了大量改进，使得软硬件高性能的集成在一起，这一系列改进使得这个产品获得了巨大的成功。
最初Oracle和HP合作，收购了SUN之后，整体设备由自己打造，到今天全球出货量超过了12，000台。这对于一个软件公司来说，已经是一个巨大的成功。
从外存到闪存，再到今天的内存数据库（Oracle称为In-Memory Option），Oracle这些年将软硬件结合做成了。
Oracle收购SUN之后就一直在做另外一件非常重要的事情，就是将数据库和Java的一部分功能指令嵌入到CPU当中去。
新一代的处理器称为M7,Oracle将会在一体机中，通过SPARC处理器替掉Intel，这次真的实现端到端的成本Larry可控。
而且Software in Silicon之后，Oracle的数据库性能将会获得大幅度的提升，一些特定类型的SQL可以在CPU中完成处理。
我此前见到Oracle的IMO产品经理，他给出的数据是，IMO的列存性能较之前的IMO提升了170倍，结合压缩技术实现每秒扫描1700亿行记录。
总结来说：Oracle今天的策略是，依托强劲的硬件支撑，推动用户进行数据整合（Oracle Database 12c Multinent多租户特性，可以在数据库内部实现隔离），通过IMO内存列式存储加速使OLTP、OLAP共存。一统关系型数据天下，一个数据库包罗万象。
其实我们很容易看到，Larry Ellison的思路和乔帮主是非常相似的。
很多用户大量采用Oracle的一体机，图示是PayPal的架构，通过Oracle的一体机技术支撑业务，主备之间ADG实现1000公里以上的数据灾备，备库同时承载查询的读写分离职责。主库还通过OGG（Oracle GoldenGate）复制软件，对数据库的数据实时复制到ETL环境。
这是Oracle全堆栈的典型架构实现，RAC实现集群、ADG主备读写分离、OGG复制、Exadata底层硬件支持。
从数据架构上来看，企业发展演进的道路其实可以用八个字概括：合久必分，分久必合。而且分分合合是交织在一起的，IT的历程是永恒的变化。
企业经历了数据增长、性能衰减、成本提升，然后开始分表、分库、分布式，去解决企业数据发展过程中面对的问题，然而这其中的很多步骤是和企业的部分目标相违背的，比如在性能之外，企业还要考虑提升系统的稳定性、保障数据安全、降低TCO的总体拥有成本。
所以随着技术的发展和演进，企业的IT建设过程也可能是曲折迂回的。
Oracle数据库一直以来是以Scale Up的方式向上扩展，共享存储是Oracle数据存储的基本方式。所以Oracle典型的数据库架构，无论是从基本的HA主备切换，还是RAC集群的多实例并行，这些架构的基本前提都是有一个可共享的存储设备。
但是集中存储的显而易见的问题是：如果对于存储的访问过于密集超过了存储设备的承载能力，那么系统必然遭遇到严重的性能瓶颈。传统IT时代，不断扩展存储设备造就了一批存储企业的辉煌，然而对于互联网企业的各种爆发式需求，单纯硬件的支撑已经不能满足业务发展的需要。
共享存储的问题依然存在，就需要继续去解决，在Oracle推出Exadata的一体机中，底层使用PC服务器构建而成了分布式的存储架构，将存储打散和分散开来。这一改进全面改善了Oracle数据库的性能，进而引起了这一架构的广泛关注和跟进。
Oracle数据库配合一体机（Exadata）实现了Smart Scan等特有的功能，使得Oracle一体机的性能更加突出。但是总之，这是Oracle在集中式数据库上分布式存储的探索实践，并且取得了极大的成功。
我把Oracle的一体机总结为：去IE的分布式存储架构。
在今天从事分布式存储、软件定义存储、Server SAN、Virtul SAN……的公司非常多了，但是Oracle把自己产品打包集成起来，获得了独一无二的竞争优势，这是重要的里程碑。
Oracle的一体机，简单来说就是通过PC服务器堆叠，存储和计算都通过PC来完成，由于Oracle数据库的RAC集群需要共享存储，在软件上进行了一层存储定义。
当然，其实云和恩墨今天也提供了分布式存储解决方案，一体机架构，称为zData，和Oracle Exadata架构类似，底层通过PC服务器和Flash存储加速I/O，100GB IB网络提供高吞吐带宽，3个存储节点轻松实现超过8K块大小100w iops的处理能力。
既然我们已经提到了Oracle的集群技术 - RAC，主备的容灾架构 - DataGuard、ADG，那么就必须提一下扩展RAC - Extended RAC。
如果能够在高可靠的网络中，将RAC的不同节点分布到不同的数据中心，那就可以实现真正双活的扩展RAC集群。图例将RAC的4节点，部署在两个相聚50Km左右的数据中心。
由于很多用户的灾备多数处于备用状态，在真正灾难来临需要切换时可能并不可用，双活看起来是更好的解决方案，但是扩展RAC对于网络要求很高，近年来的真正用户实践才慢慢多起来。
既然硬件能力提升了，Oracle希望能够推动用户将以前分散建设的数据库整合起来，同时为了更好地适应云的数据库支持，Oracle在12c中改写了数据库架构实现了多租户的特性。
在多租户特性中，每一个以前的独立数据库，都可以作为一个子集 - PDB（Pluggable Database)加入到一个容器中来（CDB - Container）。但是对于外部使用，甚至在这个容器中，这个PDB看起来都是一个独立的数据库，如果在云上实施，每个用户只需要一个PDB的子集就够了。
数据库的分分合合，Oracle希望企业级用户可以基于多租户的特性去实施数据库整合。这是Oracle 12c最重要的新特性之一。
从数据存储的微观来看，当数据容量增大之后，为了提高查询性能，很多时候架构上的一个重要考虑就是分表，通过特定条件将数据拆分开来，比如按照时间、地域等等。
在Oracle数据库内部支持一个分区特性，可以在同一个数据表中实现数据分离，通过多个存储段来存储满足特定分区条件的数据，从而实现数据分片。
这是一个我优化的案例，当时用户系统中存在一张典型日志表的查询，占用了系统20%的逻辑读，为了解决这一问题，我们详细的分析了所有访问该表的SQL（之前用户评估并不适合分区），针对查询谓词汇总，并测试所有典型的SQL，评估其分区前后的性能改变，针对性的进行微调。
针对现有业务系统的调整优化始终面临一个挑战，就是：如何保证调整对于所有应用都产生正向的影响？毫无疑问详尽的测试必不可少，Oracle有一个功能称为RAT - Real Application Testing，可以捕获生产系统负载，在变更后的系统上重演，以验证其性能改变。
这一特性是今天升级变更不可缺少的测试步骤之一。
经过详尽测试微调之后，这个数据量大表被实施了分区，其效果是影响这个系统20%左右的逻辑读几乎被全部消除。这是分区可能带来的查询数据剪裁，缩减I/O访问带来的性能改善。
可是在一些对性能要求极高的环境下，很多用户还是想要Sharding。通过Shard，将数据分离开来，不同分区只存储一部分数据的子集，应用被设计成按照条件去访问特定数据库分区。MySQL在分库分表的条件下也经常被如此使用。
这是淘宝当年去O的中间态，也可以作为借鉴。淘宝是逐步将Oracle中读密集的数据表，分拆出来分布到大量的MySQL上去，MySQL又通过主从来保证高可用性。事实上这也是读写分离的实现。
但是这样的分布架构，数据割裂开，带来好处的同时也必然带来应用的复杂性，应用需要通过一种方式路由到需要的数据库上，淘宝的TDDL是变革过程中随之出现的产品。
今天Oracle的重度用户，也有将读分离到MySQL的案例。这个架构作为生产态在今天也依然存在。可是很多Oracle用户数据量还是会很大，并发还是会很高。
Oracle在即将发布的12.2版本中，也将发布Sharding的新特性，将Oracle数据库的底层存储彻底拆分开来。现在你也将拥有一个分布式的Oracle数据库了。Oracle 12.2，是很多用户在等待的一个版本，将在6月正式发布。
如果你想将集中式的存储分开来，Oracle数据库也会满足用户的需要。这一特点是在Oracle分区技术上，以前的分区基于数据库内部实现，现在可以基于数据库级别实现跨越数据库的分区。
分区、分表、分库，在数据库领域以种种形态演绎出来。
当然数据实现了分片，就存在数据访问上的路由。Oracle通过Shard Directors和Coordinator数据库实现路由。分布式数据库莫不有此。
我们可以想象，当原来后端一个数据库被分离成数十、上百甚至上千个数据库后，应用的连接管理也会成为一个难题，Oracle为此开发了一个GDS产品。用于实现数据库的连接管理，诸如主备切换等功能都可以由这一层次接管。这一产品已经随12.1版本发布了。
Larry Ellison连续两年在OOW大会上总结，Oracle在云上持续革新，由此可以看出，Oracle向云上转型的决心。2015年Oracle宣布和腾讯合作在中国落地其全球的第20个数据中心，可以看到Oracle在公有云上的发力和速度，公有云也将改变Oracle数据库的使用方式。
云产生了这么巨大的影响，也必然影响到我们，我们是做运维服务的，那么在云时代，运维和DBA会向什么方向走？
下图是Gartner的一个分析报告，在技术成熟度曲线上可以看到，今天最火热的就是DevOps，现在大家都已经在谈DevOps各种形态的落地和实现。
在DevOps的时代，大家对于一件事情的整体理解发生了改变。传统的形态下，开发人员认为老板给钱，就是让我快速迭代开发一个软件，实现一个功能；运维的使命和职责是为了让系统更稳定，减少不确定性变更。
这两者天然存在着矛盾和对立，尤其是在开发一贯的加班加点赶工的情况下，缺少文档、缺乏完备测试，比如不断将不稳定性引入线上。
但是今天我们看到，大家最终认识到必须把我们的目标统一在企业的共同目标之下，大家如何让一个系统变得更稳定、为用户提供更好的服务，这才是根本的目标，只有企业目标实现了，这两伙人的目标才能最终实现。
所以，我们认为DevOps更重要的是让大家树立一个全局的观点，从全局的观点去看运维。以前我们国家有一个成语叫盲人摸象，如果每个人都只是从自己的角度看一小块内容的时候，这时候很多看法难免是矛盾和对立的。运维抓到的是尾巴以为程序很单薄，而程序员认为手里是稳健的柱子。
这是一份内部的分析数据，代表在Oracle数据库使用上遇到的问题分布。
毫无疑问，云也会改变数据库的使用和运维方式，我一直认为那 3.03% 的性能问题是最有含金量的部分，根据经验这部分问题多数来自SQL开发编写不当。
在DevOps的时代，运维和开发紧密的结合，推进产品质量的改善，是架构师和DBA共同会涉及的职责方向之一。
在数据库领域这个方向的最佳实现之一，我以为是SQL审核。
此前提到了，最终那3%的性能问题会成为工作的核心。跟性能相关的问题正是最经常影响到用户业务连续性、可用性的问题，是对于用户影响最大的问题，也是不容易通过标准化去解决的问题。
其实超过80%的性能问题会是SQL问题导致的，你的一个SQL编写不良、存在性能问题，跑到线上去，在高并发的情况下可能瞬间就会引起雪崩。
在线上系统中，由于种种复杂原因的加入，情况可能更趋复杂，比如并发、统计信息等等。
在今天Oracle的数据库产品这么成熟的情况下，在SQL、在性能上为什么还存在这么多重要的问题？通过调研我们发现几乎所有的企业中，开发通常是一个群体非常庞大的队伍，运维团队可能三五号人，大公司几十号人，但是你面临的开发团队可能是几百、上千人，这个庞大的群体变化是非常频繁的，经常的有人员流动，很多新人进来以后会循环往复地将初级问题、低级问题带到系统中来，这是我们在很多用户那里看到的现状。如何去解决这样的问题，是我们一直在思考的，我们今天把它定义为SQL审核。
这是我们最近一直思考和实践的方向，我认为云会推动和加速这一领域的变化。
1、SQL审核方面，有辅助的工具吗？
有辅助工具，我们也在做产品。同时，我们能看到行业里很多公司在这个方向努力，包括腾讯、去哪网的团队，在很多大会上都在做分享。
2、如何把握SQL规范呢？
我在运维大会做过一个演讲，讲了我的历程，即：从案例总结规则，从规则汇聚规范，从规范衍生产品。我做10多年的数据库优化，面临的问题大都类似。我开玩笑说：不幸的数据库大都相同，幸运的数据库各有各的幸运。如果只是经验，行业里就是重复劳动，所以需要总结。而规范已经很多，花时间就可以聚而为规范，然后需要执行，需要用产品监督规范的落地。
3、据我所知，Oracle有ADDM可以用来发现、优化SQL，这个和第三方提供的优化工具有哪些区别？
不同工具的侧重点不同。Oracle的ADDM也是建立了一个专家库的诊断系统，主要用于线上的分析。其实我们希望有一个系统，能够在开发阶段发现和解决问题，包括潜在问题，以确保线上稳定。防患于未然。
大家或许很难想象，我们非常核心的用户，系统中编写错误的SQL都非常多，审核这部分问题都是一个挑战。DevOps，我想就是要事前、靠前去审核解决潜在问题。
4、数据库死锁的问题有没有好的预防、分析、诊断和处理的工具？
对于Oracle数据库来说，死锁会被强制解锁，基于解锁日志可以获得较为详细的信息分析死锁的成因。目前我们主要是基于这些来分析死锁，没有特别的工具。
嘉宾介绍：
盖国强——云和恩墨（北京）信息技术有限公司/董事长、首席架构师，Oracle ACE总监，ITPUB版主
盖国强先生是中国地区首位Oracle ACE和ACE总监，曾获评"2006年中国首届杰出数据库工程师"奖，拥有超过15年的数据库实施和顾问咨询经验，对于数据库性能优化及内部技术具有深入理解。
公司介绍：
云和恩墨以“数据驱动，成就未来”为使命，致力于成为国内数据服务的领导者。目前基于企业级的咨询服务、优化服务、开发审计、监控服务等服务于国内近300家企业。
（点击标题即可阅读）
能共苦为何不能同甘？股权分配决定企业生死！
技术中立的我们，价值观能中立吗？
让员工每次打卡变成一次互联网点击......看看这个连续创业者的的商业思考！
Top sales？不，企业不需要聪明的销售，而是需要蚂蚁雄兵！
（深度超长，慎入！）开创软件的工业4.0新时代，人人都是开发者
原文始发于微信公众号（牛透社）：APP Store里找不到腾讯产品，是商业问题？不，可能只是因为苹果升级了Oracle数据库！
