下一个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，本该走进千家万户。

这是云海，有点像大海的波浪呢。

太阳刚落到与云层同一高度，经过的是一处云层比较稀疏的地方。

现在看这照片，诡异的蓝色。

而又有多少个碌碌无为的昨天从你身边飘过，不留一点痕迹。

今天的难忘，终将成为明天的财富，无论是快乐，抑或痛苦。

人生终将老去，年轻人可以老态龙钟，老年人亦可以生龙活虎。态度决定行动。

其实，我们都很年轻，虽不是八九点钟的太阳，起码也是午后一点的阳光，暴晒无比。

回归，回归。

picasa应该不错，就是国内访问有问题，找找国内的，好象没找到一个又可以外链接，又比较很容易管理的。

怎一个简单的问题都这么复杂呢。

其实电线也很乱。

旧金山缆车，终于体会了一把。装着军人大衣的黑人司机，边开缆车边把瓜籽壳丢在脚底下（大街上）。

中国城。

名字不详的教堂。

建在悬崖边上的饭馆，来自christine的推荐。。

很奇特的景象。在金门大桥边上。