1.3 在Oracle的世界里
如果你是一位Oracle数据库的使用者，那么我们说你将是立足在Oracle的世界里的。本书的主旨也是以此为出发点，立足Oracle的世界，以海纳百川的胸怀选择性吸收各种数据库的使用。
立足点的不同，同样会影响到我们视角不同，那么在Oracle的世界里的高并发数据库系统架构设计将会是怎么样的呢？这也将是本书需要给读者们介绍的。
相信在每一个Oracle数据库用户的眼中都有其独特的风景，对Oracle的理解可以是技术的，更可以是艺术的。在讨论中，我经常提及的一个观点：“将技术的东西当成一种艺术去做，那你将不再是简单的技术者，而是更富创造力的艺术家。”
1.3.1 数据库森林体系
在这里，我们也不妨东施效颦一回，模仿经济学里的“布林顿森林体系”，架构一个属于数据库领域的“数据库森林体系”。
数据库森林体系，是指以Oracle数据库为核心的多种数据库集群工作的生态体系。该体系的特点应该是：
应用系统核心内容和性能直接与Oracle数据库挂钩；
其他类别和功能的数据库与Oracle核心库挂钩；
其他类别和功能的数据库与Oracle数据库按业务需求实现数据同步与交互；
其他类别和功能的数据库作为Oracle核心库的扩展，分摊前端或外围业务支持。
图1-5所示为一套比较完备的数据库森林体系架构图。秉承以Oracle核心库为中心，从业务逻辑层面、数据库功能层面两个维度展开纵横方向的扩展。
Oracle核心库与Oracle子系统库、MySQL子系统库之间，使用GoldenGate实现即时的数据同步，MySQL子系统库是单向同步，它的角色更像是一只伸出去的手，处理前置业务。
Oracle核心库与灾备库之间通过Data Guard功能实现异步同步，起到灾难备份的作用，特殊情况下，也是可以临时打开使用的。
同样，在核心库与ADG库、T-1交易库之间也是通过Data Guard功能实现数据同步。ADG库可以看成是核心库即时的映像，服务于只读业务；T-1交易库则可视为过期的核心库映像，可以给时效要求不高的业务提供读写服务。如果必要的话，通过ADG库衍生出一些开源数据库的业务应用，就像伸出去的另一只手，处理前置业务。
对于前面提到的Oracle核心库的高并发热点争用问题，可以将这部分业务分离到前置的TimesTen内存数据库中，提高高并发会话的响应速度，其可通过TimesTen提供的方法和接口实现与Oracle核心库的即时数据同步。
当然，数据库森林体系也可以视为一种高并发热点争用问题的解决方法论，不要求全盘实现，可以选择性地搭建，满足了需求就是最佳的架构设计。
说到高并发处理能力的提升，就会不只一次地被问及Oracle数据库的RAC架构。我只能说RAC只是一种高可用的解决方案，对于高并发问题，它未必擅长。高并发热点问题，往往成了它的短板，RAC环境甚至会加剧问题的影响程度。举个例子来说，我们将会在高效索引设计章节提到的高并发会话导致主键索引分裂的等待事件——“enq：TX-index contention”，如果这个问题不先解决掉，从单节点到RAC的迁移后，问题将更加显著。
从历史来看，国人好像都很喜好RAC数据库架构，并无形中夸大了RAC数据库的作用，集高可用、高可靠、高并发、高性能的光环于一身。RAC一度风行的时候，技术人员如果不会RAC都不好意思说自己是Oracle数据库的DBA，公司如果没有RAC数据库都不好意思说自己的业务量大。这和前面提到的盲目夸大去IOE的现象是一样的，光环效应是要不得的。
然而，RAC确实也是一个不错的东西，如果在节点应用之间尽可能地实现了业务的独立，也就是说按节点完全区分业务应用，其处理并发的能力是有一定的优势的，但是是在解决了数据库结构分散的前提下。
为什么这么说呢？我们知道不论是RAC数据库还是单节点数据库，物理存在的数据库只有一套，如果数据库内部实现了业务逻辑上的必要隔离，各节点就能各行其道，反之，各节点的争用会更加剧烈。与其纠结在这个问题上，不如跳出来看问题，为什么不干脆将其按业务逻辑拆成多个库呢？必要的共享数据，可以通过即时同步来实现。
如图1-6所示，在左边RAC架构中，实例1对应业务1，有其独有的数据部分，实例2对应业务2，也有其独有的数据部分，两种业务有一定的关联性，所以还存在共享数据部分。演变成右边的架构，将其拆分成两个独立的单节点数据库，其中数据共享时效要求较低的进行数据库间即时同步，时效要求很高的冗余到各自业务数据库中。这样做虽然数据库的总容量大了，但是架构简单了，少了内存的即时同步，业务并发处理能力也提高了。回过头再来看一下我们的数据库森林体系，核心库、子系统库以及各种功能库，不就是数据库按业务逻辑拆分的结果吗？
近年来，大家也能更加理性地看待RAC数据库架构了，与其面对额外的采购成本和运维成本，不如干脆拆开来，用简单的架构来取而代之，这也正是大道至简的精神。
我们说高并发处理未必是RAC的强项，但高可用就一定是了。当一套数据库应用系统提出如下需求的时候，我们将毋庸置疑地给出RAC的解决方案：
业务7×24小时在线；
尽可能短的故障停机修复时间，10分钟以内、5分钟以内，甚至更短。
1.3.2 大道至简
在此我们不得不先提到一个概念，就是数据库架构师的“术”与“道”。业内很多数据库架构师往往是技术水平比较高的DBA的升级版，这是一个比较典型的以“术”为导向的结果，一切以技术说话，这往往造就了架构的局限性，甚至凡事唯技术论。好比很多项目在制定目标的时候，会把某项新技术的实现作为目标之一，造成驴唇不对马嘴的后果。一个成功的数据库架构师应该是以“道”为导向，那何为数据库架构师的“道”呢？在这里我先卖一个关子，将在本书的第9章中展开讨论。
我曾经在一次技术沙龙上跟几位朋友讨论过一个话题：如何看待数据库五花八门的新特性呢？当说起需求是高并发处理的数据库的时候，大家达成一种共识，就是架构需要设计得充分简单，简单了才能灵活地扩展，对于一些不熟悉或者没有实战经验的新特性，可以不用就不要用。
然而，设计简单的架构并不意味着架构简单的设计，越是简单的东西越是考验设计者的思想，需要对简单的东西充分细化。立足在Oracle的世界里，有哪些是至简而至要的东西呢？就是数据库森林体系中蕴藏的设计的大道。
数据库森林体系看似复杂的架构背后，至简的大道无外乎就是对表、索引、优化器设计的把握，以及以核心库为中心的功能数据库与前置数据库的纵横扩展。本书将分作两个部分，对这两项内容具体展开阐述，其目的不在于帮助读者解决某个具体的高并发问题，而是旨在分享一种方法论，开辟一种思路。或许你在阅读的时候能够得到一点启发，演化出更高明的观点，那么我写作本书的目的也就达到了，也正是我的大道。