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

看了，保证你会很惊讶。

既然提到了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处理能力，同时还能减少对带宽的争用。至于更具体的信息，留在另一篇介绍啦。

一个delete语句，在”同样”的环境下执行两遍。第一次花了16分钟，第二次花了24分钟。

这条delete语句是这样子的:

DELETE FROM T A
 WHERE EXISTS (SELECT 1
          FROM T B
         WHERE B.KEY = A.KEY
           AND A.ROWID < B.ROWID);

在做delete之前，已经保证表A尽可能一致，两次delete都是以串行方式执行。在这个表上都没有索引存在。整个系统只有这个SQL在运行。

问题究竟出现在哪里呢？

先检查redo, undo还有logical reads, 看看是否存在不同:

可以看出，两次运行基本上产生的redo和undo和所要求的logical reads都是差不多一样的。

在检查其它性能数据的过程中，两者的物理IO有了明显的差别:

明显地，第二次运行比第一次运行多了一半的读IO，这刚好与第二次运行的时间比第一次运行的时间多一半相吻合。

一个可能的解释在于buffer cache在两次运行开始时所处的状态不同。导致了第二次运行时没有充足的free buffer，从而进一步导致了buffer命中率的下降。这从下面关于buffer的一些性能指标值也可以看出:

为了验证上面的结论，可以做两个测试，第一是在跑delete之前把buffer cache flush，第二是在跑delete之前把表A的数据加载进buffer cache。

当flush buffer cache后，delete花了17分钟。

当把数据加载进buffer cache后，delete花了8分钟。

这个例子最重要的一点在于说明了memory对OLTP系统性能的严重影响。这是与DSS系统存在明显区别的一个地方，也可以说是串行操作与并行操作的显著区别。对OLTP系统而言，SGA起着减少物理IO的作用。对SGA的有效管理与配置，影响着OLTP系统的性能。而对于DSS系统而言，PGA并不会减少扫描表的IO量。PGA里面的数据随着操作的完成而得以释放。

Note: 上面性能指标值来源于v$mystat视图。