【读书】Exadata的性能计数器参考

Exadata的性能计数器参考 --- 摘自 《深入理解Oracle Exadata》

1．  cell blocks helped by commit cache

当存储节点进行智能扫描时，数据一致性规则任然必须得以满足，有时会借助于回滚数据。是的，一致性读在只能扫描情况下也必须得以保证。但是智能扫描的整个过程都是在存储节点上完成的，它访问不到位于数据库实例缓存中的回滚数据。同时，在设计上一个存储节点是不会与其他存储节点进行交互的，存储节点不可能从分散到所有存储节点的回滚段中读取到回滚数据。因此，当需要进行一致性读缓存克隆（consistent read buffer cloning）和回滚时，它们必须在数据库层完成。不管什么时候，如果只能扫描命中了一行仍设置有锁定字节的记录（行/块还没有被清理），智能扫描将必须临时地切换到块I/O模式，把整个数据块返回给数据库层，借助于数据库层的回滚数据进行正常的一致性读处理。

注意，当一个块被正确地清理（锁定字节被清除）而且在数据块头中的cleanout SCN比查询开始SCN（snapshot SCN）还早时，存储节点知道不需要对这个数据块进行回滚操作。如果数据块的最新的更改比查询开始时间还早，在存储节点中的块映像将是有效的，它已足够满足给定SCN查询的需要。那么存储节点是如果知道运行于数据库层的查询的开始SCN的呢？这是执行计划中航院（row source）的任务，行源拥有存储节点感知能力，它在启动智能扫描回话时通过iDB协议把SCN传递给存储节点。

现在，当数据块中的一些行的锁定字节缺失有非零值或者块头中的cleanout CSN恰巧比查询的snapshot SCN还大时，存储节点自己就无法确定数据块和数据版本的有效性，因而需要把数据块返回给数据库层以进行普通的非智能扫描式的处理。可想而知，如果存在大量的锁定行和还没清理的数据块，就会显著地降低智能扫描的处理效率。

不过，有一种优化手段，可以用来减少这样讲块I/O处理发送回数据库层处理的次数。不管什么时候，当智能扫描在段扫描期间发现被锁定的行时，它将检查是否有某个事物锁定了该行。这可以通过读取由锁定行的锁定字节所指向的位于数据块头的事物ITL列表中的相应条目得到。注意对于胃痛索引段数据块和HCC压缩数据块，他们并没有为数据块中的每一个单独的行预留一个锁定字节，但道理是一样的----Oracle能够从本市的数据块中找到锁定行（一行或多行）对应的事物ID。现在，智能扫描把这个事物ID返回给数据库层（也就是启动了智能扫描回话的数据库回话），并请求数据库回话检查这个事物是否已经提交。如果该锁定事物还没有提交，只能扫描将为该数据块回退到块I/O模式，数据库层将必须进行正常的一致性读缓冲克隆/回滚体制，没有任何其他的方法可以避免。如果次事务已经提交，只是在某些数据块中留下了一些锁定字节还没清理（这对于大的DML操作时很常见的），那么智能扫描将不需要回退到数据库层的一致性块IO模式。它知道虽然锁定位仍然被设置着，但这些行事实上已经不再被锁定，因为锁定该行的事物已经提交了。¹

这就是读取一个单独行所要发生的一切！当进行智能扫描时，你很有可能要扫描数以百万或千万计的行，而且可能里面许多行的锁定字节还没被清理。你或许不希望智能扫描对每一个锁定的行和数据库层进行如此的交互。这就是Oracle存储节点引入一个叫做“Commit Cache”的内存结构用来缓存关于事物状态信息的原因。它很有可能是一个位于内存的哈希表，以事务ID进行组织，对事务的提交状态进行跟踪。当存储节点看到一个锁定的行时，它将从数据块的ITL部分提取出事务ID，并检查在Commit Cache中是否有关于此事务的信息。这个检查操作将会递增统计数据cell commit cache queries。如果在commit cache中没有这个事务的信息，智能扫描将向数据库层请求这个事务的状态，并把结果存储（缓存）到commit cache 中。理想情况下，每个事务状态只需要一次读取到缓存的操作，接下来的所有检查都可以此commit cache中直接获取。因此当智能扫描打开一个新的数据块，发现一些行被锁定，并借助commit cache，成功避免了与数据库层的一次交互是，cell blocks helped by commit cache这个统计数据的值就会得以更新（加1）。

