“网红”老盖解析Oracle Database 12c特性和实践

盖国强

云和恩墨信息技术有限公司创始人

盖国强，国内第一个Oracle ACE总监；技术论坛ITPUB版主。曾获评"2006年中国首届杰出数据库工程师"奖，拥有超过15年的数据库实施和顾问咨询经验，对于数据库性能优化及内部技术具有深入理解。

他是中国地区最著名的Oracle技术推广者之一，他的专著《深入解析Oracle》、《循序渐进Oracle》等书籍受到Oracle技术爱好者的广泛好评，他主编撰写的《Oracle DBA手记》系列作品是Oracle技术爱好者们分享和传播技术的重要书籍。

本文根据【2016 第七届中国数据库技术大会】现场演讲嘉宾盖国强老师分享内容整理而成。

我的两段职业生涯可以概括为O2O，前半段是在线上完成的，我和DDTCC大会，或者说后面的ITPUB论坛结缘已经有15年。从最开始参与技术社群的分享，博客的互动，到后期以写作出版书籍的方式来来分享知识，一路走来，我们的团队越来越壮大，很多技术爱好者参与到我们的分享当中,到后来我成为国内第一位Oracle ACE。

第二段职业生涯在线下，我们建立了云和恩墨这家公司，聚集了在线上结识的这些朋友、专家，为客户提供服务。现在云和恩墨旗下还有一个恩墨学院，在全数据库领域提供培训课程，从Oracle到MYSQL、Hadoop等数据领域。

无论是在线上还是线下，我们的技术分享不停歇。最重要的是，学习技术分享经验逐渐成为我们的一种生活方式，我们在分享中结交朋友，收获快乐。

甲骨文2015年在Iaas、Paas、Saas这三层上都做了大量的改进、创新，而2014年Larry的演讲总结几乎完全相同，甲骨文这家公司在过去已经用了两个整年将他的业务全面转移和迁移到云上去。这就是这家在中国市场占据50%以上份额的厂商在做的事情。全面向云上迁移他的产品和服务。

在埃里森的引导之下，我们看一下甲骨文数据库在向何处发展。这页PPT是甲骨文数据库的掌门人Andrew Mendelsohn主题演讲的核心。

他提到Oracle数据库12C今天是为云而全新设计的，未来注重三个方向上的演进。第一是敏捷；第二是弹性；第三是云。甲骨文数据库的未来演进正是在朝这三个方向发展。

那么在现实中，我们的客户又面对着怎样的实践过程呢？我做了一个简单的总结，企业级数据库架构经历的变革历程可以用八个字概括，就是“合久必分，分久必合”。我想在座大家做数据库很多人都有这样经历，我们经历了很长时间的“折腾”，技术在折腾的过程中不断向前。

最初，我们经历了数据积累增长带来的性能衰减，然后我们为了解决这些问题在开始分表、分库，今天我们可能又在考虑是不是要去IOE，去做异构的迁移。当然有很多用户又因为业务的驱动在进行拆分。这就是真实的企业经历。但是这些技术上的变化很多是和企业的经营目标相违背的。比如企业在成本上的考虑，希望成本降低，运维尽量简化。这两者之间存在着大量的矛盾。

企业在如何向前发展？我引用几个用户的案例，大家随着软硬件技术的提升和演进，很多企业的数据架构开始走向整合。过去的IT架构我把它称为烟筒式的村落建设。不知道大家是否会有同感。

我引用了一些用户的脱敏信息，可以看到以前用户每上线一套系统都会建设出来整套架构，包括数据库、主机、存储等，案例中是保险行业的系统概要，可以看到企业的数据系统非常庞杂，有监控、有统计、有销售、有精益生产、有六个能力，行业内的朋友可以知道，对于金融的还有各种监管、信托、核查、仓库等等大量的系统。这不仅仅有大量烟囱式的村落系统，而且这些系统的IT基础设施可能是完全不同的。他们可能会构建在不同的硬件之上、不同的操作系统，从数据库角度可以看到，数据库版本是千差万别的。

用一个比喻来描绘，我们仿佛在维护着一个动物园。它里面有各种各样不同的动物，脾气秉性习惯完全不同。每一个版本，每一个系统，你都要面对大量的挑战。那么自然而然的我们说在业务的发展驱动之下，很多用户开始走向整合。

第二点就是简洁快速。一项技术可以被大家很快的掌握最重要的是简单。

