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

看了，保证你会很惊讶。

对上一篇文章里提到两条语句
select distinct begin_date, end_date, begin_date + level -1 day  from test connect by begin_date + level -1 <= end_date order by 1,2,3;
和
select one_date
  from (select start_date + level – 1 one_date
          from (select min(start_date) start_date, max(end_date) end_date
                  from test) test
        connect by start_date + level – 1 < = end_date ) all_date,
       test
where one_date between start_date and end_date;

它们都实现相同的功能，即: 当一个表里面有两个列，分别为begin_date和end_date时，如何针对这个表的每一行，用SQL返回begin_date和end_date之间的所有连续日期。

首先，我们关注第一条语句在没有distinct的情况下返回的行数。

会使问题简单化，假设对于表里的每行数据，end_date – begin_date + 1 的值都是一样的，设为 n 。假设test里总共有 m 行(m>1)。
那么，这时返回的行数是 m * ( power(m,n) – 1 )/( m – 1 ) 。
(
这是一个等比数列，公式为
1 +  m +  power(m,2) + ….  power(m,n-1) = ( 1 – power (m,n)) / (1 – m),
)
这些行可以用一系列的树加以形象的表示，如下所示：

当 n 和 m 很大时，会使结果集变得非常之大，为 power(m,n).

因此，下面语句在数据量变大的情况下，性能将急剧下降!
select distinct begin_date, end_date, begin_date + level -1 day  from test connect by begin_date + level -1 <= end_date order by 1,2,3;

对于语句2，我们关注以下子查询所返回的行数:
select start_date + level – 1 one_date
          from (select min(start_date) start_date, max(end_date) end_date
                  from test) test
        connect by start_date + level – 1 < = end_date

这时，表实质上只有1行时，存贮的是原来表的最大值和最小值。也就是说，这时 m = 1 。

当m=1时，情况变得不同了。这时，返回的行数刚好就是 n 。
如果以树加以表示的话，这时上面的图形已经退化成一棵只有一个支干的树。

因此，当原来的查询m 和 n都很大时，返回的行数为 将为n。

从上面的表述可清晰地看出，语句2在大数据量的情形下将能体现出良好的性能。

从另一方面看，出现distinct的地方，或许就是性能调整应该关注的地方了。