当回话在继续只能扫描时，如果看到这个统计数据的值一直在增长，那么它表明存储节点正在检查被标识为锁定的行是否仍然处于锁定状态，这个操作会有一些资源消耗，但是正是由于commit cache，才得以避免和数据库层进行重复交互的需要。如果没有此项优化，整个智能扫描将会变得更慢，因为它必须不断地和数据层做交互。在数据库层你也会看到更多的逻辑IO操作（观察以consistent gets from cache开头的统计数据），而正常情况下，针对一个段，只需要一个LIO去读取段头，以得到High Water Mark一下的各个extend的为止和数据块数目的信息。

注意 类似的优化实际上也存在于数据库层，还有费Exadata的数据库上。Oracle可以把已提交事务的信息缓存到数据库回话的私有内存中，因此当命中锁定行时，将不需要执行对回滚段头的缓冲读取（buffer gets）操作。只要一个回话把已提交事务的状态信息缓存到内存中，它就会对在V$SESSTAT中的Commit SCN cached统计数值进行“加1”操作。只要它对此缓存执行一个查询操作，它就会对Cache Commit SCN referenced 统计数值进行“加1”操作。

如果对Oracle的延迟块清理机制不熟悉，可能会想知道当事务已提交时，怎么可能还存在锁定字节被设置的行。这是Oracle区别于其他大多数主流商用RDBMS产品的地方。Oracle不需要吧还未提交的行所对应的数据块始终缓存在内存中，DBWR可以自由地把他们写会磁盘，从而释放出内存以供其他数据块使用。现在，当提交事务是，从磁盘中把所有相关的数据块重新读回内存以清除锁定字节就不是一个好方法了。如果这种块很多，提交动作可能要花很长时间才能完成。以此相反，Oracle只是在回滚段头槽中标志此事务已经完成。以后的块访问者将通过回滚段头槽检查此事务是否仍然处于活动状态。如果之后通过IO把这些数据块读取到数据库层，那么这些读取会话将会对这些块进行清理（清理已提交事务所修改的行对应的锁定字节），因此再以后的读取将不再需要进行事务钻头的检查。然而，存储节点并不会执行块清理，因为存储节点不会对数据进行修改。这是因为数据库块的修改需要重做操作的写入，而重做日志已经由数据库层进行管理并打散分配到所有的存储节点上，存储节点怎么可能实现对重做日志的写入呢？

注意对于小事务，它不会修改很多的数据块，而且数据块仍然位于缓存中，Oracle将会在提交的时候执行对块的清理工作。同时，上文所讨论的问题并不适用于某些数据块（如数据仓库），在这种数据库上，表时通过直接路径加载实现数据的插入的（并且索引分区也是在表分区加载完成后才创建的），因此对于直接路径加载，在新格式化的数据块上并没有对行进行锁定（同样地，数据加载完成后的索引创建也没有对索引叶节点上的索引条目进行锁定）。

2．   cell blocks helped by minscnoptimization

Exadata存储节点还有另外一项优化技术，用来进一步改进一致读的效率。这就是所谓的Minimum Active SCN优化，它对数据库中任何任然处于活动状态（未提交）的事务的最小的SCN进行跟踪。这允许我容易地对锁定事务的ITL条目的SCN号与数据库上最“老”的活动事务所对应的最小的SCN号进行对比。因为Oracle数据库能够在启动一个智能扫描会话时把MinSCN的信息发送给存储节点，只要存储几点收到的这个已知的最小活动SCN号高于数据块中的事务ITL条目中的SCN，存储节点就能够避免与数据库层的交互²。只能扫描对一个块进行处理，发现某一行被锁定，并在ITL槽中有相应的活动事务，通过与数据库会话传送过来的MinSCN信息做对比，它认识到这个事务一定提交了，统计数据cell blocks helped by minscn optimization就会加1（对于每一个数据块）。

如果没有此项优化，Oracle必须检查commitcache，如果在commit cache 中没有此事务的相关信息，就必须与数据库层进行交互，以确定锁定事务是否已提交。这个优化适用于RAC环境，事实上Minimum SCN也被叫做Global Minimum SCN，每个实例上的MMON进程会跟踪MinSCN的信息，并且每个实例的SGA中有一个内存结构用来实现此信息的同步。可以通过查询x$ktumascn（使用sys用户查询）视图得到当前已知的global Minimum Active SCN。

