OS与Oracle

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

direct read是直接把数据块读到PGA的一种操作，在并行查询中这是唯一的模式。这明显地区别于非并行查询把数据块读到SGA的做法。读到SGA的目的主要是为了共享，这特别适用于OLTP场合。不过，与此同时，访问SGA会引入更多的latch等待，例如cache buffer chains, cache buffer lru等等。

在非并行查询中也可以使用direct read，可以通过一个隐含参数_serial_direct_read进行设置。

值得注意，_serial_direct_read对解析过程起作用，这意味着为了使_serial_direct_read对当前运行中的SQL起作用，我们必须先flush当前的shared_pool。

11g中，Oracle有了一个自适应的算法决定是否对serial execution启用direct read。不过，这是在运行时才决定的。它取决于多个统计信息，例如当前buffer cache的大小，_small_table_threshold的大小，当前dirty blocks还占的比例等等。因此，即使在11g中_serial_direct_read的值为false，serial direct read也可能起作用。这个算法其实就叫做Adaptive Direct Read…….

前面分析的主要是Exadata如何高效地进行计算。通过在存贮结点加入数据处理能力，Exdata不仅大大地提升了处理性能，而且解决了以前的Oracle架构上可能存在的CPU和网络的瓶颈问题。

一个Database Machine有8个DB节点，14个Cell (存贮)结点。在V1版本中，一个Cell可以提供1GB/s的带宽，14个Cell节点总共能提供的带宽为14GB/s。对于8个DB节点，每个节点都是两个CPU，每个CPU 4 个Cores。所以一个Database Machine中DB节点总共有64个Cores。

8 DB Nodes + 14 Cell Nodes = Balanced System

这是一个经过实践证明过的平衡的一个配置。
记得今年9月底和阿里巴巴的DBA的一个关于Exadata的交流活动上，新成立的阿里云的同事也到场了。Exadata的架构引起了大家的共鸣，会后一个反应是，有人觉得Exadata与云计算有些异曲同工之妙。其实这也难怪，Exadata本来就是一个关注大规模并行计算的集群系统。特别是智能的存贮节点的引入，更使得每个存贮节点能够分担一个大计算里的一小部分，并且这些智能的存贮节点还有线性的可扩展性，当需要更好的性能时，只要简单地相应增加存贮节点和/或DB节点就可以实现了。这难怪不是一个“云计算”的例子吗……

下一个问题，Exadata如何解决CPU方面的瓶颈呢？

在Exadata之前，我想无非两种思路，第一在原来节点上用更多更强的CPU，第二采用更多的RAC节点。

不过在Exadata的架构中，CPU的瓶颈已经从基本上得到很大的缓解，这就是存贮节点上CPU处理能力的介入……

Exadata应该说代表着Oracle Database未来的发展方向。这句话可不是一句广告词，依我看来，Exadata完全有这个资格享受这种待遇。

一个计算系统，最主要的是追求CPU，IO，Network之间的平衡。使这些计算资源能充分地发挥潜能。比如说，如果IO的扫描能力能达到10GB/s，如果存贮阵列到计算结点的带宽不能达到10GB/s，那么IO的扫描能力就不能得到充分发挥。又比如，如果CPU每秒钟只能处理6GB/s的数据量，10GB/s的IO扫描能力也不能能到充分发挥。

对一个计算系统另一个重要的衡量指标是如何有效地利用计算资源，这同样地包括CPU，IO，Network。比如说，虽然Network可以达到每秒10GB/s的带宽，但如果这些数据都是无效的(与本次操作无关的其它业务数据)，那么这只是对网络带宽的浪费。这就涉及到一个重要的课题：如何高效地利用最少的计算资源在最适当的时候对数据进行操作。

在原来Oracle Database的基础上，为满足上面提到的两个基本点，Exadata进行了富有创新的对基本设施的改进。举一个例子，当数据刚从存贮结点扫描出来时，马上进行初步的加工，把无效的数据丢弃。同时，Exadata推出了一个实现了CPU，IO，Network之间平衡的典型的机器配置。这可以说是Oracle为业界推出了自己在Oracle Database的最佳实践的一个最佳解决方案……

做了几个月的PoC终于降下帷幕，但是几个月来一直是通过SSH到服务器上工作的。
不过，见到它时还是觉得亲切，这台超大发热量的家伙，这台Extreme Performance的家伙……

Materialized Views, 其实不是View。我觉得把它归类于Index可能还准确一些。
View在我们的印象里总是逻辑存在的。即使前面加上一个Materialized，我们只会觉得奇怪，干嘛要对View进行物化呢？
把它理解为一种特殊的Index未尝不可，况且，它与Index有一些相同点：
They consume storage space.
They must be refreshed when the data in their master tables changes.
They improve the performance of SQL execution when they are used for query rewrites.
Their existence is transparent to SQL applications and users…….

如果问我Exadata给我的最深刻印象是什么？我脑海里最先浮现的莫过于每秒14GB的IO吞吐量。还有8个节点上100%的CPU使用率……

Kevin Closson的关于Oracle Exadata Storage Server的一个系列 Frequently Asked Questions，涉及到了Exadata很多方面，使用上的，和其它厂商的比较，底层的实现等等。当然还有很多有用的信息。详见 http://kevinclosson.wordpress.com/kevin-closson-index/exadata-posts/

我们组参加了OOW 2008关于Exadata的准备与演示工作。Greg在他的Blog上有关于这次展示的记录。http://structureddata.org/category/oracle/exadata/……

2006年, 来到了深圳，加入了Oracle亚洲研究与开发中心。
……
2008年初，加入了RealWorld Performance组
……