下一个Oracle Real World Performace Group所录制的Demo视频是关于OLTP性能的。与Retail Demo对应，这个Demo内部的名字叫做Connection Demo。Retail Demo主要展现的是数据仓库的性能，而Connection Demo展现的主要是OLTP的性能。这个Demo首次出现于2010年的OOW，往事不堪回首，那段时间我刚好在Oracle总部负责这个Demo的开发工作，怀念那段与bug做斗争的日子。

这个Demo的功能比较多，录制好的视频主要有两个主题：

1. OLTP Performance – The Trouble with Parsing
这是关于Oracle 里面的no parse, soft parse 和 hard parse。

这是一个老生常谈的问题，自从有了Oracle之后。

在no parse情况下，情况很理想，响应时间1毫秒，吞吐量30,000.
在soft parse情况下，情况有点糟糕了…
在hard parse情况下，情况更糟糕了… 关于shared pool的等待事件…

另一个展示的是不使用长连接而使用短连接有什么后果。究竟频繁地执行logon -> do some stuff -> logoff会导致什么严重的后果？服务器上的SYS% CPU为何会比USER% CPU还高？

还有，EM在这三种情况下的Performance Page会有什么直观的展示？

一切尽在这个Demo中，嗯。

2. OLTP Performance  – Concurrent Mid-Tier Connections
这是一个很有趣的Demo.

有多少客户的系统连接着成千上万个数据库连接？有多少个客户把实现成32000个并发连接做为系统的需求进行设计？

过度的连接会导致什么后果？

这个Demo模拟了两个应用服务器对一个数据库服务器的连接。应用会话数为9600个，使用JDBC Connection Pool连接到数据库。

开始时，Connection Pool有2048个连接。这时你会看到一个看起来非常常见的系统。CPU很忙，系统看起来很正常，等待事件看起来很多很常见。如buffer busy waits, enq: TX – index contention, log buffer space等等。嗯，DBA开始分析这些等待事件，开始调整参数。 过年过节的时间，系统变得更不稳定，DBA们开始提心吊胆渡过每一秒钟。

这个Demo起码回答了几个问题：
如果把Connection 的个数降到1024，会有什么结果？会话的等待时间会不会变得更长？吞吐量会不会下降？
如果把Connection 的个数降到96，又会有什么结果？
还有，EM在这三种情况下的Performance Page会有什么直观的展示？

看了，保证你会很惊讶。

这是7月30号在北京远洋光华中心ACOUG所组织的一次技术活动。我的分享主题是《Exadata下的数据并行加载、并行卸载及性能监控》。另一位作者是邢海捷，早在几年前，就深深地拜读了他在《Oracle数据库性能优化》对锁的深入浅出的描述。

北京还是挺有技术氛围的，自愿自觉地参加，又能办得红红火火，很成功的组织。

和Eygle和yangtingkun的一张合影（左起:Kaya, Eygle,Yangtingkun）。我觉得这张图片很有意义。

更多图片，猛击http://www.douban.com/photos/album/54076276/

下面是演讲的PPT。

当然， 给大家留下深刻印象的，其实是里面的两个Live Demo， Eygle和Yangtingkun的blog/weibo里也不约而同地也提到了（一台满配的X2-2机器）：

• 加载1TB数据，用时10分钟，全表扫描读取这些数据用时 7 秒。总数据量行数在 76 亿左右。
• 卸载1TB数据，用时17分钟，同时实现把文件压缩成gzip格式。

11g里面的DBRM(Database Resource Manager)正越来越显示其重要性。特别地，随着Exadata的流行，DBRM管理的东西越来越多，有对硬件资源，如CPU, IO资源的分配；也有对软件资源，如并行进程数，活动会话数的分配。可以预见的是，Exadata做为一个一体机，DBRM发挥的作用将越来越大，如11g里面的Instance Caging可以在CPU层次实现多个数据库系统的Isolation，IORM可以实现多个数据库系统对IO的Isolation。而系统间相互的独立也是对多个应用系统进行整合的前提。

如Exadata这种强劲的机器，如何用好它是一个很重要的问题。一方面，Oracle会尽可能地实现其易用性与自我管理性，另一方面，也需要DBA，开发者掌握驾驭它的方法与技巧，以便更好地发挥Exadata的性能。

