以下整理总结来自盖国强（Eygle）上周四晚云和恩墨大讲堂的分享：我的学习之路和 Oracle 数据库的架构演进，希望能对大家了解 Oracle 的架构演进有所帮助。

大家好，很高兴今天有机会和大家一起分享一个主题。在分享主题前面我加了八个字：天道酬勤、自强不息。这是我最喜欢的八个字，也是指导我学习成长的座右铭。因为是在架构师群和 DBA 群同步，所以内容主要从大的方向分享一些知识和经验。

1. 自我介绍

首先做一点简短的自我介绍。我的职业道路基本上可以用 O2O 来概括。

• 前半段和 Online 有关，我从参加工作，接触互联网，结识了一群好友，参与到 ITPUB 论坛的建设过程中，最终论坛成为了国内最大的数据库方面的专业论坛，当年在其中结识的朋友很多都成为了工作的伙伴、生活中的朋友，这是我线上生涯收获最大的财富；

• 然后我编辑、写作、出版了一个系列的 Oracle 技术书籍，和很多读者成为了未谋面的朋友，这也是我线上生涯的延伸；

• 因为这些努力和技术传播，我成为国内最早被 Oracle 官方授予 Oracle ACE、ACE 总监称号的技术人。

• 在那以后，我们在线下组织了 ACOUG 用户组，进行技术分享，并最终建立了云和恩墨公司，汇聚专业的专家，专注在数据领域，为用户提供专业的服务。

今天，云和恩墨汇聚了国内10多位 ACED 中的6位，这是我们的骄傲。聚专业的人，做专业的事。

2. 天道酬勤

我推荐的方法以及步骤大致分为六个阶段：

• 打好基础，这是学习一切的起源阶段，万丈高楼平地起，基础重于一切；

• 学会思考，在学习的过程中必须学会独立思考，唯有学会设问并解答，才能真正获得提高；

• 掌握方法，我的方法是由点及面，由浅入深，在遇到问题时，由一个点下钻深入，直至问题的本源，在这个过程中相关知识点的学习会让你掌握一个知识面，最终在大量专研后融会贯通；

• 养成习惯，在任何一个领域都有潜在的素质要求，作为 DBA 和数据人，严谨是基本的素质要求，严谨严格才能在复杂的环境中幸存下来；

• 实践修正，纸上得来终觉浅，要通过实践去验证和检验知识，在实践中积累经验成长起来；

• 臻于至善，经过山重水复的旅程之后，抵达见山见水的从容，这是技艺的最高境界，作为 DBA 应当能够见微知著防患未然，从容而治。

3. 回馈感恩

我一直以为，在学习的道路上，勤奋和坚持是成就技术道路的关键所在，如果又是在自己感兴趣的方向上用正确的方法导引，则学习必然事半功倍。

前几天，在杨廷琨的访谈文章中，杨长老也强调坚持的重要，大家的观点完全类似：

“谈论 Oracle 技术学习的文章非常多，方法真的不是最重要的，持之以恒不间断的学习才是成功的关键。而除了潜心研究外，多关注新的技术发展和趋势十分关键。低头做事，抬头看路，了解最新的技术发展和行业的趋势可以避免走弯路，对于更好的理解技术的演进很有帮助。”

杨长老罗列了四种学习路径，包括他自己的，我稍加总结就是：

• 杨廷琨从阅读 Oracle 官方文档起步，先看 Concept，再看 Administrator，然后是 Backup、Performance Tunning、RAC、Data Guard、Upgrade、Utilities、Network 等等，通读所有重要官方文档。

• 盖国强多次提过他的学习方法是由点及面，抓住每个技术点，不断的深入下去，最终把整个体系的脉络理清楚。

• 崔华的学习方法是通读 Metalink 文档，他在演讲的时候介绍他每天要看几个小时的 Metalink 文档，每天都会经历多次的页面超时。

• 张乐奕更喜欢关注国外顶级专家的 BLOG 和 Mail List，这样可以快速的获取到业内专家的最新研究成果。

这四种学习方法，我概括成两类：Full Scan 和 Index Scan.

• 杨长老有"Oracle 百科全书"的美誉，他看文档是全表扫描，遍历；崔华钻研技术也是如醉如痴、废寝忘食，他读 MOS 是经年累月持之以恒的，也属于全扫；