cell blockshelped by minscn optimization也是一个必须过多关注的统计数据，但在诊断高级的智能扫描问题，甚至是bug时，它可能会派上用场，比如说在某些情况下，智能扫描看起来被中断了，因为它们必须回退到IO模式，并和数据库有太多的交互。

3．  cell blocks processed by cache layer

cell blocks processed by … layer统计数据是衡量存储节点上卸载处理深度的很好的指标。Exadata存储节点的主要优势在于Oracle内核的部分代码被移植到运行于存储节点上的cellsrv可执行文件上。这就运行Oracle数据库层把数据扫描、过滤盒投影工作下放到存储节点上执行。为了实现此目的，存储节点必须能够读取和理解Oracle数据块及其中所包含记录的内容，就如数据块层所做的一样。与最后返回数据库层的数据块数目不同，cell blocks processed bycache layer统计数据显示的是存储节点已经处理（打开、读取和用来智能扫描）的数据块的数目。

当存储节点只是把数据块以块IO的模式返回给数据库时，这个统计数据并不会更新。但当存储节点本身把这些块用于智能扫描时，打开数据块（一致读和当前读）首先做的第一件事就是对数据块缓存层头部进行检查。这是为了确保数据块是正确的，没有顺坏，是有效的和一致的。这些测试由缓存层函数（KCB代表Kernel Cache Buffer管理）实现，并以统计数据cell blocks processed by cache layer的形式报告给数据库。

在数据库层，取决于用来实现一致缓存获取的bufferpinning代码路径，常规块IO所对应的统计数据时consistent gets from cache和consistent gets fromcache（fastpath）。注意cellsrv只是执行一致模式的缓冲获取（CR获取），并不执行当前模式的块读取。因此在统计数据中所看到的所有当前模式获取都是在数据库层完成的，并被报告为db block gets from cache或者db block gets fromcache（fastpath）。可以使用这个统计数据简单的衡量cellsrv为用户会话执行了多少逻辑读。

4．  cell blocks processes by data layer

这个统计数据统计的是存储节点上数据层所处理的块的个数。它只负责对表数据块及物化视图数据块（这些物理上就像表数据块一样）读取的统计。这些信息由数据库层模块进行收集，被称为KDS，即Kernel Data Scan的缩写，它能够从表数据块中抽取出行和列，并把它们传递给各种验算函数进行过滤盒条件检查。如果存储节点智能扫描可以再存储节点上完成所有的处理，不需要回退到数据块IO模式，那么统计数据cell blocks processed by data layer的值加上统计数据cell blocksprocessed by index layer的值应该等于统计数据cell blocks processed by cache layer的值。这意味着对于打开的每一个数据块，它通过了缓存层和事务层的检查，被传送到数据库层或者索引层完成行和列的抽取操作。如果processed by data layer加上processed by indexlayer的和小于processed by cache layer，那么则意味着剩下的数据块不能在存储节点上进行所有的处理，必须发送到数据库已进行通常的块IO处理。

5．  cell blocks processed by index layer

这个统计数据与cell blocksprocessed by data layer类似，但只在对B树获知位图索引段的数据块进行智能扫描时，此统计数据才会增长。从索引段中抽取数据行的代码路径不同于数据段。cell blocks processed by index layer统计智能扫描处理的所有段的数据块的数目。

6．  cell blocks processed by txn layer

这个统计数据显示存储节点事务层所处理数据块的数目。下面是存储节点上执行智能扫描一致读取时所发生的动作序列的简化描述：

（1）      缓存层（KCB）打开数据库，检查它的头部信息，最后更改SCN号，清理（cleanout）状态。

（2）      如果存储节点上的数据块在运行当前智能扫描的查询所对应的快照SCN之后没有被修改过，这个数据块会被传送到事务层进行处理。然而，如果磁盘（存储节点）上的块映像在此查询的快照SCN之后被修改了，缓存层会认识到为了进行一致性读，这个快必须进行回滚。这种情况下，这个块不会被传送给存储节点上的事务层，存储节点会回退到块IO模式，把这个块直接返回给数据库层以进行普通的CR处理。

（3）      如果数据块有缓存层传送给了事务层（KTR），当碰上锁定行或者已经提交事务的未清理块时，事务层会使用commit cache和MinActiveSCN优化技术减少和数据库层的交互次数。当不需要回退到块IO进行数据库层的一致读取时，将由存储节点内部的数据库层或者索引层进行一致读操作。然而，如果不能在存储节点内部完成一致读，整个数据块将必须传送回数据库层，并在那里进行一致读操作（总体而言，一般的数据流向是这样的：缓存层à事务层à数据层或索引层）。

