OS与Oracle

下一个Demo是关于OLTP性能的。与Retail Demo对应，这个Demo内部的名字叫做Connection Demo。Retail Demo主要展现的是数据仓库的性能，而Connection Demo展现的主要是OLTP的性能。这个Demo首次出现于2010年的OOW，往事不堪回首，那段时间我刚好在Oracle总部，刚好负责这个Demo的开发工作，怀念那段与bug做斗争的日子。

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

从第一篇开始到现在，Cell Flash Cache, Exadata Hybrid Columnar Compression, Storage Index轮番上场，加上V1版本里出现的Smart Scan，Infiniband等等，多少会给人以眼花缭乱的感觉。

最根本的一点，当然在于Exadata本身是一个balanced system。

不过，这些技术做为一个整体对实际应用会带来多大的好处呢？这不是一个很好回答的问题，当然也可以用一句话回答——具体问题具体分析……

Exadata上另一个聪明的软件设计是实现了storage index.
如果Exadata给你的印象就是有很强大的硬件，却不会利用传统的性能优化方法，比如索引，去加快查询速度的话，那么Storage Index的出现或许会改变你的这种观念。而且，storage index是完全自动化的，它甚至不需要人工的干涉就能工作得很好……

下一个要出场的是HCC, Hybrid Columnar Compression. 目前它是Exadata上面才有的一个特性。
在Exadata V2 架构分析 (1)中，曾提到“在软件设计上，还有另一个重头戏，它更是大大的利用起了存贮节点上的CPU处理能力，同时还能减少对带宽的争用”。Exadata的很多设计，或许从根本上讲，就在于充分利用起存贮节点上的处理能力，Smart Scan和这里所要提及的HCC，就是两个典型的代表了。HCC中文翻译过来或许就叫做混合列压缩，它是在单纯的行存贮和列存贮之间取得的一个折衷……

关于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次……

既然提到了Flash Cache,如果不提下对OLTP的提速好象会缺少点什么。对OLTP系统而言，缓存是一个极其重要的设计，不管是数据库节点上的内存上的Buffer Cache，还是存贮节点上的Flash Cache（Exadata)，还有数据库节点上的Flash Cache(某些平台，如Linux)……

准备写一系列的文章，专门分析下Exadata的架构。时间真过得很快，自从Exadata问世以来，一直围绕着它做各种各样的性能测试，从V1过渡到V2。Exadata在大踏步地前进着，我总认为，这应该是一个很优秀的产品，而我也相信时间会证明这一点的。
这些文章不会有很严谨的结构，或许某天，某时发现的一个特性，一个特点，一个最佳实践，一个有意思的地方，一个令人惊讶的数据，一个令人鼓舞的图形，都会成为这一系列文章的一部分。
Flash Cache是V2里引入的一个特性，大家或许都认为Flash Cache 主要是用于OLTP场合，为OLTP提高更高的IOPS，这点当然没错，Flash Cache相比于一般磁盘，会带来上十倍的IOPS的性能提升。但即使对于DSS场合，Flash Cache也是提升性能的一个利器……

在做Exadata相关的培训时，Ad-Hoc Query是经常被提及的一个词，中文的翻译应该就叫做随机查询吧，望文生义，就是随机的，不能预料到的查询。但究竟有多随机呢，一些活生生的例子可能更能说明问题。
我们组设计了一个查询，每次show出来的时候，底下总有人暗底里偷笑不止……