• 我和张乐奕的方法有点像索引扫描，我推荐由一个根节点下钻，然后你可能发现几个分支，一堆叶节点，通过这样的过程由点及面，形成体系。

方法可以借鉴，但是最终还是要找到适合自己的路径去学习前进。我以为以上探讨的经验和思路，适用于所有领域的学习之中，希望对大家有所借鉴。

4. 架构演进之分久必合

从数据架构上来看，企业发展演进的道路其实可以用八个字概括：合久必分，分久必合。而且分分合合是交织在一起的，IT的历程是永恒的变化。

企业经历了数据增长、性能衰减、成本提升，然后开始分表、分库、分布式，去解决企业数据发展过程中面对的问题，然而这其中的很多步骤是和企业的部分目标相违背的，比如在性能之外，企业还要考虑提升系统的稳定性、保障数据安全、降低 TCO 的总体拥有成本。

所以随着技术的发展和演进，企业的IT建设过程也可能是曲折迂回的。

5. 架构演进之共享存储

Oracle 数据库一直以来是以 Scale Up 的方式向上扩展，共享存储是 Oracle 数据存储的基本方式。所以 Oracle 典型的数据库架构，无论是从基本的 HA 主备切换，还是 RAC 集群的多实例并行，这些架构的基本前提都是有一个可共享的存储设备。

但是集中存储的显而易见的问题是，如果对于存储的访问过于密集超过了存储设备的承载能力，那么系统必然遭遇到严重的性能瓶颈，传统IT时代，不断扩展存储设备造就了一批存储企业的辉煌。然而对于互联网企业的各种爆发式需求，单纯硬件的支撑已经不能满足业务发展的需要。

6. 架构演进之读写分离

在 Oracle 的体系结构里，可以通过读写分离的设计，分担对于单一共享存储的密集 I/O 访问。

Oracle 数据库可以通过日志（Redo Log）的传递，实现一个同步的备库机制，这被称为 Data Guard 机制。备库可以经由日志保持和主库的同步。尤其是在 Oracle 11g 中，支持了称为 Active Data Guard 的机制。备库在恢复时可以同时被读取，这看起来轻而易举，但是在 11g 之前备库在恢复时是不可读取的，Oracle 自1992年 Oracle 7开始引入备库的概念，到2007年 11g 第一版本开始支持 ADG，而且这是一个收费的功能选件。

技术进步确实是市场和用户推动的，当用户的需求真实涌现出来，厂商才会以较大力度去支持和改变。

图中所示是苹果公司采用 ADG 实现的读写分离架构，国内的阿里巴巴当年在11g的第一版本同样采用了这一功能，可见这一功能实现的广泛用户真实之需求。但是由于这一功能是收费的，其读节点越多，成本不可避免的会越高。

回顾过去，借鉴当下，在今天我们基于 Oracle 去设计企业数据架构时，应当从初始阶段就开始考虑读写分离的架构设计和实现。

7. Exadata

共享存储的问题依然存在，就需要继续去解决，在 Oracle 推出 Exadata 的一体机中，底层使用 PC 服务器构建而成了分布式的存储架构，将存储打散和分散开来。这一改进全面改善了 Oracle 数据库的性能，进而引起了这一架构的广泛关注和跟进。

Oracle 数据库配合一体机（Exadata）实现了 Smart Scan 等特有的功能，使得 Oracle 一体机的性能更加突出。但是总之，这是 Oracle 在集中式数据库上分布式存储的探索实践，并且取得了极大的成功。

很多用户开始采用 Oracle 的一体机，图示是 PayPal 的架构，通过 Oracle 的一体机技术支撑业务，主备之间 ADG 实现1000公里以上的数据灾备，备库同时承载查询的读写分离职责。主库还通过 OGG（Oracle GoldenGate）复制软件，对数据库的数据实时复制到 ETL 环境。

这是 Oracle 全堆栈的典型架构实现，RAC 实现集群、ADG 主备读写分离、OGG 复制、Exadata 底层硬件支持。

8. zData