上面描述说明的一点是，如果智能扫描一切顺利时，在进行智能扫描过程中将不需要中断其工作和数据库层进行交互，理想情况下所有的扫描工作都在存储节点上完成，一旦准备好了足够的数据，它们就会以批量的方式返回给数据库。这种情况下，统计数据cell blocks processed by data layer（或者index layer）的值就会等于cellblocks processed by cache layer（还有txn layer）的值，这表明所有的数据块可以在存储节点上进行完全出来，所有的行抽取工作可以不必回退到数据库层的块IO和一致读模式。

记住存储节点上关于一致读的所有这些复杂的过程只有在执行智能扫描时才会发生。当进行一般的块IO时，存储节点只是把数据块直接返回给数据库层，一致读逻辑会像平常一样在数据库层执行。一般情况下不用担心这些指标，除非看到只能扫描事件总是穿插着cell single blocksphysical reads，并显著地占用了查询的响应时间。

7．  cell commit cache queries

这是智能扫描从存储节点上的commit cache 哈希表中寻找事务状态的次数。对于只能扫描的每一个数据块所发现的每个未提交事务，除了能够利用MinActiveSCN优化技术避免对事务状态的检查之外，通常需要进行一次对commit cache的查找。这个统计数据与cell blocks helped by commit cache紧密相连。

8．  cell flash cache read hits

这个统计数据显示有多少个IO请求由存储节点闪存提供，从而不需要进行硬盘读取。注意，这里说的是“硬盘读取”，而不只是物理读。这是因为从闪存卡的读取也属于物理读（导致闪存卡IO的系统调用）。当观察这个指标时，它表示所需的数据块不在数据库层的缓存中（或者选择的是直接路径读取的访问路径），但幸运的是该IO请求所需要的所有数据块都在存储节点闪存（正是的名字叫做Exadata智能闪存）中。注意这个指标代表的是IO请求的个数，而不是从存储节点闪存读取的数据块数目。记住存储节点闪存既可用于普通的块读取，也可以用于存储节点智能扫描。特别是当在Exadata上运行OLTP数据库时，为了取得最好的性能，应该尽量使用数据库缓存或者存储节点闪存（如果数据库缓存不足时）以满足绝大多数单块读的需要。

9．  cell index scans

当灭此智能扫描开始对一个B树或者位图索引段扫描时，这个统计数据就会递增。注意为了实现索引段上的智能扫描，执行计划行源（row source）操作符index fast full scan必须和直接路径读取一起使用。这个统计数据在智能扫描会话开始时进行更新，因此如果要监控一个已经运行了一段时间的长查询会话，可能无法发现会话的这个统计数据有所增长。

当串行会话对非分区索引段进行智能扫描时，这个统计数据的值只会加1。然而，当对分区索引段进行智能扫描时，cell index scans的值对于每个试样了智能扫描的分区都会加1.这是因为智能扫描时在运行节点，根据每个不同的段（表、索引或者分区）所做出的决定。因为智能扫描只有在把数据直接路径读取到PGA时才会生效，而是否进行直接路径读取又是基于所要扫描段的大小（还有其他一些因素），因而相同表的不同分区可能采用不同的方式进行访问。可能会发现多分区表或索引里的一些分区没有使用智能扫描/直接路径读取，这是由于这些分区比较小，Oracle决定对他们采用缓存读取的方式。这种情况下，在ASH或者SQL监控报告的执行计划中关于表/索引扫描行源(row source)对应的等待事件，就会看到更多的cell multiblock physical read，而不是cell index scans。

10．             cell IOuncompressed bytes

这个统计数据显示的是存储节点中扫描的数据解压后的大小。因此，如果在扫描一个10GB的压缩段，统计信息physicalread total bytes将会增大10GB，而如果解压后的总数据大小是100GB的话，cell IO uncompressed bytes就会增大100GB。这个统计数据只有在只能扫描执行解压的操作时才会增长，当以块IO的方式直接把压缩块返回给数据库层时这个值并不会改变。

11．             cell num fast response sessions