准备花点时间，整理一下使用DBRM的基本思路，与在现实中的实际运用。DBRM，本该走进千家万户。

做下回顾与思考。

从第一篇开始到现在，Cell Flash Cache, Exadata Hybrid Columnar Compression, Storage Index轮番上场，加上V1版本里出现的Smart Scan，Infiniband等等，多少会给人以眼花缭乱的感觉。

最根本的一点，当然在于Exadata本身是一个balanced system。

不过，这些技术做为一个整体对实际应用会带来多大的好处呢？这不是一个很好回答的问题，当然也可以用一句话回答——具体问题具体分析。

思路应该是这样的，首先明了当前系统的现状

• 如果当前系统运作得很好，简直完美的设计，分区，并行，并发控制等都无可挑剔，业务量也没超过系统极限，那么也许只有一些技术会对性能提升比较明显，如Smart Scan。举个例子，如果原来系统没存在IO上的瓶颈，Cell Flash Cache就英雄无用武之地了。
• 如果当前系统运作得很好，简直完美的设计，分区，并行，并发控制等都无可挑剔，业务量大大超过系统极限，系统出现CPU或者IO或者Network上的瓶颈了，这时或许就是考虑升级的时候了。
• 如果当前系统为小数据量所设计，如刚开始没有分区，但随着业务量的增长，系统出现CPU或者IO或者Network上的瓶颈了，这时可以有两条途径，改进原来的设计，或者考虑硬件升级了。

设计上的改进包括

• 分区
• 压缩
• etc.

硬件上的升级包括

• Smart Scan
• Flash Cache
• Storage Index
• etc.

最后，做为一个例子，可以考核一个原来的系统（没分区，没压缩，没Flash Cache，没Storage Index），分区，压缩，Flash Cache，Storage Index，分别能带来的性能上的提升，及做为一个整体带来的性能提升。

感性认识还是更重要的，虽然我把它放在最后面了。

Exadata上另一个聪明的软件设计是实现了storage index.

另一篇白皮书中有对Storage Index的一个描述 A Technical Overview of the Sun Oracle Exadata Storage Server and Database Machine

Storage Indexing

Storage Indexes are a very powerful capability provided in Exadata storage that helps avoid I/O operations. The Exadata Storage Server Software creates and maintains a Storage Index in Exadata memory. The Storage Index keeps track of minimum and maximum values of columns for tables stored on that cell. When a query specifies a WHERE clause, but before any I/O is done, the Exadata software examines the Storage Index to determine if rows with the specified column value exists in the cell by comparing the column value to the minimum and maximum values maintained in the Storage Index. If the column value is outside the minimum and maximum range, scan I/O for that query is avoided. Many SQL Operations will run dramatically faster because large numbers of I/O operations are automatically replaced by a few in-memory lookups. To minimize operational overhead, Storage Indexes are created and maintained transparently and automatically by the Exadata Storage Server Software.

如果Exadata给你的印象就是有很强大的硬件，却不会利用传统的性能优化方法，比如索引，去加快查询速度的话，那么Storage Index的出现或许会改变你的这种观念。而且，storage index是完全自动化的，它甚至不需要人工的干涉就能工作得很好。

Smart Scan之所以冠名以Smart，是因为它在扫描数据的时候同时做过滤操作，只把必需的数据返回给数据服务器端；而Storage Index在这里却直接避免了对Disks的访问，其Smart的程度与Smart Scan相比，或许已经到了超凡脱俗的境界了。

如果真要找一个类比的话，DB2中有个特性或许可以与Storage Index做下对比，那就是Multi Dimensional Clustering. 仔细阅读下MDC的介绍，两者真的有异曲同工之妙。

下一个要出场的是HCC, Hybrid Columnar Compression. 目前它是Exadata上面才有的一个特性，所以又叫做Exadata Hybrid Columnar Compression。