云和恩墨今天也提供了分布式存储解决方案，一体机架构，称为 zData，和 Oracle Exadata 架构类似，底层通过 PC 服务器和 Flash 存储加速 I/O，100GB IB 网络提供高吞吐带宽，3个存储节点轻松实现超过 8K 块大小100w iops 的处理能力。这个架构在很多客户处实现了超过10倍的性能提升，我们的客户包括青海移动、四川电信、太平保险等行业客户。

9. 双活与 Extended RAC

既然我们已经提到了 Oracle 的集群技术 - RAC，主备的容灾架构 - DataGuard、ADG，那么我们必须提一下扩展 RAC - Extended RAC。

如果能够在高可靠的网络中，将 RAC 的不同节点分不到不同的数据中心，那就可以实现真正双活的扩展 RAC 集群。图例是我们的一个客户，将 RAC 的4节点，部署在两个相聚50Km 左右的数据中心。

由于很多用户的灾备多数处于备用状态，在真正灾难来临需要切换时可能并不可用，双活看起来是更好的解决方案，但是扩展 RAC 对于网络要求很高，近年来的真正用户实践才慢慢多起来。

10. 多租户与分区

既然硬件能力提升了，Oracle 希望能够推动用户将以前分散建设的数据库整合起来，同时为了更好的适应云的数据库支持，Oracle 在12c中改写了数据库架构实现了多租户的特性。

在多租户特性中，每一个以前的独立数据库，都可以作为一个子集 - PDB（Pluggable Database) 加入到一个容器中来（CDB - Container）。但是对于外部使用，甚至在这个容器中，这个PDB看起来都是一个独立的数据库，如果在云上实施，每个用户只需要一个 PDB 的子集就够了。

数据库的分分合合，Oracle 希望企业级用户可以基于多租户的特性去实施数据库整合。这是 Oracle 12c 最重要的新特性之一。

从数据存储的微观来看，当数据容量增大之后，为了提高查询性能，很多时候架构上的一个重要考虑就是分表，通过特定条件将数据拆分开来，比如按照时间、地域等等。

在 Oracle 数据库内部支持一个分区特性，可以在同一个数据表中实现数据分离，通过多个存储段来存储满足特定分区条件的数据，从而实现数据分片。

11. 分区案例

这是一个我优化的案例，当时用户系统中存在一张典型日志表的查询，占用了系统20%的逻辑读，为了解决这一问题，我详细的分析了所有访问该表的 SQL（之前用户评估并不适合分区），针对查询谓词汇总，并测试所有典型的 SQL，评估其分区前后的性能改变，针对性的进行微调。

针对现有业务系统的调整优化始终面临一个挑战，就是：如何保证调整对于所有应用都产生正向的影响。毫无疑问详尽的测试必不可少，Oracle 有一个功能称为 RAP - Real Application Testing，可以捕获生产系统负载，在变更后的系统上重演，以验证其性能改变。

经过详尽测试微调之后，这个数据量大表被实施了分区，其效果是影响这个系统20%左右的逻辑读几乎被全部消除。这是分区可能带来的查询数据剪裁，缩减 I/O 访问带来的性能改善。

12. Sharding

可是在一些对性能要求极高的环境下，很多用户还是想要 Sharding，NoSQL 的 Sharding 多美啊？

通过 Shard，将数据分离开来，不同分区只存储一部分数据的子集，应用被设计成按照条件去访问特定数据库分区。MySQL 在分库分表的条件下也经常被如此使用。

这是淘宝当年去O的中间态，也可以作为借鉴。淘宝是逐步将 Oracle 中读密集的数据表，分拆出来分布到大量的 MySQL 上去，MySQL 又通过主从来保证高可用性。事实上这也是读写分离的实现。

但是这样的分布架构，数据割裂开，带来好处的同时也必然带来应用的复杂性，应用需要通过一种方式路由到需要的数据库上，淘宝的 TDDL 是变革过程中随之出现的产品。

今天 Oracle 的重度用户，也有将读分离到 MySQL 的案例。这个架构作为生产态在今天也依然存在。

可是很多 Oracle 用户数据量还是会很大，并发还是会很高。

Oracle 在即将发布的12.2版本中，也将发布 Sharding 的新特性，将 Oracle 数据库的底层存储彻底拆分开来。现在你也将拥有一个分布式的 Oracle 数据库了。

如果你想将集中式的存储分开来，Oracle 数据库也会满足用户的需要。这一特点是在 Oracle 分区技术上，以前的分区基于数据库内部实现，现在可以基于数据库级别实现跨越数据库的分区。