这个统计数据显示以下行为的次数：Oracle开始智能扫描代码，但接着决定并不立刻就开始配置智能扫描回话，而是先进行一些数据块IO操作，以期找到足够的行以满足数据库回话的需要。此项优化被用于执行计划中的FIRST ROWS选项，可以使用提示FIRST_ROWs_x(或者等价的init.ora参数)，或者使用条件WHERE rownum < X来控制执行计划中的First Rows选项的采用与否。它的原理是，如果执行计划只是获取几行，Oracle希望避免在存储节点上配置智能扫描回话（由于ASM镜像，智能扫描会话会在所有节点上启动）带来的开销，于是，它会先试探性地进行一些常规的块IO操作。

12．             cell num fast response sessionscontinuing to smart scan

这个统计数据显示以下行为的次数：Oracle已经启动了存储节点智能扫描快速响应会话没，但接着却必须切换成真正的智能扫描会话，因为先前有限的几次IO操作没有找到足够的匹配行。

13．             cell num smart IO sessionsusing passthru mode due to reason

这三个统计数据（其中reason可以是user、cellsrv或者timezone）代表Oracle数据库启动了智能扫描，但cellsrv却由于各种原因不能够进行智能扫描，从而回退到块IO模式的次数。数据块只是通过cellsrv传递给了数据库，而不会在存储节点上对它们进行处理。这意味着虽然可以看到cell smart scan和cell physical IO interconnect bytes returned by smart scan一直在增长（它代表正在发生智能扫描），但智能扫描的全部威力并没有得到完全利用，因为存储节点只是读取数据块，并把它们返回给数据库层。换句话说，在passthrough模式下，存储节点没有打开数据块对匹配行所要求列进行抽取，而只是把相应段的所有物理块原封不动地返回给数据库层。注意存储索引（动态创建于cellsrv的内存中）也可以被用来减少passthrough模式下的IO，但这些存储索引必须由一般的智能扫描所创建，也就是在那些存储节点上真正地打开数据块并对其进行处理的智能扫描。

在最新版本的数据库和Exadata存储节点上，不应该看到任何的passthrough的只能扫描，除非存储节点碰到了类似内存用尽的问题。可以在测试环境中通过设置_kcfis_cell_passthru_enabled为TRUE观察智能扫描将会发生什么。仍然会看到cell smart scan的等待事件，但它们会运行得比原来慢，因为它们只是把所有的数据块发送给数据库进行处理。

14．             cell physical IO bytes eligiblefor predicate offload

这个性能数据器包含着对于理解存储节点只能扫描非常重要的一个统计数据。当对一个段进行智能扫描时，这个统计数据显示智能扫描遍历这个段的字节数。从本质上讲，从段头开始直到高水位线的所有字节都会被统计（随着扫描逐步遍历整个段）。问题的关键在于这是扫描所能达到的理论的最大字节数，但是有时存储索引优化技术会发挥作用，它允许跳过对某一些数据块范围的扫描。不过即使存储索引避免了对10GB的段的80%的扫描量，把真正发生的IO数量减少到2GB，这个统计数据还是显示扫描段的总大小，与任何优化技术的采用与否无关。换句话说，这个统计数据显示的是没有采用任何存储节点级别的优化技术（经常是这种情况）时本应该扫描的总字节数。注意这个统计数据只是简单地计算数据文件中数据块的物理大小（而不是通过解压、过滤、投影后的“最后的”数据大小）。

如果这个数字在回话的VSESSTAT（对于整个实例则是Statspack/AWR数据）中没有增长，那么它是另一个没有用上智能扫描的标志。任何智能扫描会话对数据块范围的扫描（即使由于存储索引优化技术跳过了这些数据块范围）都会相应地增大这个统计数据。另一个需要知道的事情是当智能扫描回退到passthrough全块搬运模式时，cell physical IO bytes eligible for predicate offload仍然会增大，即使在此模式下存储节点并没有进行谓词卸载和智能扫描过滤。

15．             cell physical IO bytes pusheddue to excessive CPU on cell

这个统计数据与选择性地回退到passthrough模式有关，这个数字越大（与统计数据cell physical IO bytes eligiblefor predicate offload相比），代表存储节点会把更多的压缩CU（Compressed Unit）发发送回数据库层进行解压缩和处理。当存储节点的CPU利用率达到阀值，而在数据库层却有足够多的空闲CPU能力的时候，这个情况就会发生，它允许用户更好地利用起整个Exadata集群的CPU能力。