在Exadata V2 架构分析 (1)中，曾提到“在软件设计上，还有另一个重头戏，它更是大大的利用起了存贮节点上的CPU处理能力，同时还能减少对带宽的争用”。Exadata的很多设计，或许从根本上讲，就在于充分利用起存贮节点上的处理能力，Smart Scan和这里所要提及的HCC，就是两个典型的代表了。HCC中文翻译过来或许就叫做混合列压缩，它是在单纯的行存贮和列存贮之间取得的一个折衷。

一个比较好的参考文档是这篇白皮书Exadata Hybrid Columnar Compression.

上图中，典型地，4个8KB的blocks被当成一个Compression Unit。在这个CU所能存贮的rows中，每个column被分开存贮。可以想像到，每个column里的内容是很相似的，如果与row之间的内容做比较的话。于是，对每个column的内容进行压缩，会得到很好的压缩率。根据压缩算法的不同，Oracle提供了四种不同的压缩等级，详见上面提到的白皮书，这里就不详细列出了。

到底EHCC的压缩率可以达到多少呢？白皮书中提到两个数据，可以做为参考，对于Warehouse Compression，有10x的压缩率，对于Archive Compression，有15x的压缩率。

EHCC相对于单纯的Column Compression而言，有一个极其突出的优点，这点是不得不提及的。当进行行级访问数据时，如根据rowid返回一行数据，EHCC只要一个IO就够了，不管所访问的表有多少列，而对于单纯的Column Compression而言，对于每个Column，都必须有一个IO操作。那么，随着表设计的复杂，如一个表拥有成百上千列，两种存贮方式的性能就能体现出成百上千倍的差距了。

关于Cell Flash Cache，好象大家都余兴未尽，例如：
1. 一个真正的生产系统，真的需要1,000,000 IOPS吗？
2. Cell Flash Cache对用户带来的真正的好处在哪里？

假设用户的逻辑IOPS达到1,000,000 IO/s. buffer cache命中率为98%。则落在Cell Flash Cache中的IOPS为20,000次。这个数据对于1/4配，即一个quarter的Exadata来说，当然是小菜一碟，不过对于一般磁盘呢？一般的磁盘每秒大约为300 IOPS，这意味着需要有20,000/300=66个磁盘，这已经是一个不低的配置了。

再进一步考虑，如果系统想支持混合负载，即系统同时支持数据仓库查询和OLTP在线系统。那么这时OLTP的性能将会受到严重影响。要知道，数据仓库查询要求的MBPS，而OLTP要求的则是IOPS，这两个指标是会相互影响的，用户一般考虑的是OLTP优先。甚至于出现一种情形，我不清楚下面这种情况会多普遍：

在IO受限的情形下，不敢对OLAP查询启用并行，由于不启用并行，OLAP查询很久不返回结果，进一步地，用户会在表上建更多的索引来“优化”这些OLAP查询。最终，整个混合型的系统就变成了一个类似OLTP的系统了。

在这种情形下，Cell Flash Cache或许会带有性能上的实质提升，通过Flash Cache会大大提升OLTP的查询性能，同时，后端的磁盘和Flash Cache会一起提供足够的带宽给OLAP查询(很聪明吧)，这在硬件上保证了两者并存的可能性。另一方面，由于在IO上的财大气粗，对原有OLAP的过度优化终于可以停止了，系统设计因些会回归简单，与此对应地，系统维护成本也会大大降低。

或许这是Cell Flash Cache可能给大家带来的一个很诱人的地方。

既然提到了Flash Cache,如果不提下对OLTP的提速好象会缺少点什么。对OLTP系统而言，缓存是一个极其重要的设计，不管是数据库节点上的内存上的Buffer Cache，还是存贮节点上的Flash Cache（Exadata)，还有数据库节点上的Flash Cache(某些平台，如Linux)。

前几天在Eygle的性能调优课程上听过他提过的一句话，缓存为王（致敬，呵呵），深以为然，这应该是他极其重要的实践总结，对于OLTP系统而言，这真是一点不为过。

下面的表格列出了一个实际场景，分别测试了不同的buffer 命中率和引入Flash Cache之后的性能变化。

上面的三行对应的OLTP负载是相同的，但总的执行时间却是大大不同的，从2分多钟到10几秒到2秒。唯一的区别就在于Cell Flash Cache, Buffer Cache 的介入。

