让Oracle跑得更快2—基于海量数据的数据库设计与优化

ITPUB技术丛书 

让Oracle跑得更快2—基于海量数据的数据库设计与优化 

谭怀远著

ISBN 978-7-121-13921-5

2011年7月出版

定价：69.00元

16开

452页

宣传语：国内第一本以作者10年的工作经历打造的

        基于海量数据的数据库设计与优化的书籍

内 容 简 介

数据库设计，是最近几年才出现的技术领域，再早的时候，数据库是以一个黑盒的方式，附属到某个系统当中的，开发人员对它的关注非常少。

近年来，由于很多系统数据量呈几何级数激增，各种性能问题日益凸显出来，而这种性能问题绝大多数都落在了数据的载体—数据库身上，因此，人们越来越关注数据库的性能。而一个数据库性能的好坏，通常是在系统设计阶段就决定了的，于是，将数据库从系统设计中拿出来单独进行设计，变得越来越主流了。

这是一本以讨论海量数据环境下Oracle数据库设计与优化的书籍，也是作者10年来从事Oracle数据库工作的心得体会，是作者工作经验的结晶，这样的书籍并不多见。

本书通篇围绕着在海量数据环境下，如何构造一个高效的Oracle数据库这一核心，将许多相关技术融汇到这个核心话题当中，这些技术包括：分区、索引、数据库对象属性、并行技术、只读表空间、初始化参数、几种常见的数据库架构，以及在特定数据库架构下数据库的备份和恢复等相关技术。

本书适合于Oracle DBA、开发人员、项目经理或者其他对数据库性能感兴趣的人员。

序

怀远君写的第一本书《让Oracle跑得更快—Oracle 10g性能分析与优化思路》于2010年8月出版，曾经在China-pub（中国互动网）和当当网的销量榜的前列占据了很长时间。在给该书写序的时候，曾经想抛砖引玉，鼓励勤于笔耕的怀远君继续在优化问题上深入下去。现在时间过去了快一年，新书《让Oracle跑得更快2—基于海量数据的数据库设计与优化》也即将面世。

针对海量数据的数据库设计方面的书，在国内市面上并不多见，本书可以看成国内作者在这个领域里一个新的探索和尝试。随着近年来很多系统中数据量呈几何级数的暴增，对于存放这些数据的数据库的关注，被提到了一个新的高度，这完全是系统需求使然，而系统需求，即为用户需求，海量数据的数据库设计，不可避免地变成系统设计中的一个新领域。

纵观全书，可以视为作者第一本书的内容延续和技术的继续探讨，在第一本书里没有涉及的分区、索引、压缩、RAC、存储规划等内容，在本书里均进行了深入讨论。

关系数据库诞生已经有30多年时间，这几十年是数据大量增长、信息爆炸的年代，经过积累，很多应用的数据量已经非常可观。作为这些数据的载体、容器，数据库承受着日益增长的压力。如何面对海量数据带来的存储、查询速度、灾备等方面的压力，是每位数据库工程师所必须面对的课题。

本书的内容，对于处于一线面临海量数据压力的专业人员具有很好的参考价值；同时，对于处于系统设计、项目经理等职位的人员，也具有极好的参考价值，可以看做是作者的另一部心血力作。

 

ITPUB创始人tigefish

2011年   

 

 

前 言

一年前的这个时候，我也是在写一本书，书名叫《让Oracle跑得更快—Oracle 10g性能分析与优化思路》。

那是一本讲Oracle性能优化的书，书是在2010年8月初上市的，销量出乎意料的好，曾经一度在中国互动出版网（china-pub.com）上排在计算机类书的销售第一位，随后在当当网的数据库类书中也长时间占据着销售排名的首位。

现在的这本书可以看作是《让Oracle跑得更快—Oracle 10g性能分析与优化思路》的姊妹篇，它继承了上一本书的核心内容，就是写数据库的性能；同时，也保持了上一本书的写作风格，就是用一种思考和启发的方式来写作。

《让Oracle跑得更快—Oracle 10g性能分析与优化思路》主要是以知识点作为切入点来讨论Oracle数据库的性能分析和优化，比如并行技术、执行计划、优化器、AWR报告等；而本书就显得更加具体和有针对性，它主要是讨论在海量数据的情况下，数据库的设计和优化相关的话题。

这样，本书和《让Oracle跑得更快—Oracle 10g性能分析与优化思路》的内容叠加起来，就基本上形成了一套比较完整的关于数据库性能优化方面的书籍。