注意这个性能计数器首先出现在11.2.2.3.0版本的存储节点软件和BundlePatch 6的数据库中。显然这个是一个临时的one-off fix，因为这个统计数据代替了V$视图中的临时的spare statistics 1计数器。事实上，在Oracle11.2.0.3（和Exadata Bundle Patch 7）中，这个统计数据被更名为“cell physical IO bytes sent directly to DB node to balance CPU usage”。

16．             cell physical IO bytes saved bystorage index

这是另一个重要的统计数据，它显示由于cellsrv位于内存中的存储索引的存在，智能扫描会话直接跳过磁盘读取所节省的扫描字节数。如果这个指标cell physical IO bytes saved by storage index的值接近于cellphysical IO bytes eligible for predicate offload，它表示智能扫描大大受益与存储索引，由于存储索引避免了对磁盘的读取。

17．             cell physical IO bytes saved duringoptimized file creation

这一统计数字显示在存储节点上完成的数据文件创建和文件扩展的字节数。如果没有这项优化技术，Oracle将在数据库会话的PGA中对数据块进行格式化，在通过内部网络把物理块写回存储节点。在Exadata上，文件数据块的格式化和写入可以被下放到存储节点上，数据库本身不需要进行物理写入操作。当存储节点在为新文件格式化数据块或者扩展文件时，将会看到等待事件cell smart file creation。如果没有这项优化，将只能看到等待事件Datafile init write。

18．             cell physical IO bytes savedduring optimized RMAN file restore

这一统计数字显示在存储节点上王城的数据文件还原（restore）的字节数，由于把RMAN还原操作下放到存储节点上执行，所有不需要数据库层的参与。当在Exadata执行还原操作时，将会注意到恢复会话的等待事件是cell smart restore from backup。

19．             cell physical IO bytes sentdirectly to DB node to balance CPU usage

这个统计数据与cell physicalIO bytes pushed due to excessive CPU on cell类似，在Oracle11.2.0.2和Bundle Patch6使用先前的统计数据名字，而在新的数据库版本和补丁级别上则使用这个新的统计数据名字。

20．             cell physical IO interconnectbytes

这是一个简单而又基础的统计数据，它显示存储节点和数据库会话之间已经传输的数据总字节数。这包括数据库发送和接收的所有数据、智能扫描结果集、从存储节点读取的完整数据块、临时的IO读取和写入、日志写入（LGWR）、任何附加的iDB流量，等待。因此，这个统计数据显示了所有的流量字节，而与其方向，内容或者性质都没有关系。

当衡量写入IO指标时，可能会看到统计数据cellphysical IO interconnect bytes是physical write total bytes的2或3倍。这是因为后者是在Oracle数据库级别进行的度量的，而cellphysical IO interconnect bytes是在存储节点层次度量的，它发生在ASM镜像之后。因此，举例说明，如果LGWR把1MB的数据写到高冗余级别（三重镜像）的ASM磁盘组上，将总共3M的数据流经内部网络。注意在Oracle 11.2.0.1中有一个Bug（#10036425），即使在非Exadata数据库中这个统计数据也会增长，在非Exadata数据库上可以简单地选择忽略这个统计数据。

21．             cell physical IO interconnectbytes returned by smart scan

这个统计数据非常重要，它显示智能扫描返回给数据库层的字节数。实际返回的字节数应该从磁盘扫描/读取的字节数少很多。这是Exadata智能扫描特性的主要特点---存储节点每秒可能会读取GB级的数据，但由于谓词卸载对数据进行了早期过滤，它们可能只返回少数的行给数据库层。此外，由于投影卸载机制，智能扫描只返回所有要求的列，而不是完整的行。当然，如果应用程序使用SELECT *获取一个表的所有列，投影卸载将不会有所帮助，但是谓词卸载引起的早期过滤仍然会有很大的帮助。

这个统计数据时cell physicalIO interconnect bytes的一个子集，它只统计智能扫描返回的行机的字节数，而不包括其他流量。

22．             cell scans

这个统计数据类似cell indexscans，但cell scans显示的是在表和物化视图段上完成的智能扫描次数。对于串行执行，这个统计数据只在每个段扫描的开始加1。而当扫描一个分区表时，由于每个分区是一个独立段，这个统计数据对每个分区都会加1,。对于并行扫描，cell scans则会增长得更快，因为并行子进程是基于查询协调进程分配给它们的数据块范围（PX granule）进行扫描的，所有对每个数据块的范围扫描都会当成一个独立的cell scans。当出现统计数据table scans（rowid ranges）时，它表示基于数据块范围的PX扫描正在发生。

