【技术分享】“网红”老盖解析Oracle Database 12c特性和实践

数据库技术大会 2016-08-24

197

本文整理自DTCC2016主题演讲内容，录音整理及文字编辑IT168@杨璐。如需转载，请先联系本公众号获取授权！

演讲嘉宾

盖国强

云和恩墨信息技术

有限公司创始人

国内第一个Oracle ACE总监；技术论坛ITPUB版主。曾获评"2006年中国首届杰出数据库工程师"奖，拥有超过15年的数据库实施和顾问咨询经验，对于数据库性能优化及内部技术具有深入理解。他是中国地区最著名的Oracle技术推广者之一，他的专著《深入解析Oracle》、《循序渐进Oracle》等书籍受到Oracle技术爱好者的广泛好评，他主编撰写的《Oracle DBA手记》系列作品是Oracle技术爱好者们分享和传播技术的重要书籍。

分享内容

我的两段职业生涯可以概括为O2O，前半段是在线上完成的，我和DTCC大会，或者说后面的ITPUB论坛结缘已经有15年。前期从创建开始参与到技术社群的技术分享、再到通过写作出版一系列的书籍，来分享知识，做用户组传播知识，到后来成为国内第一位Oracle ACE。

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

云是甲骨文最核心的理念

谈到数据库，尤其Oracle数据库，我们从前面吴承杨吴总的演讲里也看到云已经成为甲骨文最核心的理念。我引用一张甲骨文的创始人Larry Ellision在2015年OpenWorld大会上的演讲总结，这是他最后一页PPT，大家可以看到他总结2015年甲骨文做的事情是云上的革新。在Larry的主题演讲里核心关健词只有一个就是“云”。

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

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

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

数据库用户面对怎样的困境？

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

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

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

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

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

经验分享如何整合

这是我亲自参与的一些项目，我们在参与用户这些项目当中首先要思考如何建立一个科学的模型，去评估整合之后的容量。包括现在不管是去I或者去E，以及到云上的迁移都要做这一步的规划。只不过根据规模而复杂度不同而已。

那么如何去进行科学的容量规划么？第一步要做什么呢？

我根据数据库里边收集的数据，来做一个模型的评估，将多套分布式系统，将它的趋势数据叠加、偏移，再用算法来推算整合后它的容量。

这张图是帮助我们的用户，在做全国系统整合的时候，对CPU的推演。我要评估31个省市的数据库整合之后，它要消耗多少的CPU资源。

你可以看到最高点的时候要消耗120个CPU，如果将系统整合起来。我希望整合之后有50%的CPU使用率，那可能需要CPU进行双倍配置。甲骨文数据库有两大体系，一个是统计信息，一个是等待事件。在Oracle 11G里面它的统计数据有679项，而在12C里面有1178项，等待事件在12c中则有高达1650项，通过每一个数字都可以衡量和量度数据库某一方向的运行状况。

在进行充分的评估后，国内最近几年很多用户数据架构从分布式的村落走向集约化的整合，我们也帮助很多用户将他原来几十套数据库最终整合成一套、两套三套，大幅度降低了他的运维成本。很多用户获得了70%-80%的总体成本下降。

所以说如果大家很粗暴地去O，不如去考虑如何理性地整合、减O、减少成本，仍可享用最佳的数据库产品。在11g的整合过程中，由于多用户并存，如果我们有很多用户的名称的冲突，在这里会遇到很多障碍。

Oracle数据库今天的技术演进，就专门针对整合进行了增强，这其中一个关键特性叫多租户。就是说，将之前这些分散的数据库快速地融合在一起构成一个数据库，整合之后可以得到资源上的节约、提升，同时它的数据库仍然是彼此隔离的。我们之前的整合要基于用户将数据库融合起来，但是在12c的多租户中，在一个容器里可以接入很多独立数据库，这些独立数据库在未来可以很便利的克隆、迁移，这就是甲骨文说的敏捷，可以快速地对数据库进行多种维度的操作。

第一个主题演讲中吴承杨吴总讲到12C从第一版到第二版，在这个特性上做了大量增强。在多租户的容器了可以支持高达4096个PDB，在一个数据库内部可以有这么多独立的个体。

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

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 Work Together』,为用户提供的是解决方案和服务，帮用户实现端到端的数据管理。我们今天从数据库的设计、优化、维护到构建分布式一体化的解决方案，这是我们正在做的事情。

那么有了非常强劲的硬件之后，可以在此之上进行很多的创新。这是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数据库领域的一个重要优化和发展方向。

DevOps in Oracle：SQL审核防患未然

我们一个客户江苏移动的技术专家，他说：在生产中，绝大多数Oracle的业务系统出现问题都是SQL导致的。但是大多DBA，尤其是偏运维的DBA对SQL并不擅长，这些DBA承担着数据库运维和维护稳定性的职责，而他们对这些问题可能又无能为力。原本SQL的质量应该是开发层负责的问题，但目前的现状是，开发人员管不了，运维人员不擅长。所以当系统出现问题的时候，就需要专业人员“救火”，而事发或事后救火往往是业务已经遭受了损失。

那么我们提供一个最佳实践是帮助用户进行SQL审核服务，在开发上线环节帮助用户做一道把关，去防范这些问题导入稳定系统里面，从而预防式解决了问题。

我们应该如何去面对SQL问题，我举一个简单的例子。大家可以看到这个查询，简单的单表查询，有五个限定条件，它出的问题也非常简单，叫做全表扫描。