为什么一定要写关于数据库性能方面的书籍呢？

我一直都持有这样一种观点：现在很多的系统中，数据库的功能正在从数据存储工具的角色慢慢转变成数据处理器的角色。

近年来，用户对系统的性能要求变得越来越高，这和用户对系统的依赖性变得越来越强直接相关；而这种性能实际上很多时候就是指数据库的性能，因为数据库是数据的最终载体和数据分析、处理的机器（大多数时候）。

于是，数据库的性能问题就日益凸显出来，无论是项目负责人、开发人员还是DBA，都不可回避地要面对这个问题，唯一的区别是各自考虑的层面不同而已。

记得上一本书上市不久，ITPUB的创始人Tigerfish先生就鼓励我再写一本关于数据库设计方面的书，他的原话是这样的：

当DBA从烦琐的日常工作脱身出来举目远望的时候，再往前的一片田野便是架构问题，最好的、最彻底的能一劳永逸的优化，往往从架构设计开始。期待怀远君将来的新作，可以在这片更广阔的天地里驰骋。

在之后的沟通中，他又提及了几次，这种友好的鼓励变成了我开始考虑写这本书的原动力。

Tigerfish先生说得没错，真正的一劳永逸地解决问题的方法，就是在架构设计上。

一个好的架构，会使一个系统充满了可用性和扩展性；反之，就会后患无穷，开发人员要付出大量的后续工作，来修补这种架构缺陷导致的后遗症。

坦白地说，关于数据库的架构问题，特别是在海量数据情况下的数据库架构设计，我认为是一件不太容易的事情。

一方面，它和业务息息相关，需要考虑很多业务需求。

另一方面，数据系统架构设计，就其本身而言，在很多地方又有很大的独立性，比如：

●    分布式数据库架构

●    RAC架构

●    Data Guard架构

●    存储架构

 

最初想写很多内容，除了上面提及的数据库本身的架构设计外，还考虑对几种典型的系统，比如OLTP、OLAP的数据库架构问题进行讨论，甚至包括中间件架构、网络架构等。这看起来真是一个十分庞大的工程！

最终我放弃了这么庞大的内容，决定专心来写关于海量数据的数据库架构设计，这主要考虑到以下几个原因：

（1）我本人从事海量数据的数据库DBA工作超过10年，对这一块比较熟悉。

（2）数据库设计对于海量数据的数据库来说更有意义，更为重要。

当数据量大到一定程度时，很多看似不是问题的问题都变成了问题。

这样的数据库要解决数据的装载、数据的存储、数据的处理、数据的备份和恢复，这在海量数据的情况下，并非一件容易的事情（实际上，是一件很麻烦的事情）。

（3）数据库的数据越来越多，数据越来越受到重视。

随着信息化的进程越来越快，以前不是海量数据的数据库，现在也变成了海量数据的数据库；以前没有太关注的数据，现在也被严重关注。

基于以上三点原因，我决定只写海量数据的数据库设计；而对于一些OLTP相关的技术，书中有提到，但没有做过多的介绍，比如并发、绑定变量和OLTP相关的初始化参数都简单带过，这样让本书的内容看起来更有针对性一些。

实际上，如果要比较OLTP和OLAP数据库设计在系统设计中的重要程度，我认为对后者的关注更应该多一些，主要原因是：

（1）在OLTP数据库层面，相对简单，因为它的数据量显得不是那么“大”，很多常规的方法都可以使用，并且还有很多现成的技术都可以用。

（2）对于OLTP系统，即使数据量相对较大，但是SQL操作相对简单，通常来说，SQL执行都是一个很快的过程。

这可以用一个小例子来说明。

对于OLTP系统的数据库，SQL语句大多是这样的：

select *

from

 test where object_id=100

 

这些SQL语句的特点是，它们的谓词条件主要是这样的：

where col=…

 

而这些字段上都创建了索引，同时索引键值的重复率非常低（比如银行账户、股票交易代码），甚至很多时候这些字段都是主键（不允许有键值重复）。

这样的特性，使得OLTP系统数据库中的SQL执行通常都非常快。比如，下面就是这条SQL语句的执行结果，我们看到执行时间只能用毫秒衡量。

call     count       cpu    elapsed       disk      query    current     rows

------- ------   -------  ---------   --------  ---------   --------  -------

Parse        1      0.00       0.00          0          0          0        0

Execute      1      0.00       0.00          0          0          0        0