23．             cell smart IO session cachehits

这一统计数字显示数据库会话重用存储节点上一已经初始化好的智能扫描会话的次数。当一个串行的执行计划扫描多个段（如分区表）或者重新访问同样的段时，这个统计数据就会发生变化。

24．             cell smart IO session cachelookups

当每次数据库会话舱室重用一个在存储节点上先前初始化好的只能会话时，这个统计数据就会相应增长。如果cell smart IO session cache hits也同步增长，则这个寻找是成功的，先前的会话可以被重用。智能IO会话缓存只在一个打开游标的执行计划内（和接下来的获取）有效。一旦执行计划完成，接下来的执行（即使对于相同的游标）必须设置新的智能扫描会话（并把新的一致读快照SCN也一起发送给所有存储节点）。

25．             cell transaction found incommit cache

这一统计数据与Oracle必须保证的一致读机制有关，在Exadata上也不例外。它显示为了决定是否需要CR回滚，智能扫描会话检查存储节点commit cache的次数，它会在存储节点的commit cache中查找事务的状态信息。这避免了到数据库层利用那里的回滚数据检查的事务状态的一次交互。

26．             Chained rows processed by cell

在解释这个特定统计数据的意思直线，先看看智能扫描是如何处理链接行的。链接行给智能扫描提出了一个问题。链接行的“下一个”行片断（row piece）可能位于段中的任何地方，由于ASM的条带化，并不能保证链接行的下一个行片断位于与行头片断相同的存储节点上。因为一个链接行可能物理上被分割在多个不同的存储节点上。由于存储节点间是相互独立的（为了扩展性和简单性），怎么样才能在需要的时候构造出完整的一行呢？cellsrv当前解决此问题的方法是只要智能扫描碰到了链接行（并认识到必须获取它的下一个行片断），针对该行cellsrv将回退到一般的块IO模式并把数据块返回给数据库层进行正常的处理。接着数据库层从行头片断中取得下一个行片断的数据块地址，并向相应的ASM条带化后的实际放置该数据块的存储节点发出块IO读请求。这个优化技术背后的原理与根本问题类似于为什么一致读回滚必须在数据库层而不是存储节点上完成---因为此操作所要求的有些数据块可能刚好位于另一个存储节点上，而存储节点间是互不交流的。

这一行为意味着如果智能扫描碰上了很多链接行，而且必须获取它们的下一个行片断时，智能扫描性能就会下降。如果运气很好，只需要访问位于行的头片断中的那些列，对于这些块将不需要回退到数据库块模式，智能扫描还是会很快。然而，如果必须获取下一个行片断，智能扫描将会不断地回退到块IO模式，数据库层随之进行逻辑读（可能还有单块物理读，如果这些块还没被缓存到缓冲池中）。这意味着查询等待的大部分时间用来进行随机的单块读取，而不是高性能的智能扫描。

现在，回到统计数据chained rowsprocessed by cell上，它代表智能扫描碰到了一个链接行，并且该行可以在该存储节点内部进行处理。这个统计数据只会在块内部链接（intra-block chaining）的特殊场合下才会增长，这种情况下，链接行的下一个行片断存储在与当前行头片断相同的数据块中。块内链接被用来存储对于255列的行。在这些情况下，存储节点注意到它只需要从相同的已打开的数据块中获取行的剩下内容，而不必回退到数据块IO模式对链接行进行处理。

注意链接行的性能问题仅适用于常规的数据块和那些以常规的块级压缩方式（LOAD或者OLTP）进行压缩的数据块。幸运的是，EHCC压缩的表完全没有这个问题，因此对于EHCC，行和列有不同的物理组织方式。还有，这个问题也不适用于对迁移行（这种情况下，整一行由于更新的原因被移到另一个数据块中，只留下一个存根片头）的全段扫描。这种情况下全扫描/智能扫描会直接跳过迁移行的片头，因为整个行物理上可以在其他地方找到。注意对于HCC压缩的表，虽然对链接行的扫描没有问题，但对HCC压缩表的更新却会引起其他的性能问题。

