下一个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会有什么直观的展示？

看了，保证你会很惊讶。

在Exadata上面的Retail Demo展示始于Exadata在2008年底在OOW上的发布。经过几年的发展与完善，在Oracle Real World Performance Group在全球各地所举行的各种培训活动中，Retail Demo极好的展示了Exadata各方面的卓越性能，使听众们对Exadata有着一个真实切身的体验。Retail Demo包括了众多数据仓库上的典型内容，如数据加载，增量数据加载，统计信息收集，数据验证和转换，随机查询，并发查询等等内容，里面融合着Oracle所提倡的最佳实践。

btw, 上次我在ACOUG分享的10分钟加载1TB数据的Demo即来源于此。

20分钟可以做哪些事情，下面是Retail Demo对此做的一个回答：

应广大人民群众的要求，Oracle Real World Performance Group终于推出了Retail Demo的录制视频，并共享在了youtube上面。总共分为四部分：

第一部分主要内容：
整个Demo的整体介绍，22节点实时性能监控窗口，EM监控窗口
数据仓库硬件发展趋势分析，硬件规划
1TB数据构成与HCC压缩
数据加载的特征,IO瓶颈? CPU瓶颈? 内存瓶颈？
Demo： 加载1TB 数据

第二部分主要内容：
数据压缩和分区对数据加载的影响
外部表的使用
Demo: 统计信息收集
11g的新特性:增量统计信息

第三部分主要内容：
使用服务进行增量加载
数据的有效性检查与转换
Demo：有效性检查
Demo: 数据转换

第四部分主要内容:
Demo: 随机复杂查询
数据库资源管理
Demo: 并发随机查询

这是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操作。那么，随着表设计的复杂，如一个表拥有成百上千列，两种存贮方式的性能就能体现出成百上千倍的差距了。

在检查客户的代码中，有时会深刻地感觉到原代码编写者在调试代码时的无奈。

这使我想起以前调试代码时的经历。一个SQL迟迟不返回结果，一小时过去了，又一小时过去了…… 于是，想了好多调优的方法，调整系统参数，为这个SQL建立很多Index，加上各种各样的Hint ……

于是，现在在代码中看到似曾相识的/*+ index(t_xx, idx_xx) */时，有时会发自内心的笑了，同时，轻巧地把里面的+号删掉了，我就让这些个hint不起作用，不强迫CBO走index了，结果当然是CBO选择了Hash Join，而不是原代码编写者指定的Nested Loop，于是，执行速度嗖一下上去了。

还有另一个有趣的事情，对大表的操作DSS查询或DML操作，检查客户的执行计划，无一例外地没有用并行查询或者并行DML，当然，里面会用到很多类似上面的/*+ index(t_xx, idx_xx) */。于是，心里很纳闷，这样跑DSS查询或DML操作，要跑到啥时候才跑完啊？有趣的地方在于，发现了原代码编写者的一个可能的workaround，对大表进行分割分片处理，一次跑不完，我跑它个几百上千次还可以吧。很聪明的做法，不过也感觉到一阵阵深深的无奈。

不可否以地，很多客户有很复杂的业务逻辑要处理，DBA们和开发者们也很聪明地运用着Oracle的技术。编写的代码质量其实也是可圈可点的。不过，在代码实现与现实世界之间，我们却不得不面对一个折衷，优雅的代码，在糟糕的机器配置之前，只能无能为力，于是，过度的调优也就理所当然，顺理成章的成为了主流。

或许，我们的DBA们要主动地进行呐喊；或许，我们还需要有这样的职位，能够从大局上对系统进行规划，包括对系统硬件的容量规划，系统软件实现上的总体设计，最佳实践上的运用等等；或许，也应该是架构师工作的一部分？

之前曾提到如何利用SQL Monitor Report对SQL进行诊断与调优，对于具体的SQL调优而言，SQL Monitor Report提供的信息无疑比AWR更有针对性，当然，AWR在信息的全面性方面会更胜一筹。本文提供一个具体的例子，同样的SQL，同样的执行计划，第一次执行的时间远远大于第二次执行的时间。

SQL Monitor Report详细提供了SQL执行所消耗的系统资源曲线，每一步骤的显著等待事件。通过对比上面两种情形下的系统资源曲线，执行计划中提供的等待事件分布，基本上应该可以诊断出第二次执行为什么比第一次执行快的原因。

下面是两个Reports的链接，你不妨试着对比对比。也借此体验下11.2 中的SQL Monitor Report在展现信息方面的灵活性(让鼠标指向每一个可能隐藏信息的地方，如每个可能的bar)。

• 第一次执行的SQL Monitor Report
• 第二次执行的SQL Monitor Report

关于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可能给大家带来的一个很诱人的地方。