OS与Oracle

Kaya 发表于os2ora.com

下一个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所提倡的最佳实践。20分钟可以做哪些事情，下面是Retail Demo对此做的一个回答…

Kaya 发表于 os2ora.com 这是7月30号在北京远洋光华中心ACOUG所组织的一次技术活动。我的分享主题是《Exadata下的数据并行加载、并行卸载及性能监控》。另一位作者是邢海捷，早在几年前，就深深地拜读了他在《Oracle数据库性能优化》对锁的深入浅出的描述。 北京还是挺有技术氛围的，自愿自觉地参加，又能办得红红火火，很成功的组织。 和Eygle和yangtingkun的一张合影（左起:Kaya, Eygle,Yangtingkun）。我觉得这张图片很有意义。 更多图片，猛击http://www.douban.com/photos/album/54076276/ 下面是演讲的PPT。 Exadata下的数据并行加载、并行卸载及性能监控 当然， 给大家留下深刻印象的，其实是里面的两个Live Demo， Eygle和Yangtingkun的blog/weibo里也不约而同地也提到了（一台满配的X2-2机器）： 加载1TB数据，用时10分钟，全表扫描读取这些数据用时 7 秒。总数据量行数在 76 亿左右。 卸载1TB数据，用时17分钟，同时实现把文件压缩成gzip格式。

Kaya 发表于 os2ora.com 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，本该走进千家万户。  

最近一段时间，老在深圳北京间往返，发现坐晚上6点的飞机回深圳是不错的选择，人不多，靠窗的位置还能看日落。 这是云海，有点像大海的波浪呢。   太阳刚落到与云层同一高度，经过的是一处云层比较稀疏的地方。   现在看这照片，诡异的蓝色。

当生活是为了忘记，当今天就忘记了昨天，昨天存在的意义又何在？ 而又有多少个碌碌无为的昨天从你身边飘过，不留一点痕迹。 今天的难忘，终将成为明天的财富，无论是快乐，抑或痛苦。 人生终将老去，年轻人可以老态龙钟，老年人亦可以生龙活虎。态度决定行动。 其实，我们都很年轻，虽不是八九点钟的太阳，起码也是午后一点的阳光，暴晒无比。 回归，回归。

此时此刻，彼时彼刻，物是人非。    

看来还是得找个第三方网站托管下照片。放在自己空间太占用带宽和存贮了。目前放在本空间的图片暂时无法访问啦，直到找到解决方案为止。 picasa应该不错，就是国内访问有问题，找找国内的，好象没找到一个又可以外链接，又比较很容易管理的。 怎一个简单的问题都这么复杂呢。

从渔人码头，坐缆车到中国城，步行返回渔人码头，开车到最西边的cliff house，折回金门大桥，杀向市中心macy大购物。神奇的一天就过去了。 其实电线也很乱。 旧金山缆车，终于体会了一把。装着军人大衣的黑人司机，边开缆车边把瓜籽壳丢在脚底下（大街上）。 中国城。 名字不详的教堂。 建在悬崖边上的饭馆，来自christine的推荐。。 很奇特的景象。在金门大桥边上。