2015年的OOW大会上，埃里森展示了如何将一个数据库从一个数据中心迁移到甲骨文的云数据中心上去。通过SQL Developer的菜单，仅仅通过按钮点击就完成了这个迁移。

菜单里一个叫Relocate的功能,数据库迁移简化到点一下按纽就把数据库搬走了。

这也是我觉得12C里设计的一个重点，可以很简洁、便利地完成一些重要的任务。我把过程跟大家技术性地分享一下。

要完成这样一个动作，在Oracle 12C里，通过四个步骤将我的数据库从一个数据中心迁移到另外一个数据中心去。第一步是在线克隆，把本地文件和日志迁移到远程去，第二是通过增量同步去进行同步，第三步是静默源库，最后监听自动的将连接切换到远程去。整个过程中不需要任何的其他的干预，通过Oracle的Relocate一个操作就完成了。

数据库要整合在一起，另外一个前提是我们要有足够强健的硬件资源去支撑它。甲骨文从2008年开始做一体机，到现在已经发布了他的Exadata X6版本，能够提供500多万的IOPS处理能力，提供144核心和6TB的内存等等这样的高端配置。

实际上甲骨文一体机已经获得了巨大的成功，在全球卖出了12000多台，这里面最关键的是他总结的两个关健词，以前甲骨文讲『Hardware and Software Engineered to Work Together』，软硬件集成在一起为用户服务，而今天甲骨文谈的是集成云，用自己的技术整合去实现云服务。从Oracle口号的变化可以看出公司的演进。

当然甲骨文一体机方面的成功引起了很多厂商的追随。zData是云和恩墨提供的一个解决方案，通过我们提供的方案，同样可以用基于PC的开放式架构，为用户带来上百万IOPS的数据处理能力，以及数十GB的吞吐量带宽，这可以在三个服务器作为存储节点而实现。

今天我们的理念是『Solutions and Services Integrated to WorkTogether』,为用户提供的是解决方案和服务，帮用户实现端到端的数据管理。我们今天从数据库的设计、优化、维护到构建分布式一体化的解决方案，这是我们正在做的事情。

那么有了非常强劲的硬件之后，可以在此之上进行很多的创新。这是Oracle 12C里的内存数据库选件， 12C里最核心的两大特性就是多租户和内存数据库技术。当然大家知道甲骨文还有一个产品叫Timesten，是独立的内存数据库产品，和IMO内存选件不同。在这个特性里引入了列式存储，在12.2版本中，列式存储甚至还可以落地到FLASH上去，12.2版本里甲骨文数据库真正有两种方式物理存储，行式和列式并存。

IMO是甲骨文史上卖得最快的一个选件。所以取得成功我认为主要是它非常简单，就是甲骨文的敏捷性。几乎简单到只需要几条命令，设置一个内存区域，指定某一个数据表把他放到内存里去就完成了。就是这样。Oracle DBA花两个小时时间就可以理解这项技术。

这项技术在12.2里可以做到什么呢？可以自动判断哪些数据更适合于列式存储，并自动帮我们完成这项工作。甲骨文的数据库演进一直是这样的，提供一项技术，并逐渐让他自动化地去实现。

其实Oracle基于内存方面还做了很多改进，传统的内存加速，可以通过KEEP池去缓存数据，并且Oracle不断地去改进算法来提升性能，这其中包括11g的新特性Serial Table Scan。

当你的内存足够大之后，甲骨文12C支持一个特性叫做全库缓存，可以通过一条命令缓存整个数据库。

在内存数据库选件的革新上，有一个技术叫做SQL In Silicon。

如果大家做数据库运维，在数据库里可能看到很多类似以下的查询，要对一个时间区间、某类数据进行一个汇总。这类了SQL非常常见，也非常消耗资源。但是现在这类SQL查询甲骨文可以在CPU里完成它。不需要将数据通过外存读入内存、通过内存再进行运算。那么这样改进，事实上对整体的性能做到了几十倍的提升。大家可以想像，以前复杂的路径现在被简化了。

不仅SQL in Silicon，Oracle还有很多函数增强，可以实现SQL in Function，刚才讲到范围查询很常见，还有一类查询很常见，我们会经常做一些DISTINCT运算，这个运算也很消耗资源。在12C里面甲骨文对它做了非常小的改进，叫近似唯一值计算，通过一个函数来实现。

