网志栈编辑推荐
；
（1）中国平安保险集团拥有10余年数据库从业经验的资深数据库架构师撰写，盖国强等多位业内数据库专家联袂推荐
（2）秉承大道至简思想，从内部扩展、横向扩展和纵向扩展3个维度对架构与设计高并发Oracle数据库系统的思想、方法、核心技术进行深入讲解和剖析
（3）国内首部讲解内存数据库TimesTen的专著
；
内容简介
这是国内第一本深度讲解如何架构与设计高并发Oracle数据库系统的著作，也是国内第一本系统讲解内存数据库TimesTen的专著。作者是拥有10余年Oracle从业经验的资深数据库架构师，本书的内容也得到了业界以盖国强为代表的数位数据库专家的一致认可。本书秉承大道至简的思想，技术与艺术并重，从技术、方法论、原理和思想等角度讲解了如何架构与设计高并发Oracle数据库系统。
全书主要内容从三个维度展开：首先是内部扩展的维度，深入探讨了高效B树索引、高效表设计、查询优化器等数据库架构设计与优化的核心技术，以及高并发Oracle数据库系统架构与设计的方法论和常见的高并发案例；其次是纵向扩展的维度，国内首次详细讲解了内存数据库TimesTen的基本使用、高可用架构设计、缓存应用、监控方法、数据备份与恢复、数据迁移以及高并发场景；最后是横向扩展的维度，详细讲解了如何使用GoldenGate构建数据库群，重点是结合链路原理的实现，介绍了拓展数据集成平台和异构数据库群的设计思路。此外，还从容灾和高并发的角度介绍了Data Guard的妙用，以及超出纯技术范围的一些*实践。
作者简介
侯松（网名：麻袋爸爸）
资深数据库架构师、PMP、北美寿险管理师，现就职于中国平安保险集团，拥有10余年数据库开发、管理和运维经验。精通Oracle数据库相关技术，掌握ITIL运维体系，擅长金融行业（银行、保险、投资）的项目管理和数据库系统的架构设计，有世界500强IT团队管理与大型项目管理的经验。活跃于ITPUB等技术社区，2013年中国数据库大会演讲嘉宾。个人网站：http://www.housong.net
；
目录
推荐序一
推荐序二
前言
第一部分 内政篇
第1章 大道至简
1.1 初见高并发
1.1.1 从一次谈话说起
1.1.2 问题就在那里
1.1.3 你不是一个人在战斗
1.2 说句时髦话
1.2.1 谈谈去
1.2.2 开源的作用域
1.3 在Oracle的世界里
1.3.1 数据库森林体系
1.3.2 大道至简
1.4 本章小结
第2章 高效B树索引
2.1 索引扫描识别
2.1.1 B树索引
2.1.2 全表扫描
2.1.3 ROWID扫描
2.1.4 索引唯一扫描
2.1.5 索引范围扫描
2.1.6 索引全扫描
2.1.7 索引快速全扫描
2.1.8 索引跳跃扫描
2.1.9 索引组合扫描
2.1.10 索引联立扫描
2.2 索引与排序
2.2.1 B树索引内部结构
2.2.2 输出排序
2.2.3 降序索引
2.2.4 聚合查询min()与max()
2.3 索引设计优化
2.3.1 索引选择度
2.3.2 数据分布的影响
2.3.3 索引聚簇因子
2.3.4 数据存储的影响
2.3.5 复合索引
……
第3章 高效表设计
第4章 查询优化器
第5章 常见高并发案例
第二部分 纵横篇
第6章 TimesTen内存数据库
第7章 GoldenGate构建数据库群
第8章 Data Guard的妙用
第9章 最佳实践 ；
媒体评论
在如今高压力、快节奏的工作状态下，作者能坐下来将自己的经验编写成书分享，让我报以深深的敬意。该书基于Oracle基本架构体系和TimesTen内存数据库架构体系，拨开各类潮流技术的迷雾，大道至简，艺术性地向读者阐述了高并发数据库设计中需要关注的内容，很值得静下来心来研读和体会。如果你正在为设计一个复杂的系统架构而费神，或正在为选择一项新技术应用而犹豫，这本书提供的方法论，无疑会给你带来极大的帮助。
——何月华 中国太平系统规划经理
与作者相交多年，深知其在数据库架构设计方面的过人造诣，当得知作者要出书之时，为之高兴的同时也是非常期待。在2013年DTCC大会和OOW大会上，作者与我多次就TimesTen内存数据库技术进行探讨，如今在其新书中有了非常详尽地介绍，凝聚了作者自身实践经验，颇为难得，且介绍TimesTen的书籍在国内也尚属首本。全书从Oracle内政讲起，到纵横扩展的实践，无不透露出作者的独到之处，堪称数据库架构设计方面的典范之作。
——杨志洪 Oracle ACE，上海新炬技术总监
一直以来，ORACLE管理、开发、优化类书籍在市场上，总是让人眼花缭乱。然而，却很难找到一本专门讲解应对高并发应用的ORACLE数据库系统架构与设计的书籍。侯松兄这本书的面市，真是让人欣喜不已，仔细研读，可以让你了解到一个大型高并发系统，在ORACLE数据库架构方面需要的相关技术。值得注意的是，这本书不仅立足于技术，还有很多技术之外的方法论与经验之谈。我相信，读完此书，你会受益匪浅。
——丁俊(dingjun123)，ITPUB ORACLE开发版资深版主
《剑破冰山--ORACLE开发艺术》副主编
以艺术之心打造架构之美，本书浅品之下，颇感独具匠心，作者以大道至简为主导思想，从Oracle内部优化到纵横扩展，只阐述核心内容，并以此来激发读者的思考。书中关于TimesTen和GoldenGate的介绍更是让人眼前一亮，不仅有助于传统行业数据库架构设计，对于互联网电商的应用也有着相当的指导性，是非常值得一读的数据库架构设计读本。
——韦连友 一号店数据部经理
；
免费在线读
第一部分
内 政 篇
万物之始，大道至简，衍化至繁。
——老子，《道德经》
第1章
大 道 至 简
万物之始，大道至简，衍化至繁。世间一切事物在刚刚开始的时候，都是非常简单的，是为大道，随着事物不断地发展，其衍变出来各种复杂的局面。然而，追本溯源，仍然会发现复杂局面下真正在左右事物的还是那些最基本的东西——大道。如果能牢牢把握住这些被认作是“大道”的东西，再复杂的局面也自然会变得简单。
近些年来，在数据库领域里，可谓群雄逐鹿，志在中原。他们各自有各自的特色，相互间也甚是喜欢用自己的长处去比较对手的短处，以彰显其产品的优势，眼花缭乱的测试结果和市场评价，其局面之复杂就像将要开启一个新的时代。不论是作为研发者还是用户，这样的竞争无疑都是一件好事，但也要求我们需懂得把握其中的大道。
为什么会有如此多样的数据库在市场上竞争呢？当然是市场需求在推动的，而需求的本身则源自于各行业的业务系统应用。如果说未来会开启一个新数据库时代，那很好。然而，现在无疑还是RDBMS的时代，其中的佼佼者无疑还是Oracle数据库。
本书将秉承大道至简的主导思想，立足于Oracle的数据库相关技术，给读者展示一套高并发业务系统的数据库架构设计方法论。
1.1 初见高并发
高并发这个概念并不新鲜，可以说有数据库的地方都有可能面临高并发的问题。在数据库里，高并发问题主要集中在两个方面：读的高并发、写的高并发，两者看起来都不是很复杂，然而实际情况往往是读和写会交织在一起，并同时呈现出高并发的问题。
这个时候，相信很多读者都会提出一个观点：做读写分离嘛。是的，这是一个不错的主意，但只是一个治标不治本的主意。业务系统的耦合度很高，是不可能实现业务层级的读写分离的。在架构设计的过程中，不能驻足于技术层面，还是需要渗透到业务层面去的。不论是业务驱动技术，还是技术驱动业务，两者都是不能分离开考虑的，比较好的做法应该是，在两者之间形成一种平衡，当然这是需要架构师的分析能力和沟通能力来加以驱动的。
1.1.1 从一次谈话说起
应用架构师：“哥们！还记得上半年让你们帮忙做的一次数据库容量测试吗？”
数据库架构师：“当然！我们可是费了很大的工夫才完成的。”
应用架构师：“当时不是说我们在现有的硬件条件下，数据库的容量足够承受当时4倍业务压力吗？可是下半年我们的业务量才增长了0.5倍，怎么就不行了呢？”
数据库架构师：“从系统资源利用率的报告来看，CPU、内存、I/O、网络上都没有太大的压力。但是，在业务高峰时段，CPU出现短暂冲高的现象。”
应用架构师：“没错！在应用端可以看到出现用户阻塞，中间件上的连接持续增加，没有得到及时释放。”
数据库架构师：“嗯，那是数据库未能及时响应造成的。CPU冲高，通过监控，我们发现很多并发的会话在争用一些资源，比如数据块、索引块、Latch和Mutex。表现出很多等待事件的冲高。”
应用架构师：“我想我们遇到高并发争用的麻烦了。”
数据库架构师：“是的。当初这套系统的设计，预期到现在这么大的业务压力了吗？”
应用架构师：“谁也不会有这种先见之明吧？当初只是一种业务的尝试而已，谁能想到市场的反应会那么好！从数据库层面来看，有什么好办法吗？毕竟现在的问题出在数据库上。”
数据库架构师：“办法是有的，针对性地一一解决掉。但是，这总归是治标不治本的办法。就像治水，现在压力我们堵住了，如果压力再大一些呢？我需要你的帮助。”
应用架构师：“你是说业务架构的变更吗？小变化没有问题，但是要像互联网公司那样大改，肯定是不行的，我们接受不了这么大的变化。”
数据库架构师：“是的，变革对我们来说，成本太大，小帆船掉头容易，航母掉头可能就要出事情了。”
应用架构师：“我们最近在开发消息队列，能一定程度上缓解用户的高并发压力。但这是以牺牲用户体验作为代价的，终归不是太好的办法。”
数据库架构师：“我想我们可以学习大禹治水，堵不上，就疏通。先将一部分业务压力分离出去，在子数据库和主数据库之间即时同步必要的数据，同时适当冗余数据到子数据库，减少数据库之间的交互。”
应用架构师：“是个好办法，我们现在不就是这么在做的吗？问题不还是在那里吗？”
数据库架构师：“我想是的。因为业务热点过于集中，在数据库上这部分业务数据耦合度又非常高，没有办法做到有效拆分。”
应用架构师：“这不奇怪，我们的业务逻辑的复杂程度不是互联网应用可以比拟的，没办法像他们那样去充分地解耦。但是，我们是否可以学习他们使用廉价MySQL数据库代替Oracle数据库，这样业务分离的成本就低了很多。”
数据库架构师：“你确定这样的成本会低吗？Oracle数据库的开发人员真的会开发MySQL吗？我们的业务逻辑是很难在MySQL数据库上实现的，现在Oracle数据库帮助我们完成了大部分的数据耦合，如果使用MySQL，这些都将要在应用端完成，开发成本将会增加。另外，Oracle有强大的优化器机制，开发者写得不算太好的SQL，它也能包容，MySQL则不然了，SQL写得不好，马上给你颜色看，因为它的优化机制不能跟Oracle相提并论。与Oracle相比，MySQL只能作为一个数据容量来看待。”
应用架构师：“你说的这些我也明白，但是我们的数据库是应该架构扩展了吧？”
数据库架构师：“当然。虽然我们不能做到充分的数据解耦，但是一点一点地解还是可以的吧。我们现在的问题是解决高并发问题，而高并发集中的那部分业务就是我们的目标。”
应用架构师：“那部分业务很难弄哦。读写比例为5∶1，写操作占比还是蛮高的，而且都交织在一起的。最大的问题是要保证较快的响应速度，否则高并发压力就会积压。”
数据库架构师：“内存数据库！将其作为Oracle数据库的前置缓存数据库来加快响应速度，如果保证了快速响应，高并发压力也就解决了。眼下Oracle和SAP都在内存数据库上大做文章呢。”
应用架构师：“他们都是在搞OLAP的内存数据库吧，我们的可是OLTP。”
数据库架构师：“Oracle的TimesTen就是为了解决OLTP的并发问题而研发的哦。关键是看我们的应用是否适应得了。”
应用架构师：“嗯，是多样化的数据库架构了。”
数据库架构师：“是的，就像一套数据库生态体系，没有必要特别待见谁，也没有必要特别排斥谁，关键是看应用的需要。不过，我们也需要反思一个问题，就是当初Oracle的设计阶段没有预见性，应该从Oracle内部设计先把握好，加强其处理并发的能力。是谓：‘先修内政而后纵横。’”
1.1.2 问题就在那里
看过冗长的对话，我们来总结一下吧，问题到底出在哪里？
Oracle数据库架构设计之初，粗放设计，没有充分把握细节；
业务数据耦合度过高，无法充分解耦，革命性的变化成本太高，不能接受；
业务逻辑比较厚重，灵活性不高；
可以接受架构创新。
以上问题，相信很多架构师和数据库管理员们都会面临。更多时候，我们都是无力去推动业务的，让业务适应技术，一直都是技术人员美好的愿望，却鲜有实现。现实一点地来看，我们只能在一定程度上去引导业务，但不能完全让技术去适应业务，两者需要达到一种平衡。
立足于大多数的传统行业，来看一看应用的现状吧。业务逻辑都是经年累月沉淀下来的，要想做出革命性的变化确实很难，除非行业革命。谁能想象一下，让银行去拆分核心逻辑呢？业务看似刁难的要求，也蕴藏着行业的特点，架构师是需要充分认识到这一点的。
如图1-1所示，理想情况下的应用系统架构中的子系统应该是相对比较独立的，子系统之间关联较少，而且相互关联的子系统数量相对较少。实际情况往往是大相径庭的，子系统之间存在很高的耦合性。子系统内读写错综复杂，基本上不可能实现读写分离。面对这样的现实，出于成本和风险的考虑，很难做到子系统的解耦，理想情况也只能是理想了。
业务子系统与数据库的对应关系，如图1-2所示。在一套完整的数据库生态体系中，子系统和数据库也是无法独立开的。理想情况是若干子系统分布在一个数据库中，数据库基本上是自包含的。现实仍然是残酷的，往往是子系统和数据库出现多对多的关系。
那么，数据库架构设计就需要反映这样的业务架构，如图1-3所示。对于某一系列的业务应用来说，是不可能通过单个数据库来实现的。需要的是一个数据库群，其中包含核心库、业务应用库，以及各种功能的库，根据重要性做层级划分。数据库之间实现即时的数据同步，构成一套完整的数据库生态体系。
做到这些是不是就解决问题了呢？当然没有，如果解决了，也不会有以上那段对话。但是，这种架构的演化方向是正确的，将错综复杂的业务分为治之，如果某些业务上出现了很高的并发压力，也不会影响到其他业务的应用，还可以将影响面控制在最小范围内。
虽然本次在架构建模阶段没有充分考虑到Oracle数据库的细节问题，但是也可以作为一次经验教训，为下次的建模工作提供指导。可喜的是，我们也不必坐以待毙，架构的创新始终都是受欢迎的，因为这意味着数据库的并发处理能力的提升。
图1-2 子系统与数据库的对应关系 图1-3 数据库生态体系架构
从技术层面来看待以上的问题，我们可以去做好两件事情：
Oracle数据库架构设计工作细化；
以Oracle数据库为中心，开展架构纵横扩展。
1.1.3 你不是一个人在战斗
对于现在的企业级应用系统来说，数据库一般不会成为一套系统的瓶颈所在。数据库出现高并发问题往往都是热点业务集中争用造成的结果。为什么这么说呢？因为现在的数据库应用中，不论是Oracle数据库，还是MySQL数据库，抑或其他新型数据库，它们都不是一个人在战斗。
如图1-4所示，在一套比较完整的应用系统架构体系中，一般可以分为四个大层级：
应用层：直接服务于最终用户的，完成用户行为的交互。
网络层：后台处理的第一个层级，实现网络路由，并通过网络负载均衡器实现第一次负载均衡，使高并发压力第一次得到分流。
中间件层：就是通常说的B/S架构的中间服务器层，其接收网络层来的用户连接，并实现第二次负载均衡，所不一样的是，网络层是通过硬件实现负载均衡，而中间件层是通过软件实现的。同时，其按照一定的逻辑配置连接数据源。
数据路由：隶属于中间件层，是数据库层的一个前栈，实现分布式数据存储的路由。一般来说，若数据库使用分布式存储，则这个组件都是不可少的。
数据库层：这是我们最关心的，也是最底层的结构，可分为核心数据库层和前置数据库层。
核心数据库层：传统意义上的数据库群所在的区域，我们按照不同的功能应用，区分不同的数据库存储，包括核心库、子系统库、灾备库（可细分为远程灾备和本地灾备）。如果业务扩展，则可以通过ADG库和T-1交易库实现部分业务的分离，这两个概念我们会在“纵横篇”详细介绍。
前置数据库层：这个层级可以部署在核心数据库层的前端，也可以平行部署。其另一种叫法是“数据库中间层”。可以部署一些内存数据库，分离高并发业务到这个区域，也可以部署一些开源的数据库，分离边缘化的应用于其中。
图1-4 系统架构概要图
可以看到，一个完整的架构远比我们想象得要复杂，云的概念也是基于这个架构逐渐衍生出来的。就拿数据库层来说吧，我们平滑地实现数据存储的横向和纵向的扩展，并对上一层级是透明的，那么我们就实现了数据库的池化，也就是说对外服务的数据库可以视为一个，基本上实现了数据库云架构。
从以上架构来看，高并发的压力经过了网络层和中间件层的过滤，到达最底层的数据库层，基本上都不会有压力了，应用层、网络层、中间件层都可以视为数据库的保护层。当我们进行应用系统压力测试的时候，绝大多数情况下，数据库都是没有太大压力的，最容易出现问题的往往是中间件层，换而言之，在数据库被压垮之前中间件层已经被压垮了。这也提醒我们只做系统应用压力测试是不够的，我们还需要做数据库的压力测试，找到数据库层的瓶颈所在。
这样是不是可以就此高枕无忧了呢？当然不能，数据库出现高并发压力在实际应用中还是比较常见的。难道我们前面说的不对？不是的，可以看到不论是网络层，还是中间件层，都是在分流压力，压力并没有凭空消失，这些用户会话要访问的数据分布是无法控制的，如果分布过于集中，那么数据库会在某一个点上出现高并发争用，也就是热点争用，如上述谈话的背景一样。
面对高并发压力，我们现在已经很清楚自己要做什么了吧？就是一定程度上实现数据访问的分流工作，也就是通常所说的纵横扩展。另一方面来看，任何的扩展都是有一个核心点的，就是我们的Oracle数据库，扩展工作在一定程度上是对其核心地位的弱化，但是核心仍然是核心，在扩展之前，必须做好Oracle核心库的设计。
1.2 说句时髦话
活在当下，对于IT人来说，是再合适不过的说法了。IT行业的发展速度堪比高铁、火箭，每一个IT人都在担心自己的知识领域明天就要过时，不得不每天学习新的知识，无奈的是跑得再快也没有办法追得上火箭。
在数据库的领域里，也是时刻都在出现新概念和新产品。创新，成了每个人、每个企业都在不断追逐的东西。现有的东西，做好了是应该的，做不好要接受惩罚；创新的东西，做不好是应该的，做好就是绩效。当创新和KPI绩效直接联系到一起的时候，大家都不再是为了创新而去创新，而是为了KPI而去创新，甚至出现了微创新的说法，可以是一种方法的引进，或者一种新数据库的引进。然而，创新这东西是由需求来驱动的，人家的需求未必是我们的需求。人家的创新就像人家的衣服，人家穿得很漂亮，我们拿来穿可能就很别扭了。
每个行业都有一到两个领军的企业，他们在做什么，同行业的人就跟着做什么，我也是经常被同行们问起最近在做什么，如何做的。同行业的借鉴和学习当然是好事，但也要考虑到自身的现实条件，不要在数据库总容量只有几个TB的时候，就非要去搞什么大数据。
由于市场利益的驱动，很多企业也开始跨行业发展。为了能够快速地融入并占领不熟悉的行业领域，不惜生搬硬套该行业已成型的东西，由于急功近利而缺乏沉淀，直接导致东施效颦的结果。更有甚者，不分良莠，言必称希腊。
1.2.1 谈谈去IOE
去IOE，具体不知道从什么时候开始，在数据库领域里掀起了一波不算大也不算小的浪潮。是赞是贬，是喜是忧，一半一半。
去I：就是废弃以IBM为代表的高价小型机；
去O：就是废弃以Oracle为代表的集中式数据库；
去E：就是废弃以EMC为代表的高端存储设备。
废弃这些高端大气上档次的东西，取而代之的是使用开源的软件。暂且不说开源软件的优缺点吧，先来看看为什么要去IOE呢？不说始作俑者是何用意，后来者更多的是一种盲从跟风的心态，正如前面所说的一样。下面我们从两个维度来分析一下看看吧：
1.?以公司为中心
去掉了IOE确实能给公司节省下不少的硬件成本，但如果你就此简单地认为IT成本降低了，那就错了。这部分节省的硬件成本将转化成软件成本附加到IT开发和运维上面。这些软件成本将包括以下几个方面。
开发运维人员再学习和再培训的成本，如果公司不打算把原班人马全部开掉。
数据库开发运维的成本将增加，且不可控。开源数据库的开发运维和Oracle数据库的开发运维是完全不同的，Oracle数据库有强大的优化机制，让一些不算太好的SQL也能表现得不错。开源数据库则不然，需要更多人力投入到优化开发和设计中。不幸的是，这就像一个无底洞，谁也不能预估将需要多少人力成本的投入。
开发运维风险增加，且不可控。使用开源的东西，意味着失去专业厂商的支持，什么问题都要靠自己解决，万一解决不了就只能等死。
面临成本和风险的不可控，需要稳步发展的企业是否还值得选择去IOE呢？如果说出于战略考虑，可以不用受制于IOE，那么就算去掉了，不是还要受制于PC Server吗？同时，系统的开发运维更加依赖于技术人员，不是更加受制于技术人员吗？
2.?以技术为中心
以技术为中心，也就是以技术人为中心。我记得我曾经在一次IOE的话题讨论中问过一个问题：“谁愿意在情人节跟女友出去约会的时候，突然被叫回来处理故障呢？谁愿意在陪孩子亲子活动的时候，突然被叫回来处理故障呢？”
如果去了IOE，就失去了专业的服务支持，这些都将变成可能。当然，热衷于以公司为家的技术人不在讨论范围内。
客观地来说，每一种技术、每一种产品都有其作用的领域，没有万能的数据库，也没有万能的架构，只有万变的需求和随机应变的设计。IOE有其广阔的作用域，也有其不擅长之处，成熟的设计应该是用其所长，避其所短，不走极端路线。
；
高并发Oracle数据库系统的架构与设计(国内首部讲解内存数据库TimesTen的专著，从内部扩展、横向扩展和纵向扩展3个维度对架构与设计高并发Oracle数据库系统的思想、方法、核心技术进行深入讲解和剖析) pdf下载声明
本pdf资料下载仅供个人学习和研究使用，不能用于商业用途，请在下载后24小时内删除。如果喜欢，请购买正版
pdf下载地址
版权归出版社和作者所有，下载链接已删除。如果喜欢，请购买正版！
