标签：演进 Scan 数据库 IO 软件 Exadata 节点 Smart
Exadata性能加速相关软件特性的演进历史（一）发布之后深受大家欢迎。经过小编锲而不舍地催稿，吴大师终于提交了本系列之二。
1
智能扫描 (Smart Scan)功能的持续增强
智能扫描(Smart Scan)是在Exadata V1推出时，在最早的Exadata Exadata Storage Server Software 11.1.1版本就具备的功能，而且一直是Exadata最重要功能之一。这个功能如此出名，以至于到今天仍然有很多对它的误解。其中最大的误解就是认为有了Smart Scan以后，索引就没有意义了，甚至当年还有很多误传认为数据库迁移到了Exadata以后，应该去掉所有的索引才运行的效率最好。事实上，Smart Scan是用来加速全表/分区或者索引快速全扫描特性，并不是用来代替B-tree索引选择性好的情况下快速访问少量数据。因此简单来说，Smart Scan特性是用来加速分析/OLAP类工作负载的特性，并不是用来直接加速通过索引访问的OLTP类的特性。
也因此，就有了第二个误解，很多人认为Smart Scan这个特性只有在数据仓库应用上才有用。这种观点忽视了现实世界运行在Oracle数据库上应用的复杂性。实际上大部分应用是复杂的，在Oracle数据库上运行的SQL也是复杂多变的，很多所谓的OLTP系统，类OLAP工作负荷一点都不少。在支撑OLTP工作负荷的同时，仍然有全表扫描的存在，真实的应用大部分都是混合负载，也就是现在一个时髦的新词HTAP。例如下图，是在两个Oracle OLTP交易库捕获的1小时的IO情况。
这两个应用都是来自使用Oracle数据库运行关键OLTP业务的数据库，其中一个已经运行在Exadata环境，而另外一个则还是传统IOE架构。但是有意思的是 ，这两个典型的OLTP库的IO明显都存在大量全表扫描。第一张图这一个小时内做了6TB的IO读取，其中4.7TB Smart Scan就是说明在Exadata全表/分区/索引快速扫描而且被智能存储的SmartScan加速。而第二张图没有迁移到Exadata，一个小时做了7.3TB的IO读取，其中3.2TB是direct path read，也是因为在做全表/分区/索引快速扫描而导致的IO。如果迁移到Exadata这些IO也会被大量加速。而这样加速的效果不仅仅是加速全表扫描，同时能大量释放存储访问网络的IO压力，也降低数据库节点的CPU负荷，能够间接加速OLTP中的其他随机读取。Smart Scan是一个非常优秀的设计，这个特性带来了Oracle RAC在架构机制上的变革。有了Smart Scan，传统的Share Disk 的RAC和Share Nothing的存储层数据密集处理完美结合，才有了唯一一款在一个数据库集群中实现的Share Disk + Share Nothing混合分布式架构。这一架构到今天为止还是独此一家，别无分店。在这个架构中，我们既能享受基于缓存一致性的Share Disk数据库架构对OLTP应用的透明支持，又能享受Share Nothing对OLAP数据库需要的并行处理减少数据搬移的特点，而且通过Share Nothing的智能存储层突破了传统Share Disk架构计算能力增长远超存储能力增长而导致的不均衡问题。
Smart Scan的功能也随着Exadata软件的升级在不断加强。从第一个Exadata版本开始，Smart Scan功能就能进行包括行投影、列投影、标量函数在存储节点的运行，而且负责在通过Smart Scan扫描数据时的解压缩工作。随着版本的升级，Smart Scan的能力越来越强。12.1.1.1开始（Oracle数据库是12.1.0.2或以上的版本），LOB和CLOB的like操作可以被offload到cell处理；12.1.2.1开始， JSON和XML的以下操作也可以被offload到存储执行。
2
存储索引 (Storage Index)功能的持续增强
Storage Index这个功能也是在最早的Exadata软件版本中就存在的功能。为了加速DW类的全表扫描，仅仅利用Smart Scan减少从存储节点到数据库节点的IO传输量已经不够，还必须设法减少在物理介质上发生的IO量。减少物理介质的IO量一个方法是通过压缩，尤其在Exadata上的混合列压缩方式（在这里不做详细介绍），另外一个方法就是通过Storage Index（存储索引）这样的技术：在存储服务器的内存里针对表里的数据，每个固定大小的Chunk(通常是1MB)数据建立某些列的最大值和最小值。当查询条件有某个列的>,<,=,between…and时，ESS软件会自动根据内存里面的一个Region这个列的最大值和最小值判断这个Region是否有满足条件的数据。如下图是一个例子。
这个功能最早对于单个Chunk只最多支持8个Column，后续在12.2.1.1中，可以支持的列的数量增加到了24个，能够更好地加速查询。此外，还增加了能针对max/min这样函数进行加速，避免要遍历所有值才能找到最大、最小值的做法。很多情况下的查询仅仅靠最大值最小值进行修剪的加速仍然不够，因此，在12.2.1.1中除了让Storage Index能够支持24个列以外，还针对distinct值少的的列（<200个），增加了称为Set Membership的功能。这个功能能在内存中建立每个Chunk中某些列值的压缩字典，当查询条件存在在这些列上过滤的情况下，能够更好地判断Chunk中的数据是否满足过滤条件，这样就能做到更加精确而不仅仅是靠最大值最小值的修剪。
3
Cell to Cell data transfer这个功能是在Exadata软件12.1.1.1引入的一个重要的新功能，但是却是很容易被人忽视的功能。这个功能简单来说就是当大量数据需要写入到Cell的时候，可以将这个写入的过程offload到存储到存储之间直接通信。举一个例子，当ASM做rebalance/resync/rebuild的时候，在这个版本之前，所有的数据块都要从Cell被读到数据库节点，然后再从数据库节点写到另外一个Cell。但12.1.1.1开始，配合 12.1以上的DB，在rebalance /resync /rebuild时，DB的节点的ASM实例仅仅控制，不需要真正的读写数据，数据变成通过Cell的Cellsrv直接读写，跨cell直接传输。这样的好处一方面能降低上述情况下DB节点的负载，而且把DB节点和CELL节点的IB连接更好地服务业务而不是内部的数据冗余修复，另外一方面也会大大加快rebalance/resync/rebuild的速度。这样的加速还是很明显的，例如增加一个CELL的情况，通过这个功能，能加快速度可达90%；降低ASM的ARB进程DB TIME只有没有启用此功能的40%
这个功能除了对ASM这类数据密集拷贝的相关操作有用，对于数据大量加载的情况下也会有用。例如当我们采用外部表加载大量数据到数据库，由于ASM冗余的存在，在加载1GB数据库的情况下，不考虑压缩实际上在CELL层面数据文件写发生的写可能是2GB（普通冗余）或者3GB（高度冗余）。如果考虑到没有启用nologging和归档，redo/归档还会有大量的写入。如果这些数据也都是通过DB节点全部写多份，那么多DB节点的CPU、IB网络接口等容易造成额外的负担。因此这类操作也可以被Cell to Cell Data Transfer所加速，DB节点只需要写一份，剩余的多份拷贝让cell直接直接通信拷贝，避免占用DB节点的CPU和IB网络资源。
4
IO Latency Capping不论磁盘还是Flash，在实际的使用中都可能发生偶发性的高延迟离群响应。Flash的离群响应时间比较好理解，这是因为的Flash的写特性导致的，擦除循环、碎片收集、写寿命等等很容易导致，而硬盘的原因则可能是高负荷下的寻道算法、微码等导致。这是在实际生产中不论选择如何质量好的企业级存储介质都仍然可能产生的，而且容易随着使用时间的变长而发生几率升高。这种情况不会严重到ASM会将对应的介质标记成已经损坏，需要drop（如果那么做，将会产生大量的错误drop）。为了保证这种情况下Exadata上运行的数据库仍然能够对外提供良好的SLA，在Exadata软件11.2.3.3.1开始配合数据库11.2.0.4.8以上版本，引入了称为读IO Latency Capping的功能。当IO读的时间超过一个阈值后，数据库会cancel这个IO，而选择从对应数据块的其他ASM Mirror（肯定在其他的Cell）中读取，以保证良好的读响应时间。这个过程对前台是透明的，即便在数据库的alert.log中出现这种信息，应用并不会感受到。到了Exadata软件12.1.2.1，IO Latency Capping的功能扩展到了写。当数据库的写操作超过阈值，会重定向到同一个Cell的另外一个Flash设备，以保证前台的SLA。
5
网络资源管理（Network Resource Management）这也是一个重要的保证性能SLA的功能，和大家相对比较熟悉的内置在数据库内的资源管理器不同，这个功能是完全自动的。从Exadata软件11.2.3.3.0开始，配合的Inifiniband 交换机微码2.1.3-4以上引入的功能。引入这个功能的目的优先保证对前台应用响应时间最关键的lgwr写、cache fusion的消息，以保证在复杂混合负载下的关键业务性能。Exadata上的IB网络，承载了RAC互联和数据库节点到存储节点通信的消息，有的消息对于前台应用的响应时间是至关重要的，例如redolog 写的消息和RAC Cache Fusion的消息，有的消息例如归档日志写的消息，数据库备份、恢复、direct path insert大量数据、全表扫描生成报表的IO消息对响应时间的要求就不需要那么高。下图是一个测试的例子，对比了启用和不启用这个特性在混合负载下前台TPS的变化。
这是一个混合负载的场景，在没有Network Resource Manager的情况下，如果发生全表扫描，即使有Smart Scan能降低IB网络的流量，IB网络流量仍然会很大。IB流量大将会导致对前台SLA影响最大的Logwr消息和Cache Fusion消息受到影响。有了网络资源管理器，IB网络能够优先传递对前台SLA最关键的消息，保证了前台TPS收到的影响较少。
编辑：范宏伟
标签：演进,Scan,数据库,IO,软件,Exadata,节点,Smart 来源： https://blog.51cto.com/u_15127541/2702395
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。