Exadata收益分析和性能优化介绍<1>

本文介绍的内容是极少被提及的，第一深入了解Exadata的用户不多，第二大多用户都把Exadata作为银弹。

那么一体机需要分析和优化吗？一体机怎么分析和优化？

本文主要是对Exadata优化服务进行讲解，本文鉴于篇幅原因，并没有提供技术细节，对不住各位技术狂热粉丝。

首先来一幅图镇楼

网络上有很多披露Exadata 某某宗罪的文章，但实际上都是站不住脚的，大部分是在对Exadata一体机了解不深的情况下的断章取义。Exadata在绝大多情况下，Oracle数据库都运行得比以前更快。

但Exadata使用中用户由于对一体机缺乏深入了解，常常遇到几种问题,机能浪费, 收益低, 特性不融合。比较典型的包括：

大炮打蚊子，非常空闲库，  或者纯粹的只有单键值定位数据，或者嵌套链接的库

超跑上烂路，比如反复加载删除大量数据，仅仅是为排重，或者审计，

水火不容，PL/SQL狂耗CPU，却没有多少IO。

现在局面就是，很多用户既不了解应用和一体机的融合度，也不了解买了一体机的收益情况。我们的目标就是帮助客户更好的使用Exadata，让客户的钱全都花出应有的效果。

SMARTIO分析介绍，本分析是全面的分析一体机的独有特性的收益/性能情况，它并不涉及传统的性能分析。虽然传统的RAC数据库性能分析也是和一体机性能优化密切相关的。

SMART IO是Exadata独特而先进的IO机制，但是的确并不是所有的SQL都能够发生SMART IO，同时也不是所有的SQL都适合SMART SAN。我们在优化的过程中，并不是把SMART IO作为“银弹”，需要对具体情况进行权衡，在SmartIO和传统IO机制中找到合适的平衡点，才是对用户最有利的。但总的来说，SMARTIO对分析的SQL的优化是非常明显的，而OLTP类型的作用则小一些。

我们分析的主要层面包括：

•       常规的Oracle数据库性能分析（awrcrt，本文档不讨论）

•       Smart Scan 分析

•       Storage Index 分析

•       Flash Cache 分析

•       Cell事件分析

•       SQL隔离分析

•       HCC压缩分析

下面我们逐一进行说明：

一体机特性相关的主要参数

分析一体机的主要参数，一体机相关的主要参数和隐藏参数，避免由于错误设置，导致SmartIO无法使用。比较典型的错误就是，关闭布隆JION，关闭直接路径读。

SMART IO总体情况-1

一般情况下，physical read/write io=physical readio+physcial write io*3 (IO写实际会发生在多个组件，例如datafile，redo，undo) 这里没有考虑压缩表的情况。

·  physical read write io显示数据库里面所有IO总量，包含了smart scan过滤掉的IO，也就是说里面的部分IO是实际没有发生的，一般来说过滤掉越多越优。

·  pridicate offload io 显示了发生了smart scan的IO，包括了prdicate offload和storage index等特性的IO，这部分占总IO越多越好。

·  cell internet IO 是真实发生的exadata SAN网络中的io，这部分IO包括smartIO返回的IO，以及传统的IO。如果是Smart IO返回的IO，那么这部分IO越小，说明Smart IO的过滤性非常好。

SMART IO总体情况-2

该图表显示了smart scan中，storageindex和cell IO uncompressed 的比例，在非压缩表场景中满足指标1+指标3=指标2

cell IO uncompressed bytes 显示了在smart scan用，在storage index过滤和解压后扫描的数据量

storage index io显示被它跳过的数据量。

Storage index和smart scan共同作用下，大部分的物理IO被过滤掉，没有传输到计算节点。这里我们需要确认，这两种特性都在正常的利用。

SMART IO总体情况-3

显示了在总体的实际发生的IO中，smart返回IO占了多少比例，理论上总IO量合理，smart IO量占比例较大，说系统特性非常适合Smart IO，收益较大。

SMART IO 节省的IO比例

显示了smart scan的IO在总IO中的占比，当然是越大越好

Flash cache的命中率

显示了Flash cache的命中率，我们需要确认flash cache命中率在合理的范围，一般情况上OLTP数据库应该大部分区间都大于90%，大型数据库仓库大于60%。

Flash cache 失败的request

改图可以看出Flash cache中失败或者跳过的request，一般在flash空间耗尽或者active data过多时发生。

Cell IO 等待事件

显示了exadata的主要IO等待事件

cell single block physical read 对应了db file sequence read, 意味着没有使用smart scan

cell mutiple block physical read 对应了db file scatter read, 意味着没有使用smart scan

一般的OLTP的系统中，最主要的读取方式就是db file sequencial read，粗暴的删除索引让SQL offload到存储是非常不科学的方法。理论上唯一键值访问仍然是非常高效的方法，而且它可以从flash cache中获得收益。这里我们需要全面的分析和权衡。

等待次数

等待时间

被Cell拒绝的SmartIO

显示了cell节点由于过载，没有采用Smart IO的数据量，需要注意由于CPU过高，可能是bug导致的smart IO失效。

压缩表分析

这里提供4种分析：

1.  已经采用了压缩，包括传统压缩和HCC的压缩表，修改量较大的表和分区，这部分表可能消耗掉太多的CPU。

2.  还没有采用压缩，但是数据量较大，修改量较小的表和分区，这部分表和分区，建议采用采用压缩技术。

SQL级SmartIO分析

图1这里显示SQLAREA中使用了smartscan的SQL比例，已经满足了smart scan的条件但是实际没有发生smart scan，以及不能发生smartscan的SQL

图2这是显示了使用smart scanSQL的IO总量的，和使用传统IO的SQL的IO总量

图3这里显示了smart scan SQL的每GBIO返回的行数，和传统SQL的每GB IO返回的行数

SQL隔离分析

多次导致smart IO进程终止的SQL会被隔离，不会再采用smartIO。SQL隔离可能导致数据库的smart IO被关闭，需要注意。

Top SQL without smart scan order by physical IO

 显示没有利用到smart IO 而采用了传统IO最多的TOP SQL。这里就可以开始对Top SQL进行单独优化了。

Top SQL less use of storaged index order by usage percent

显示了利用storage index较少的TOP SQL

 Top SQL which flash cache hit point is low

 显示了flash cache命中率低的TOP SQL

完整的SQL 列表

到此，我们在宏观层面上EXADATA收益分析就此结束，接下来还可以结合awrcrt 进行常规的性能分析，确认出现性能问题的区间后，再生成awr，ash，sqlrpt等报告，进行细粒度分析。

以上图表是来源于一体机性能分析工具： exacrt.sql  

exadata auto workload chart report

本文到此结束。

在《2》我们将分析一体机的优化案例。