Fetch        2      0.00       0.00          0          9          0        4

------- ------   -------  ---------   --------  ---------   --------  -------

total        4      0.00       0.00          0          9          0        4

 

Misses in library cache during parse: 0

Optimizer mode: ALL_ROWS

Parsing user id: 55 

 

Rows     Row Source Operation

-------  ---------------------------------------------------

      4  TABLE ACCESS BY INDEX ROWID TEST (cr=9 pr=0 pw=0 time=143 us)

      4   INDEX RANGE SCAN TEST_IDX (cr=4 pr=0 pw=0 time=289 us)(object id 51366)

 

******************************************************************************

 

而在OLAP系统数据库中，通常运行着一些类似于下面的这种SQL语句，它们的主要作用是进行数据分析和聚合处理。

select object_type,count(*)

from

 test group by object_type

 

OLAP系统数据库的数据量非常大，它们消耗的系统资源要远远大于OLTP系统中SQL消耗的系统资源。下面是上面SQL语句的执行情况。注意：这只是演示的例子，实际上，这些SQL语句的执行时间要远远长于这个时间。

call     count       cpu    elapsed       disk      query    current        rows

------- ------  -------- ---------- ---------- ---------- ----------  ----------

Parse        1      0.00       0.00          0          0          0           0

Execute      1      0.00       0.00          0          0          0           0

Fetch        4      0.21       0.22          0       3550          1          39

------- ------  -------- ---------- ---------- ---------- ----------  ----------

total        6      2.21       2.32          0       3550          1          39

 

Misses in library cache during parse: 0

Optimizer mode: ALL_ROWS

Parsing user id: 55 

 

Rows     Row Source Operation

-------  ---------------------------------------------------

     39  HASH GROUP BY (cr=3550 pr=0 pw=0 time=220962 us)

 198980   TABLE ACCESS FULL TEST (cr=3550 pr=0 pw=0 time=597066 us)

 

********************************************************************************

 

（3）对于数据备份，OLTP系统数据库可以使用Rman增量的方式备份，也可以使用Data Guard来解决数据安全问题。

（4）对于OLTP系统的高并发，可以考虑使用中间件层间来解决。

（5）要提高OLTP数据库的处理效率，可以使用处理能力高的服务器。

（6）要提高OLTP数据库的数据访问速度，可以考虑使用内存数据库。

……

总之，对于OLTP系统，在数据库层面找到一个合适的解决方案，还不是一件非常困难和费神的事情。

反过来看OLAP系统数据库（或者数据仓库系统数据库），由于数据量太大，很多问题都变得很难，比如，对于一个1000TB数据的数据库，可能下面的问题都会使你非常头痛：

●    如何规划数据存储？

●    如何管理这些数据，包括备份和恢复数据？

●    如何优化查询？

●    如何实现容灾，保证业务不中断？

 

可以说，上面的每一条都非常困难，都需要全局地考虑用户需求、业务流程等一系列因素，通过各方权衡找到一个最终的解决方案。

上面谈的内容，就是我想写这本书的目的。和我的上一本书一样，实际上是在讨论对问题的一些思路，它可能没有提供一个完整、具体的解决方案，但是可以帮助启发读者的思维，提供一些参考和帮助。

我也看了《让Oracle跑得更快—Oracle 10g性能分析与优化思路》的一些书评，发现一些读者反映书中的内容写得不够深入，在这里我顺便做一些解释：

我一直认为，对于一个技术，最重要的不是这个技术本身的机制，而是什么时候使用这个技术。

这看起来就像一种本末的关系，比如，可以使用很多示例来说明强制变量绑定和变量窥视（bind peeking）机制，一直到我们明白这个过程的每个环节中Oracle做了什么。

但是当我们抬起头来接受别人的质询：

“我们这个系统需要强制变量绑定吗？”

时，我们真的能立刻做出回答吗？

我们知道系统的并发情况吗？

我们知道每天用户的主要工作是什么吗？

我们知道系统是属于OLAP还是OLTP，抑或是二者的一个混合体？

对技术精益求精是技术人员的一种学习方式，但绝不等同于不加选择盲目地沉迷技术，技术终归是为系统服务的，让系统保持健康和高效才是做技术的最终目的。

“授人以鱼，不如授人以渔。”

本书虽然谈不上是“渔”，但是这是作者的写作思路，我希望通过本书，把自己10多年来的Oracle DBA经验和大家分享，如果能够使读者有所收益，那将是我最高兴的事情！