Exadata的独门武器--卸载（Offloading）

Exadata的独门武器--卸载（Offloading）

卸载（Offloading）是Exadata的独门武器，正是它让Exadata不同于其他任何一种运行Oracle的平台。卸载指的是将处理能力从数据库服务器转移到存储层，它也正是Exadata平台提供的主要卖点，它不仅仅转移了CPU的使用，更主要的好处是减少了那些必须要返回给数据库服务器的数据量，而这正是大多数大型数据库的主要瓶颈所在。

卸载这个词在某些方面可以跟智能扫描（Smart Scan）互通，我们认为卸载是更好的描述方式，因为它指出了一部分传统上由数据库处理的SQL流程现在可以从数据库层面“卸载（offloaded）”到存储层面。这是一个更普适的措辞，它可以被用在那些甚至与SQL处理并无关系的优化上，比如用于提高备份和恢复操作的效率。

而另一方面，智能扫描，是一个更狭义的词汇，仅仅是指Exadata对SQL语句的优化方式，当进行扫描操作（通常是全表扫描）的时候，这些优化就会起作用。对于智能扫描更明确的定义也体现在Oracle核心代码中对于智能扫描相关等待事件的命名上，实际上有两个等待事件在名称中包含了“Smart Scan”字样，即“Cell Smart Table Scan”和“Cell Smart Index Scan”。我们将在后续的第10章里更详细地探讨这两个等待事件。好吧，我承认“智能扫描”这个词确实带有一些市场推广的成分，但是在代码上也确实有等待事件以此命名。无论如何，虽然这两个词在某些程度上可以互通，但是请记住“卸载”指的可不仅仅是加速SQL语句的执行。

本章我们将主要讲述“智能扫描”这种优化方式。我们会提到跟智能扫描相关的多种优化手段，它们是如何工作的，以及如果想使用智能扫描，那么有哪些前提条件必须满足。我们也会讲述一些技术，用以帮助你确认对于给定的SQL语句，智能扫描有否被使用到。至于在本书别的章节会提到的其他卸载优化，本章仅仅会做简要描述。

为何卸载如此重要

我们无法更加强调这个概念是何等重要，将数据库的处理能力转移到存储层这样的理念绝对是一个巨大的飞跃。这种概念已经存在了一段时间，实际上在几年前就有传言说Oracle带着这种想法跟至少一家最大的SAN制造厂商进行过密谈。显然那时候存储制造商对此想法并无兴趣，于是Oracle决定靠一己之力来推进这个理念。随后Oracle与惠普（HP）合作推出了最开始的Exadata V1，集成了卸载的概念。没过几年，Oracle就出手收购了太阳微系统公司（Sun Microsystems），这使得Oracle一举成为可以全面提供软硬件整合解决方案的公司，这也让Oracle可以完全控制到底想将哪些功能整合到产品里去。

卸载的重要性在于，当前大型数据库中一大主要瓶颈就是在磁盘系统和数据库服务器之间传输必要的能够满足数据仓库类型的查询所消耗的大量时间（因为带宽所限）。这一方面是硬件架构的问题，但是更大的问题在于传统Oracle数据库所传输的大量数据。Oracle数据库处理数据非常快也非常聪明，但是对于那些要读取大量数据的查询，将这些数据取到数据库来仍然会消耗很长时间。所以就跟任何优秀的性能调整专家一样，Oracle开始致力于减少最消耗时间的那些操作所花的时间。在分析中他们意识到每个需要磁盘读的查询会因为有大量数据要返回并由数据库服务器来处理而显得特别低效。Oracle研发了最好的缓存管理机制，但是对于那些确实庞大的数据集，将所有数据都保留在数据库服务器的内存中实在是不切实际的。

 Kevin说：作者们很好地解读了Oracle查询处理的发展历程。不过我还是想提醒各位，当今商用的x64服务器已经不再在架构上限制内存配置了。比如基于具有QuickPath互联功能的Intel Xeon 7500处理器的服务器就支持在多DIMM插槽上的大量内存通道，商用服务器具有数TB内存已然非常普遍。实际上，X2-8 Exadata就支持在数据库网格上拥有2TB内存，并且此能力随着时间推移必然会不断增强。走向极大内存的x64系统的潮流方兴未艾，我期待本书能保留足够长的时间，当以后的读者回过头来再看时会发现此注解所言不假。关于Exadata需要记住的重要一点是，它拥有Oracle数据库的所有功能并且附加了Exadata存储服务器，比如在某些场合，为了满足服务水平，正确的解决方案是尽量完全排除磁盘介质的低性能，客户就可以选择将深度压缩（比如Exadata混合列式压缩）和内存间并行查询（In-Memory Parallel Query）一起使用。