大家可以角色体验一下，开发和运维会存在天然的理解上的隔阂，开发人员倾向于功能实现、快速迭代、持续上线；可是运维人员看的是性能，如果你的应用存在性能问题，上线以后我就是踩雷了。就是这样一个状态。

我们看一下这个简单的SQL。它这么简单的一个查询，使用了全表扫描，我们的经验是，一定要在无数次的踩坑的过程中总结出来规则，然后通过规则指导我们的研发。如果有这个规则的话，不管是开发还是运维都要关注全部扫描，一定要规避不合理的扫描，大家知道全表扫描对于OLTP系统可能是个灾难。

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

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

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

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

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

DevOps的实践由案例到规则与规范

对于这个SQL来说，我们的优化可以非常简单。SQL中引用了MOD(UNI_ID)函数，其取值在5和6之间，我们认为这缺省包含了UNI_ID不为空的条件，所以做了一个改写，这时候SQL查询可以使用到索引。

但是注意我刚才讲到了，其实这还是不完美的。事实上因为做了个函数运算，在这里做索引上只能作用过滤条件，所以更精确的做法是我应该构建一个函数索引。

如果我们在这里能总结出一些规则的话，如果在SQL开发的过程当中能够尽量避免对查询条件使用类似的函数运算，这是最好的。如果你非要用的话，在索引设计的时候就要同时考虑使用函数索引，使得你的索引可以生效。

在我们的实践工作中应当有这样一个思路，我们要把我们遇到的问题形成规则，最后制订出规范，来约束我们开发或者运维。以上前三条规则是之前总结的，那么第四条呢？我们要站在开发的角度去理解为什么会有这样的逻辑，这才是根本，从源头上解决问题。

我们真的和用户一起去看，为什么有一个MOD函数在这里，最后得出这样一个结论，为什么要做这样的函数运算呢？事实上，程序通过运算得出结果之后对数据进行分片，然后开始并行进行操作。也就是说如果取到10个值的话，0和1分到一组、6和7分到一组，我是有多个进程并行做这样的后续操作。是通过这样方式进行分片的。

所以我们说我们优化不能停在后端，要往前走。当你理解前端是这样的设计的时候，会觉得SQL逻辑简直跟业务关系并不大。原来仅仅是为了分片、并行进行操作。那么DBA是可以提出更好的方案来优化这个操作的。

我们所理解的，DevOps在数据库领域的最佳实验，应该是我们能够由案例总结规则，规则汇聚成规范，如果能够开发衍生出工具产品来，帮助更多人更自动化地完成事情，让人的智力集中在20%有价值的工作上，我们认为这才是未来。

所以最后我们也跟大家分享一下我们自动化的实践。

大家可以想像，我们的职业生涯，前十年跟全表扫描斗争，后十年跟隐式转换斗争，几代DBA大约面临的都是这样的事。我们不要做这样的事，我们把这些事全部概括为算法，隐式转换、全表扫描，笛卡儿积等等这样的事情都转化为算法。然后我让这个算法在开发测试阶段进行筛查审核，在开发测试阶段就审核出应用的SQL质量问题，提前解决，防患于未然。DBA到这个环节跟开发人员一起解决问题，治本治未病，我认为这才是未来。

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

云带来的数据库运维改变

我认为在未来传统的运维DBA你的空间越来越少。以前DBA的主要工作很多消耗在安装、部署、调试硬件，进行监控。这些工作能够很快地被云取代、被自动化的产品取代。

但是我们讲的产品DBA、开发DBA，我和应用在一起，了解应用逻辑，可以规划数据架构，规划业务架构，进行SQL审核，SQL优化。我们认为这些职位会非常的热门。我们在这个方向上招聘是没有限制的。大家说如果我的SQL能力特别强，我们有两位全国SQL大赛冠军，大家可以一起做一些挑战，如果这个能力很强，会随时找到非常具有诱惑力的工作。

在我的观点里，在云时代甲骨文是非常特殊的一个存在，刚才讲了去IOE，在IOE三大厂商里甲骨文非常独特的，原本是一家数据库的厂商，大家听到甲骨文这个词首先想到是数据库。但是在云的时代这一切发生了改变。它今天是全堆栈的服务提供者，从Iaas、Paas、Saas，都有非常丰富的产品提供。从CPU到一体机，从JAVA到数据库到中间件，到Saas，事实上我们说甲骨文的业务范围在不断扩展。在全球建立了20个数据中心，我相信甲骨文和腾讯在中国的合作也将会有重量级的产品发布。

所以我认为甲骨文的风云还正在兴起。云和恩墨作为国内数据服务行业内的领导者，我们一直致力于通过服务去为用户提供更好的解决方案。谢谢大家。

关于DTCC

中国数据库技术大会（DTCC）是目前国内数据库与大数据领域最大规模的技术盛宴，于每年春季召开，迄今已成功举办了七届。大会云集了国内外顶尖专家，共同探讨MySQL、NoSQL、Oracle、缓存技术、云端数据库、智能数据平台、大数据安全、数据治理、大数据和开源、大数据创业、大数据深度学习等领域的前瞻性热点话题与技术，吸引IT人士参会5000余名，为数据库人群、大数据从业人员、广大互联网人士及行业相关人士提供了极具价值的交流平台。

oracle

文章转载自数据库技术大会，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

【技术分享】“网红”老盖解析Oracle Database 12c特性和实践

评论

相关阅读