OS与Oracle

本文要分析的是下面这个SQL，执行了半个多钟头还没返回结果。
Wait events 是了解Oracle运行状态的一个重要途径。对于某个具体的SQL，SQL Monitor Report提供了drill down的方式得到这个具体SQL在运行中的wait events的分布情况，下面是SQL Monitor Report的相应图形。
这里最突出的等待事件是enq: TS – contention，这是关于临时segment的等待事件，这可能是一般的表空间的争用(例如并行直接路径加载数据)，也可能是临时表空间的争用(例如为了hash join或者sort)。那么这时临时表空间的增长状态是怎么样子的呢？SQL Monitor Report提供了这方面的信息……

随着业务的发展，IT部门的服务器数量会越来越庞大，另一方面，这些服务器的利用率却得不到充分利用，于是，服务器的资源整合就被提上了议事日程，这方面的相应的解决方案一般有
Hardware Partitions,
O/S Workload Managers,
Virtualization
等等。
在11gR2中，Oracle也提供了一种简单有效的方法实现对服务器资源的整合，这就是Instance Caging技术……

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

构建DSS系统的第一步离不开数据加载，通过文本文件加载是最常见的方式，Oracle提供了外部表加载的方法，即把一个文本文件当成一个正常的表来进行操作，通过类似insert /*+ append */ into table select from external_table的方式进行加载。
数据加载是一个CPU-Bound的过程，不过是通过什么工具，external table也好，sqlldr也好，imp也好，impdp也好。
这个过程的AWR报告会是怎么样子的呢……

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的最佳实践的一个最佳解决方案……

在10G, Oracle已经有了Database Resource Manager，在数据仓库中，有两个系统资源非常重要，它们可以通过DBRM进行控制，它们就是Active Sessions和DoP(Degree of Parallelism)。一般而言，不同的工作负载会有一个最优的Active Sessions和DoP。甚至于有时必须对工作负载再进行细分，分别应用不同的策略(active sessions + DoP)。这有时是一个烦琐的调优过程。

在即将到来的11G中，有两个新的特性，Auto DoP和Statement Queuing机制。相信对上面的DBRM会带来一定的冲击。

“Storage Index”，对Oracle中已有的Index大家耳熟能详，B-Tree Index, Bitmap Index。这些都是基于行的，有没基于更大的存贮单元的呢？例如1M的存贮区域？Storage Index来了，这以于Cluster的列而说，pruning功能会使一个查询提高成千上万倍。这可能又是一个后来者居上的特性。

“Hybrid Columnar Compression”, 不甘落后的，又一个Oracle新引入的技术。对于数据仓库查询这无疑是天大的福音。

还有很多很多……

就让我们一起疯狂吧……

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