很多时候我们并不需要一个完全精确的结果。我想大多数人都知道，通过搜索引擎得到的都是一个近似数，如果我能够接受一个近似精确值，可以使用这个函数来获得一个近似值。它以小于5%的误差率可以获得5到50倍的性能提升。

不仅如此，在12.2版本里，Oracle把这项小的改变又往前推进了一步。如果你觉得这项技术是可以采用的，可以指定误差区间，允许多大比率的误差，可以获得更好的性能。更进一步的，如果你指定approx_for_aggregation参数，把它设为TRUE，数据库就不需要你显示引用approx_count_distinct这个函数了，会通过查询改写的方式自动地使用这种算法帮你执行，提升效率，但是获得近似的结果。你可以看到同一个函数的变化再到他把这项功能演进到自动去进行，帮助你不需要修改程序的自动进行。我认为这也是敏捷性的一种体现。

不仅如此，从12C开始，甲骨文允许你在一个SQL里直接引用函数，以前我们要创建一个函数，要调用这个函数需要权限，但是现在你可以把一个函数内嵌到一个SQL里去，直接去执行函数。这个特性在Oracle的大师Thomas Kyte的开发特性演讲里被列为第一位。它带来什么好处呢？常规的通过函数来查询，作为一倍的效率，使用位限函数可以得到3.8倍的提升，当然你还可以使用甲骨文另外一个特性，你可以使用一个UDF，它可以获得更好的性能。

所以引用一句名人名言，他说『当别人还在计较有没有这项功能的时候，Oracle在思考要以几种方式快』。

今天我们在面对这样一种情况，正是因为Oracle的SQL支持能够太强大、太灵活。事实上程序员可以非常快速的进行开发迭代。但是最灵活的SQL会在实践中提出问题，一个SQL的用法不当，或者执行不当就会带来性能问题，影响系统的稳定性。

今天事实上我们碰到的80%的数据库性能问题都来自于SQL。我们认为在开发环节上，如果能够对SQL的性能进行管控，将可以解决Oracle数据库绝大部分性能问题，我们把开发测试阶段的SQL监控审核，称为SQL审核。SQL审核也可以概括为O2O，线上到线下。一个是对线上的审核，一个是对开发过程当中审核，将SQL中存在的问题提取剥离出来，进行统一解决，从而保证线上运行的稳定。我们认为这是未来Oracle数据库领域的一个重要优化和发展方向。

大家看一下这个SQL，有一个基于时间的判定，一笔交易的时间。那么首先用户访问是要查出来五分钟之内的交易时间，这些数据。然后再往后看大家看到增加了一个条件，不论大家做哪个数据库管理，当你看到一个判断，基本上心就凉了半截。作为DBA你马上会认识到，由于OR的条件存在，如果这里有一个B数的索引，这个索引现在就泡汤了。因为这里面有NULL值，这个OR的或操作要把这个查询展开掉。实际上我又提出一个规则，就是当我们进行数据建模、数据架构设计的时候一定要考虑到缺省值的设计，如果可能的话你给这些字段设一个缺省值，如果数据结构设计的时候有这样的设置，就不会出现刚才的问题。这是我提出另外一个值得思考的地方。

然后我们看表上的索引，跟查询主要相关的有两个索引，一个是基于DealDate的索引，注意这个索引被直接忽略掉了，因为存在空值。

第二个有关的是个复合索引，UNI_ID和DealDate，注意这个UNI_ID本身也是允许为空的，所以仍然无效。除此之外，我们还可以看一看UNI_ID上，做了一个MOD运算，如果大家是对Oracle数据库非常熟悉的话,这会发生什么问题？会发生函数转换，也就是说即便你在UNI_ID建有索引，这里并不会发挥作用，因为这里面做了一个函数转换。所以大家看到，就这样简单的一个小小的SQL，里面已经存在了多个性能隐患。它简单吗？并不简单。 

我们看到这些字段、看到这些设置，开发人员和运维人员理解是不相同的。我们需要理解索引、理解数据。

好了，如果要解决这个问题可以怎么做呢？我们说我刚才讲到甲骨文在很多细节上的优化叹为观止，比如以下展示的缺省值替换NULL值，这会防范某些字段中出现NULL值。

从案例到规则、从规则到规范，从规范再演化产品，通过产品再自动化的替代人力劳动，这是时代的进步。