想像一下你所能想到的最快查询：单张表中一条记录中的一列，并且你还知道这条记录存储在哪里（通过rowid）。在传统Oracle数据库中，为了获取这列的值最少也要有一个数据块被读入内存（通常是8K大小），让我们假设该表每个数据块中平均存储着50条记录，那么很简单，你传输了额外的49行到数据库服务器中，对于此查询来说这就是无谓的开销。如果有一亿次呢？你应该开始意识到在大型数据仓库中这个问题的严重性了。消减在存储和数据库服务器之间传递完全不需要的数据所花费的时间，正是Exadata想要解决的主要问题。

卸载就是用来解决这样的问题——在各层之间传输无关数据而花费过多时间。卸载有三个设计目标，不过主要目标的重要性远超其他两个。

     减少磁盘系统和数据库服务器之间的传输数据量。

     减少数据库服务器上的CPU占用。

     减少存储层磁盘读取时间。

减少数据量是主要诉求和主要目标。卸载操作带来的大多数优化手段都是为了实现该目标。减少CPU占用同样很重要，但这不是Exadata所带来的主要好处，因此只好位居于减少传输数据量之后了（不过你们将会看到，解压是一个例外，因为解压操作会发生在存储服务器上）。另外还有几个降低磁盘读取时间的优化措施，不过，即使其中一些结果也颇引人注目，我们仍然不认为这一项目标是Exadata的最根本诉求。

Exadata是一个软硬件一体的产品，依靠这两方面组件，提供了令人瞩目的超越非Exadata平台的性能提升，不过，相比而言，软件方面带来的性能提升让硬件带来的好处相形见绌。下面是一个例子：

SYS@SANDBOX> alter session setcell_offload_processing=false;

 

Session altered.

 

Elapsed: 00:00:00.06

SYS@SANDBOX> select count(*) fromkso.skew3 where col1 < 0;

 

 COUNT(*)

----------

        2

1 row selected.

 

Elapsed: 00:00:51.09

SYS@SANDBOX> alter session setcell_offload_processing=true;

 

Session altered.

 

Elapsed: 00:00:00.07

SYS@SANDBOX> select count(*) fromkso.skew3 where col1 < 0;

 

 COUNT(*)

----------

        2

1 row selected.

 

Elapsed: 00:00:00.15

该示例演示了在一个具有3.84亿行记录的单表上的扫描。我们第一次是在禁用了卸载以后运行的，用到了Exadata所有硬件所能提供的好处但是没有软件的，你会发现即使是在Exadata硬件上，这条查询也执行了将近1分钟。注意这是仅仅分散到我们这台V2四分之一机柜的三台存储服务器上并且也没有使用任何闪存。然后我们重新启用了卸载，查询不到1秒钟就完成了。很显然在两次执行中硬件都是一样的，那么无疑正是卸载操作这样的软件能力带来了如此大的差别。

一个大众版的Exadata？

