意外出现的smart scan
近日，客户CRM系统上线，平稳运行，宣布提升数倍的性能，所有IO指标全部呈现为us级别，顺序读，散列读提升16倍之多，之前8ms，现在500us.
循例我们会对各个storage cell的指标进行一遍检查，在检查完最大的一个8计算节点的机架后，一切正常。检查到第二个6计算节点机架的cell节点时候，突然一个指标引起了我的注意：
tip：通过list metrichistory来查看性能数据
cell节点的CPU，居然一直维持到20%上下
而另外一个机架的CPU，大部分时候只有不到5%，而这个机架的的业务量更大。
进而观察每秒钟4G/s左右的smart scan，也就是说平均秒就发生了4G的存储扇区被smart scan机制扫描过。
虽然这部分IO（银弹），和传统的IO有极大的不同，它们大部分是被skip掉的IO，但是依然会消耗掉存储节点的计算资源。下图看出，从SAN网络返回的实际数据并不多，百分之一不到。
在之前的SPA测试中，以及对老生产预分析中，并未见有类似的SQL会引起这个数量级的smart scan。而且在CRM之类的OLTP典型数据库中，single block read 应该依然是工作日时段的主要IO类型。于是，运行了awrrpt，awrcrt，exacrt等工具，的确发现了大量的smart scan io
cell smart table scan挤入了top3
在短短1.5小时，单个实例产生了84T的smart IO
再下钻，发现smart scan来自一个类型SQL
对一个28GB大小的表做全表扫描，在一个半小时内运行了接近400次，单次运行时间在1~2秒。检查执行计划，改SQL只能走全表扫描，无适当索引。SQL分析过程略过不提。
这里展示了exadata smart scan非常强劲的特点，全表扫描一个28G的表，只需要1~2秒。
在一个OLTP系统里面，仅仅一类SQL（3条）就把全部cell storage的CPU吃掉1/5，这一定不是一个好的应用逻辑。全表扫描这个表，从interconnect看返回的数据量看，全表扫描也肯定不是最佳实践（一定可以有索引）。但为什么在新系统里面会出现这种情况？
通过检查迁移以前的awr报告发现该SQL在原系统中，执行一次需要600~800秒（老式emc集中存储，合理的速度），一天总共才执行几十次。这样终于恍然大悟。
应用的逻辑和数据量，决定这个SQL运行缓慢，但是长达800秒的运行时间也可以满足要求，该SQL就24小时循环不间断的扫描，一天也跑不了多少次。但迁移到一体机，改SQL迅速就被smart scan提到光速，而应用的循环调用是没有流控的，所以突然猛烈增加到7200秒内运行成功了4000次！
问题提交应用团队后，当晚smart io断崖式“消失到”合理的水平，CELL CPU利用率降低到5%
smart IO是银弹，但好刀要用到刀刃上，虽然它可以掩盖掉很多低效SQL。但这个CASE的一条SQL就消耗掉20%的资源是不可取的，同时也是资源的大浪费。索引+buffer cache+flashcache依旧是OLTP系统访问最快的途径。优化的时候需要注意在计算节点资源和存储节点资源上，获得“平衡”。
smart scan 去哪了？
前年某制造业公司核心数据库，巡检发现，smart io 几乎=0
图出现smart IO的峰值是数据库在收集统计信息！
虽然是一个OLTP的系统，但是出现smart io=0的情况是非常罕见的，难道已经被优化得是纯粹的走索引的系统？但在awrrpt报告中，有出现了大量散列读
难到客户的表都是小表，又或者客户的buffer cache很大？都不是。
为什么全表扫描都不发生了smart scan，在对所有参数，cell属性，asm磁盘组属性都逐一检查后，都不得其解。
最后，经过仔仔细细，反复反复的核对配置，终于发现
凶手 10949
隐藏参数”_serial_direct_read” 指定了是否启用串行全表扫描下的直接路径读取
“As of 11.2.0.2 the legal settings are
true, false, always, auto, and never
true is the same effect as always
false is the same effect as auto
Default value is “auto”
Setting event 10949 or event 10354 may also have the side effect of making oracle behave as if _serial_direct_read = never”
10949 EVENT事件也可以起到类似的作用。
这两个CASE给我们的提示是，smart scan的确是一种能够极大提升数据库系统运行效率的武器，但是它的最佳实践也是依赖于用户的应用场景的。我们可以简单判断，在OLTP系统中，exadata的主要带来效益在于flashcache，而且OLAP中则是smart scan。但如果回答，多就一定好，少就一定不好，都是片面的，需要CASE BY CASE的分析。exadata还有很多秘密武器诸如：exafusion，roce 傲腾，cell ram，hcc，std idx 等等，只有我们了解其机制，熟悉我们的业务需求，exadata才会成为真正的银弹！
LIST METRICHISTORY WHERE collectionTime > '2019-10-22T16:33:35+08:00'and collectionTime < '2019-10-22T16:35:35+08:00'
