网志栈编辑推荐
这本书可以看作《让Oracle跑得更快——Oracle 10g性能分析与优化思路》的姊妹篇，它继承了上一本书的核心内容——Oracle数据库的性能；同时，也保持了上一本书的写作风格，就是用一种思考和启发的方式来写作。
如果说《让Oracle跑得更快——Oracle 10g性能分析与优化思路》主要是以知识点作为切入点来讨论Oracle数据库的性能分析和优化，比如并行技术、执行计划、优化器、AWR报告等；而本书就显得更加具体和有针对性，它主要就是讨论在海量数据的情况下，数据库的设计与优化相关的话题，它集中讨论了在海量数据环境下一些具体技术的应用，包括分区的选择和使用、索引的选择和使用、对象的属性设置、初始化参数的设置，以及数据库架构的选择和设计。
《让Oracle跑得更快2 ——基于海量数据的数据库设计与优化》和《让Oracle跑得更快——Oracle 10g性能分析与优化思路》的内容叠加起来，基本上形成了一套比较完整的关于数据库性能优化方面的书籍。
；
内容简介
； ； ； ； ； ； 数据库设计，是最近几年才出现的技术领域，再早的时候，数据库是以一个黑盒的方式，附属到某个系统当中的，开发人员对它的关注非常少。
近年来，由于很多系统数据量呈几何级数激增，各种性能问题日益凸显出来，而这种性能问题绝大多数都落在了数据的载体——数据库身上，因此，人们越来越关注数据库的性能。而一个数据库性能的好坏，通常是在系统设计阶段就决定了的，于是，将数据库从系统设计中拿出来单独进行设计，变得越来越主流了。
； ； ； ； ； 这是一本以讨论海量数据环境下Oracle数据库设计与优化的书籍，也是作者10年来从事Oracle数据库工作的心得体会，是作者工作经验的结晶，这样的书籍并不多见。
； ； ； ； ； 本书通篇围绕着在海量数据环境下，如何构造一个高效的Oracle数据库这一核心，将许多相关技术融汇到这个核心话题当中，这些技术包括：分区、索引、数据库对象属性、并行技术、只读表空间、初始化参数、几种常见的数据库架构，以及在特定数据库架构下数据库的备份和恢复等相关技术。
作者简介
；谭怀远 ； 副总工，DBA团队负责人，在国内属于较早进入专职DBA岗位的人。是国内著名数据库论坛ITPUB的资深版主，论坛id alantany。10年的Oracle DBA工作经验，从Oracle 8开始进入数据库领域，从Oracle 8到Oracle 8i,Oracle 9i,Oracle 10g，见证了中国DBA职业的发展历程。作者对数据库的性能优化有独到的见解，颇擅长于海量数据数据库的设计管理及优化工作。
目录
开篇的话 ； ； ； ； ； ；
第一篇 ；分 ； ； ；区
第1章 ；分区的渊源 ； ； ； ； ； ；
； 1.1 ； DELETE与系统资源 ； ；
； 1.2 DELETE与释放空间
第2章 分区在海量数据库中的应用
2.1 分区的种类
2.1.1 范围分区
2.1.3 列表分区
2.1.4 组合分区
2.2 三种分区的比较
2.2.1 范围分区的适用情况
2.2.2 哈希分区的效率
2.2.3 列表分区与范围分区各自的优势
2.3 小结
第二篇 索 引
第3章 B树索引
3.1 B树索引概述
3.2 B数索引的效率
3.2.1 主键或者唯一性约束
3.2.2 键值重复率低的字段比较适合使用B树索引
第4章 位图索引
4.1 位图索引概述
4.2 什么时候使用位图索引
第5章 全文索引
5.1 全文索引概述
5.1.1 全文索引和普通索引的对比
5.1.2 全文索引的对象
5.1.3 全文索引在海量数据库中的应用
5.2 全文索引的空间
5.3 全文索引和DML操作
5.3.1 INSERT操作
5.3.2 DELETE操作
5.3.3 UPDATE操作
5.4 CTX_REPORT工具包
5.4.1 CTX_REPORT.DESCRIBE_INDEX
5.4.2 DESCRIBE_POLICY函数
5.4.3 CREATE_INDEX_SCRIPT函数
5.4.4 CREATE_POLICY_SCRIPT函数
5.4.5 INDEX_SIZE函数
5.4.6 INDEX_STATS存储过程
5.4.7 QUERY_LOG_SUMMARY存储过程
5.5 小结
第三篇 对 象 属 性
第6章 对象属性概述
6.1 Oracle数据库中的对象属性
6.2 对象属性和系统的关系
第7章 并行度
7.1 对象属性上的并行
7.2 使用Hint方式并行执行
7.3 索引上的并行度
第8章 数据压缩
8.1 数据压缩技术的应用
8.2 分区索引的压缩
8.3 数据压缩的优越性
8.3.1 节省空间
8.3.2 性能的提高
8.4 DML操作和数据压缩
第9章 只读表空间
9.1 只读表空间与数据备份和恢复的关系
9.2 只读表空间对于数据库的启动和关闭的影响
9.3 只读表空间可以防止数据被意外删除和修改
9.4 只读表空间使表空间的管理更加方便
第10章 数据库对象的分析
10.1 CBO和RBO
10.2 分析和动态采样
10.3 对象分析的频度
10.3.1 数据入库后不再改变
10.3.2 数据存在表中且经常改变
第四篇 海量数据的数据库架构设计
第11章 RAC架构
11.1 RAC在海量数据库中的应用
11.2 RAC架构之业务分割
11.3 RAC架构之负载均衡
11.3.1 客户端的负载均衡
11.3.2 服务器端的负载均衡
11.4 RAC架构之FAILOVER
第12章 分布式数据库
12.1 分布式数据库的优越性
12.2 分布式数据库的数据处理
12.3 分布式数据库的字符集
第13章 Data Guard
13.1 DataGuard概述
13.2 DataGuard的保护模式
13.2.1 最高数据保护模式
13.2.2 最高性能模式
13.2.3 最高可用性模式
13.3 DataGuard和RAC
13.4 DataGuard中Standby数据库的类型
13.4.1
前沿
开篇的话
一年前的这个时候，我也是在写一本书，书名叫《让Oracle跑得更快——Oracle 10g性能分析与优化思路》。
那是一本讲Oracle性能优化的书，书是在2010年8月初上市的，销量出乎意料的好，曾经一度在中国互动网（china-pub.com）上排在计算机类书的销售第一位，随后在当当网的数据库类书中也长时间占据着销售排名的首位。
现在的这本书可以看作是《让Oracle跑得更快——Oracle10g性能分析与优化思路》的姊妹篇，它继承了上一本书的核心内容，就是写数据库的性能；同时，也保持了上一本书的写作风格，就是用一种思考和启发的方式来写作。
《让Oracle跑得更快——Oracle10g性能分析与优化思路》主要是以知识点作为切入点来讨论Oracle数据库的性能分析和优化，比如并行技术、执行计划、优化器、AWR报告等；而本书就显得更加具体和有针对性，它主要是讨论在海量数据的情况下，数据库的设计和优化相关的话题。
这样，本书和《让Oracle跑得更快——Oracle10g性能分析与优化思路》的内容叠加起来，就基本上形成了一套比较完整的关于数据库性能优化方面的书籍。
为什么一定要写关于数据库性能方面的书籍呢？
我一直都持有这样一种观点：现在很多的系统中，数据库的功能正在从数据存储工具的角色慢慢转变成数据处理器的角色。
近年来，用户对系统的性能要求变得越来越高，这和用户对系统的依赖性变得越来越强直接相关；而这种性能实际上很多时候就是指数据库的性能，因为数据库是数据的最终载体和数据分析、处理的机器（大多数时候）。
于是，数据库的性能问题就日益凸显出来，无论是项目负责人、开发人员还是DBA，都不可回避地要面对这个问题，唯一的区别是各自考虑的层面不同而已。
免费在线读
一年前的这个时候，我也是在写一本书，书名叫《让Oracle跑得更快—Oracle 10g性能分析与优化思路》。
那是一本讲Oracle性能优化的书，书是在2010年8月初上市的，销量出乎意料的好，曾经一度在中国互动出版网（china-pub.com）上排在计算机类书的销售第一位，随后在当当网的数据库类书中也长时间占据着销售排名的首位。
现在的这本书可以看作是《让Oracle跑得更快—Oracle10g性能分析与优化思路》的姊妹篇，它继承了上一本书的核心内容，就是写数据库的性能；同时，也保持了上一本书的写作风格，就是用一种思考和启发的方式来写作。
《让Oracle跑得更快—Oracle10g性能分析与优化思路》主要是以知识点作为切入点来讨论Oracle数据库的性能分析和优化，比如并行技术、执行计划、优化器、AWR报告等；而本书就显得更加具体和有针对性，它主要是讨论在海量数据的情况下，数据库的设计和优化相关的话题。
这样，本书和《让Oracle跑得更快—Oracle10g性能分析与优化思路》的内容叠加起来，就基本上形成了一套比较完整的关于数据库性能优化方面的书籍。
为什么一定要写关于数据库性能方面的书籍呢？
我一直都持有这样一种观点：现在很多的系统中，数据库的功能正在从数据存储工具的角色慢慢转变成数据处理器的角色。
近年来，用户对系统的性能要求变得越来越高，这和用户对系统的依赖性变得越来越强直接相关；而这种性能实际上很多时候就是指数据库的性能，因为数据库是数据的最终载体和数据分析、处理的机器（大多数时候）。
于是，数据库的性能问题就日益凸显出来，无论是项目负责人、开发人员还是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 ROWIDTEST (cr=9 pr=0 pw=0 time=143 us)
4 INDEX RANGE SCANTEST_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=0time=220962 us)
198980 TABLE ACCESS FULL TEST (cr=3550 pr=0 pw=0time=597066 us)
********************************************************************************
（3）对于数据备份，OLTP系统数据库可以使用Rman增量的方式备份，也可以使用DataGuard来解决数据安全问题。
（4）对于OLTP系统的高并发，可以考虑使用中间件层间来解决。
（5）要提高OLTP数据库的处理效率，可以使用处理能力高的服务器。
（6）要提高OLTP数据库的数据访问速度，可以考虑使用内存数据库。
……
总之，对于OLTP系统，在数据库层面找到一个合适的解决方案，还不是一件非常困难和费神的事情。
反过来看OLAP系统数据库（或者数据仓库系统数据库），由于数据量太大，很多问题都变得很难，比如，对于一个1000TB数据的数据库，可能下面的问题都会使你非常头痛：
● 如何规划数据存储？
● 如何管理这些数据，包括备份和恢复数据？
● 如何优化查询？
● 如何实现容灾，保证业务不中断？
可以说，上面的每一条都非常困难，都需要全局地考虑用户需求、业务流程等一系列因素，通过各方权衡找到一个最终的解决方案。
上面谈的内容，就是我想写这本书的目的。和我的上一本书一样，实际上是在讨论对问题的一些思路，它可能没有提供一个完整、具体的解决方案，但是可以帮助启发读者的思维，提供一些参考和帮助。
我也看了《让Oracle跑得更快—Oracle10g性能分析与优化思路》的一些书评，发现一些读者反映书中的内容写得不够深入，在这里我顺便做一些解释：
我一直认为，对于一个技术，最重要的不是这个技术本身的机制，而是什么时候使用这个技术。
这看起来就像一种本末的关系，比如，可以使用很多示例来说明强制变量绑定和变量窥视（bindpeeking）机制，一直到我们明白这个过程的每个环节中Oracle做了什么。
但是当我们抬起头来接受别人的质询：
“我们这个系统需要强制变量绑定吗？”
时，我们真的能立刻做出回答吗？
我们知道系统的并发情况吗？
我们知道每天用户的主要工作是什么吗？
我们知道系统是属于OLAP还是OLTP，抑或是二者的一个混合体？
对技术精益求精是技术人员的一种学习方式，但绝不等同于不加选择盲目地沉迷技术，技术终归是为系统服务的，让系统保持健康和高效才是做技术的最终目的。
“授人以鱼，不如授人以渔。”
本书虽然谈不上是“渔”，但是这是作者的写作思路，我希望通过本书，把自己10多年来的OracleDBA经验和大家分享，如果能够使读者有所收益，那将是我最高兴的事情！
让Oracle跑得更快2——基于海量数据的数据库设计与优化 pdf下载声明
本pdf资料下载仅供个人学习和研究使用，不能用于商业用途，请在下载后24小时内删除。如果喜欢，请购买正版