行链接另一个有趣的地方发生在当一个表的列数多于255时。即使一个单独的块足以容纳完整的一行，但对于超过255列的行，Oracle任然会进行块内链接---行被链接起来，不过所有的行片断都物理地位于相同的块中。这是必需的，因为当Oracle在8.0版本中把255列的限制增加到1000时，必须维持向后的兼容性。一个行片断的“列数”字节由一个字节组成，因而每个片断只允许255列，但由于链接，在接下来的行片断中可以有更多的列。起初这造成了Exadata智能扫描的性能问题，那是，即使是块内行链接也会导致大量的单块读。然而，这个Bug（#9291589）已经在Oracle11.2 Exadata Bundle Patch4（BP4）中得到了修正，应该不会再碰上它。这是一个诊断起来非常有趣的问题，如果对更多的细节感兴趣，包括整个诊断过程，可以进一步阅读Tanel的相关文章“Troubleshooting Exadata Smart Scan”：http://blog.tanelpoder.com/oracle/exadata/trobleshooting/。

27．             chained rows rejected by cell

这一统计数据显示存储节点不能处理的链接行的数目。目前任然不清楚这里采用“拒绝”（rejection）这个词，而不是“跳过”（skipping）一词的确切原因。在测试中，大多数的链接行都会造成这一统计数据的增长。目前假定“拒绝”只是在存储节点上不对链接行进行处理而回退到数据库层块IO模式的一个特殊情况。

28．             chained rows skipped by cell

在诊断由于行链接引起的智能扫描“被迫”采用单块读问题时，这是一个主要的统计数据。

总之，如果发现智能扫描在等待大量的cellsingle block physical reads，并且数据库层在执行逻辑IO（consistent gets from cache），一个要检查的事情就是这些统计数据，以确定是否遭遇了必须在数据库中进行处理的链接行。当然，不要忘记智能扫描只会卸载对大尺寸对象的扫描负载，如果查询计划中包含了其他的行源（row source），如索引范围扫描，或者对小的已经缓存的表的扫描，那么看到逻辑IO伙计单块物理读则是理所当然的。幸运的是，可以使用来自ASH、V$SESSTAT或者SQL Trace的等待借口数据查看这些单块读取访问的是那些对象。ASH里的current_obj#和原始SQL跟踪文件里的obj#字段指的就是会话正在读取的表（或索引、分区）的object_id。

29．             physical read requestsoptimized

这一统计数据显示了由于从闪存直接读取，或者由于存储索引的作用，得以避免的对磁盘的IO请求次数。这个统计数据会传送到V$SQL/V$SQLSTATS和V$SEGMENT_STATISTICS的视图。

30．             physical read total bytesoptimized

这个统计数据显示了由于从闪存直接读取，或者由于存储索引的作用，得以避免的从硬盘读取的字节数。当看到cell physical I/O bytes saved by storage index统计数据也增长了相同的值时，就意味着存储索引完全避免了物理IO。如果存储索引所节省的IO小于总的优化字节数，那么剩下的优化IO部分则是从闪存读取中获得的，而不是通过传统硬盘（但是在内部仍然会发生对闪存卡的IO）。有趣的是，这个统计数据并不会被发送到V$SQL/V$SQLSTATS和V$SEGMENT_STATISTICS视图（起码对于11.2.0.2的Oracle而言）。

31．             table fetch continued row

这一统计数据并不是特定于Exadata的，但和智能扫描时发生的意外数据库单块读密切相关。这一统计数据统计Oracle获取链接行的下一个行片断（使用常规的单块读）的次数。

32．             table scans（direct read）

这一统计数据并不特定于Exadata的，在任何一表段上使用直接路径读取进行全扫描的Oracle数据库上都可以看到它。在串行执行期间，这个统计数据在表扫描开始时增长，但对于并行执行，当每个子进程开始扫描分配给它的一个新的rowid范围时，这个统计数据就会增长。直接路径读取是智能扫描发生的前提条件，因为如果查询没有用上智能扫描，应该坚持一下是否使用了直接路径读取对表进行扫描。

33．             table scans（long tables）

这一统计数据显示所扫描的表是否是一个大表。事实上，Oracle对于每个段都会单独考虑。因此一个表的一些分区了能被认为是小的，而有些会认为是大的。如果一个段（直到高水位线）比缓存的10%还大，则备认为是大的，从而会采用直接路径扫描，对于串行扫描也是如此。（但注意同时还会考虑其他因素，如果这个段已经有多少块位于缓存中了）缓存的10%这个规则实际上来自参数——small_table_threshold。这个参数默认是缓存大小的2%（块数），但Oracle使用5 x _small_tale_threshold作为发生直接路径扫描的阀值。