经常会看到关于搭建一个大众版Exadata的主题。该想法是搭建一套在某些方面模仿Exadata的硬件平台，想来也是为了能花费比Oracle对Exadata的收费要低的成本。当然这些建议都是在克隆Exadata的硬件部分，因为软件模块无法复制（仅仅是这点就应该让你不用再问到底这种尝试是否切实可行了）。不过，搭建自己的Exadata听上去很有吸引力，因为购买单独硬件模块的开销会比Oracle提供的整合价格要低，但是这种想法有几个缺点：

1．硬件模块中获得最多关注的是闪存。你可以购买一个拥有很大缓存的SAN或者NAS。中等尺寸的Exadata（1/2机架）在存储服务器上提供大约2.5TB的闪存，这确实是一个很大的数字，但是缓存了什么跟缓存有多大同样重要。Exadata足够智能到不会去缓存那些不大可能从缓存中收益的数据，比如，缓存镜像块就没什么用处，因为Oracle只会从主块中读取数据（除非发现主块损坏）。Oracle在编写管理缓存的软件上已经历时弥久，所以不用惊讶它的卓越表现，当扫描一个大表的时候，Oracle不会缓存所有的数据块，这样，那些经常会被读取的数据块也就还会留在内存中。如果没有这种了解数据库的缓存算法，普通的SAN或者NAS必须要配备大得多的缓存才可以与Exadata的闪存一较高下。另外请记住，在非Exadata存储上保存的数据量也要大很多，因为你无法使用混合列式压缩。

2．从硬件方面看更重要的，但是很奇怪却又偶尔会被DIY建议所忽略的，是存储和数据库之间的数据吞吐量。Exadata一体机在存储和数据库服务器之间提供了比当今大多数硬件架构都要平衡的数据通道，所以第二个关注的领域通常是各层之间的带宽，但是增加各层之间的数据吞吐量却并非像听上去这么简单。Exadata通过InfiniBand和可靠数据报套接字（Reliable Datagram Sockets，RDS）协议来增大吞吐量，Oracle研发了运行在InfiniBand网络上的iDB协议，而iDB协议在运行于非Exadata硬件的数据库中是不可用的，因此如果想要增加数据层之间的带宽，则必须要采用其他的方法，所以你可以使用运行在万兆网上的IPOB、iSCSI或者NFS，再或者使用高速的光纤连接方案，无论哪种方案在服务器上都需要多块接口卡（都需要连接到快速系统总线）。存储设备还需要提供足够的数据输出量以适应通路的消费能力（这正是当Oracle提到平衡配置时所指的意思）。同时，你还需要决定采用什么硬件，还要测试所有环节来确保它们能良好协作，不会在磁盘到数据库服务器之间有任何一处瓶颈产生。

3．第三点通常会被DIY方案提到的是数据库服务器自身。Exadata的硬件规格随处都可以查到，所以去购买完全相同的Sun机器是很容易做到的。但是很不幸，你需要计划购买更多的CPU，因为你无法将CPU的处理能力卸载到Exadata存储服务器上，而随之就会带来Oracle数据库许可证费用的增加。

4．假设我们可以做到在硬件的每个部分都和Exadata硬件性能相当，我们还是无法期盼能够获得与Exadata相近的整体性能，因为软件才是Exadata性能提升的点睛之笔，通过在Exadata中禁用卸载来做比较测试可以很容易地证明这点，我们会看到没有了软件助力的硬件性能到底怎样。Exadata软件做的事情很大一部分就是消除完全不必要的工作，比如把最终将被丢弃的列和行仍然传输到数据库服务器中。

就像我们的朋友Cary Millsap常喜欢说的那样，“做一件事情最快的方法就是不要去做它“。

  

本文节选自《深入理解Oracle Exadata》一书

Kerry Osborne（凯里•奥斯本）

Randy Johnson（兰迪•约翰逊）

Tanel Põder（托内耳•卜戴德）著

黄凯耀，张乐奕，张瑞译

电子工业出版社出版

图书详细信息:http://blog.csdn.net/broadview2006/article/details/7844209