当然数据实现了分片，就存在数据访问上的路由。Oracle 通过 Shard Directors 和 Coordinator 数据库实现路由。

13. GDS

我们可以想象，当原来后端一个数据库被分离成数十、上百甚至上千个数据库后，应用的连接管理也会成为一个难题，Oracle 为此开发了一个 GDS 产品。用于实现数据库的连接管理，诸如主备切换等功能都可以由这一层次接管。这一产品已经随12.1版本发布了。

14. Sparc

Oracle 的变化不仅如此，在过去几年，在内存数据库选件上，Oracle 投入了大量的研发，并成功推出了 In Memory Option，将内存数据库嫁接到 Oracle 数据库之上，以列式存储改善 OLAP 的性能；并且进一步的，将 IMO 的部分查询算法下落到 CPU - SPARC M7 处理器上。

这些改变使得 Oracle 仍然具备几乎无敌的 RDBMS 性能。

所以 Oracle 今天的策略是，依托强劲的硬件支撑，推动用户进行数据整合（Oracle Database 12c Multinent 多租户特性，可以在数据库内部实现隔离），通过 IMO 内存列式存储加速使 OLTP、OLAP 共存。一统关系型数据天下，一个数据库包罗万象。

15. Cloud

可是云的时代还是来到了数据库领域，Larry Ellison 连续两年在 OOW 大会上总结，Oracle 在云上持续革新。

由此可以看出，Oracle 向云上转型的决心。2015年 Oracle 宣布和腾讯合作在中国落地其全球的第20个数据中心，可以看到 Oracle 在公有云上的发力和速度，公有云也将改变 Oracle 数据库的使用方式。

毫无疑问，云也会改变数据库的运维方式，我一直认为那 3.03% 的性能问题是最有含金量的部分，根据经验这部分问题多数来自 SQL 开发编写不当。

在 DevOps 的时代，运维和开发紧密的结合，推进产品质量的改善，是架构师和 DBA 共同会涉及的职责方向之一。

16. DevOps 之 Z3

DevOps 需要自动化的工具和产品，为此云和恩墨开发了一款 SQL 审核工具 - Z3，其原理就是在开发测试阶段筛查 SQL，找出性能隐患，将性能问题消灭在上线之前。

我认为这是运维和架构最有价值的部分。

17. Team

最后向大家介绍一下云和恩墨的专业团队。

我们这些年做的另外一件事，就是找到行业里最懂数据库的一些人，将大家聚集在一起，为用户基于产品提供好的服务和解决方案。您也看到了，我们已经开始到国外找专家了，右上角这位，是我们从国外招募来的 Oracle ACE 总监。

我们也有自己的产品，监控、优化、SQL 审核、分布式存储管理软件，总之围绕数据为用户打造最佳的用户体验。给我们一个数据库，我们就有信心通过优化让性能翻上几番；给我们一个崩溃的数据库，我们就有信心将其拯救回来。

这就是我们在做的事。云和恩墨今年的员工招聘人数是100人，我们求贤若渴，大家有兴趣的可以和我联络。

18. 二维码

最后是我个人的二维码，欢迎大家关注。

云和恩墨

数据驱动，成就未来。整合业界顶尖的技术与合作伙伴资源，围绕数据及相关领域，提供解决方案和专业服务。

IT基础架构

zData一体机 - 分布式存储解决方案

数据架构

Oracle DB2 MySQL NoSQL

专项服务：架构 | 安全 | 高可用 | 容灾 | 优化 | SQL 质量管控

| 整合 | 升级 | 迁移 | 灾难恢复

运维服务：运维服务 | 代维服务

人才培养：个人认证 | 企业内训

软件产品：SQL审核 - Z3 | 监控 - Zone | 数据恢复 - ODU

应用架构

应用软件开发：数据建模 | SQL审核和优化 | 中间件服务

业务架构

电子渠道（网络销售）分析系统 | 数据治理

恩墨学院

恩墨学院是云和恩墨(北京)信息技术有限公司旗下的培训事业部，创业数年专注于数据库认证、技能培训，以专业的讲师塑造品牌，以专业的训练保证就业，目前已经发展成为国内数据库领域培训领导品牌。