上面这些数据起码可以得出几个结论：

1. Buffer Cache会减少CPU Time,但Cell Flash Cache不会。这从另一个方面说明，IO调度是需要CPU的。

2. Cell Flash Cache和Buffer Cache都大大减少了User IO Time。最终的结果就是大大提升了响应时间，例如上面我们得到了从13倍到158倍的性能提升。

3. Cell Flash Cache和Buffer Cache都提高了DB节点的CPU利用率。例如上面我们的CPU利用率从3%提高到36%和61%。

Exadata V2宣传的一个令人惊诧的数字之一是每秒钟一百万个8K的随机IO。很恐怖吧，1,000,000 IO/s.

其实，如果只是进行读操作而没有写操作的话，这个数字会更令人恐怖。下面是一个截图。把里面的峰值(300k)除以3乘以14，就得到整个机器14个cell可以达到的一个IOPS: 1.4 million IO/s.

准备写一系列的文章，专门分析下Exadata的架构。时间真过得很快，自从Exadata问世以来，一直围绕着它做各种各样的性能测试，从V1过渡到V2。Exadata在大踏步地前进着，我总认为，这应该是一个很优秀的产品，而我也相信时间会证明这一点的。

这些文章不会有很严谨的结构，或许某天，某时发现的一个特性，一个特点，一个最佳实践，一个有意思的地方，一个令人惊讶的数据，一个令人鼓舞的图形，都会成为这一系列文章的一部分。

Flash Cache是V2里引入的一个特性，大家或许都认为Flash Cache 主要是用于OLTP场合，为OLTP提高更高的IOPS，这点当然没错，Flash Cache相比于一般磁盘，会带来上十倍的IOPS的性能提升。但即使对于DSS场合，Flash Cache也是提升性能的一个利器。

下面是看图说话时间。

左图中，MBPS达到了4.5 GB/s。但是存贮节点上的CPU和数据库节点上的CPU的利用率却在20%左右。如果在存贮节点加入Flash Cache，整个系统会发生什么样的改变呢？右图就是加入了flash cache后的CPU/IO情况。MBPS达到了14G/s，存贮节点的CPU利用率超过了60%，DB节点上的CPU利用率也超过了40%。

仔细地对比研究这个图，对系统间资源的协作会有进一步的认识。

可以说, Flash Cache除了提供更高的带宽外，还大大解放了存贮节点上的CPU处理能力。这种处理能力可是单纯的高端存贮都不具备的，这就是Exadata上独有的Smart Scan特性。Exadata V1实现了对磁盘的Smart Scan，而V2则实现了对Flash Cache的更快，更强大的Smart Scan。当然，在软件设计上，还有另一个重头戏，它更是大大的利用起了存贮节点上的CPU处理能力，同时还能减少对带宽的争用。至于更具体的信息，留在另一篇介绍啦。

在做Exadata相关的培训时，Ad-Hoc Query是经常被提及的一个词，中文的翻译应该就叫做随机查询吧，望文生义，就是随机的，不能预料到的查询。但究竟有多随机呢，一些活生生的例子可能更能说明问题。

我们组设计了一个查询，每次show出来的时候，底下总有人暗底里偷笑不止。挺好玩的一件事情。这个查询是这样的：

我们要查询在2009年5月份第一个星期在北京市的所有百货超市里最受某一类型的消费者欢迎的前十个商品，这一类型的购物者有以下的购物癖好：购物的时候不买banana。

这个查询其实是基于一个零售业系统，里面存贮着全国所有超市的交易记录，这是一个TB级的数据库。如果有人说他能通过设计索引让这个查询跑得飞快，我可真不敢相信。

这种查询是有可能的，或许某天某位业务经理就跑到你(DBA)面前，帮我查查…，多久能给我结果？你的答案会是分钟，小时，天，还是月呢？

做个类推，中国移动版的:

我们要查询在2009年5月份第一个星期在北京市最受某一类型的手机用户欢迎的前十个热线号码，这一类型的手机用户有以下的癖好：发送的短消息里面从没有出现过类似”I love you”的语句。

或者你可以针对任一个数据库系统构造出类似的ad-hoc查询语句了。