仅EVI访问
IBM DB2 for i继续以许多方式增强SQE。 最近的一项改进（2015年11月）提供了一种新的方式，SQE可以使用EVI通过索引实现访问查询所需的数据。 此新功能称为仅EVI访问（EOA），在其中仅通过访问索引即可访问数据。 本文提供了一些基本细节，您需要使用仅编码矢量索引访问 。
EVI是IBM Research团队发明的一项专利技术，对于IBM DB2 for i而言是唯一的。 EVI能为您做什么？ 索引是一种永久性结构，由数据库维护，以快速解答您的问题（获取查询所需的数据）。 伊顿真空灭弧室可以被用作选择 ，其中所得到的行被识别的一部分。 当列的基数低（唯一值的数量）时，通常认为用于选择的EVI更有利。 2012年，对IBM i 7.1进行了增强，以允许EVI 包括并维护汇总明细，例如重要列的汇总，平均值和计数值。
通过支持EOA的增强功能，EVI可以用于列值的投影 。 列值的投影是在SQL查询中的SELECT和FROM子句之间找到的列。 您应该在哪里使用EOA？ 如您所料，我将以“取决于”来回答。 回答与性能相关的问题的任何人都总是走这条安全道路。 性能的现实是它确实取决于各种因素，其中某些因素是特定于客户的。 与其他人一样，我将依靠“取决于情况”，但也鼓励您接受教育，然后花时间评估您的选择。
启用EOA
QAQQINI查询选项控制SQE是否可以考虑成本核算以及将EVI用于EOA。 该控件名为ALLOW_EVI_ONLY_ACCESS ，可以将其配置为设置为以下值：
- * DEFAULT –在IBM i 7.1中，* NO是缺省值。 在IBM i 7.2中，* YES是缺省值。
- *是 – EOA有资格被SQE考虑
- *否 -EOA不符合SQE的资格
如您所见，IBM i 7.1和7.2之间的默认行为有所不同。 为什么是这样？ 因为许多IBM i 7.1用户希望操作和查询实现保持不变，所以我们决定将该版本的支持默认设置为关闭。 要覆盖这一决定，只需更新自己喜欢的QAQQINI文件来使用ALLOW_EVI_ONLY_ACCESS与* YES或更新QUSRSYS / QAQQINI整个分区，以使EOA。 如果您使用的是IBM i 7.2，则除了应用DB2 PTF组之外，无需执行任何其他操作来启用EOA。
表1中显示了包括EOA启用的DB2 PTF组。要使用EOA，您的DB2 PTF组级别必须匹配或超过表中的级别。
表1：启用了EOA的DB2 PTF组级别
| DB2 for i增强功能 | IBM i 7.2 | IBM i 7.1 |
|---|---|---|
| 仅EVI访问（EOA） | SF99702 9级 | SF99701 38级 |
EVI RRN探针
在处理列值的项目时，表探测操作用于根据表的行号从表中检索特定行。 通过一些其他操作为表生成行号，将行号提供给表探针访问方法。 借助新的EOA功能，现在可以使用EVI相对记录号（RRN）探针从EVI中检索列值。 EVI RRN探针是仅索引访问方法，用于通过从EVI检索值而不是使用表探针访问表来提供选定的列。 从EVI检索值应该比与表探测操作相关的随机I / O提供更好的I / O特性。
此访问方法与基数索引探针，基数索引扫描或EVI探针操作结合使用。 使用基数索引探针，基数索引扫描或EVI探针操作来选择行，然后使用所选行的RRN探查EVI，以检索用于选择的索引未提供的任何选定值。 EVI RRN探针可以访问多个EVI以提供选定的值。
表2总结了新的EVI RRN探针及其相关的优点，注意事项，示例和其他信息。
表2：EVI RRN探针属性
| 资料存取方式 | EVI RRN探针 |
|---|---|
| 描述 | 基于基础索引访问提供的RRN，可以快速探查编码矢量索引。 |
| 优点 |
|
| 注意事项 |
|
| 可能被使用 |
|
| 示例SQL语句 | |
| 示例CREATE INDEX SQL语句 | |
| 数据库监视器和计划缓存记录， 指示使用情况 | QQRID 3001索引用于每个EVI的记录，其中QQRCOD ='I8' |
| 启用SMP并行 | 是 |
| 也称为 | 台式探针，预紧 |
| 视觉解释图标 |
|
在仅访问编码矢量索引之前，建议仅为基数较低（少量的不同值）的列创建EVI。 该建议现已更改。 EVI RRN探针可用于具有高基数（大量不同值）的列。 但是，在创建EVI时，如果数据库管理器需要使用更宽的向量，则应使用WITH integer DISTINCT VALUES子句来适当地设置EVI向量的初始宽度，并最大程度地减少维护时间。 有关更多详细信息，请参考SQL参考中的CREATE INDEX语句 。
表3显示了三个数据库Navigator产品选项。 本文中的信息和示例是使用IBM i Access for Windows中的Navigator产品构建的。 有些人将此产品称为System i Navigator，而另一些人将其称为IBM i Navigator。 在本文中，使用术语IBM i Navigator。
表3：Database Navigator产品概述
| 产品展示 | Windows版IBM i Access | IBM i Access客户端解决方案 | IBM i导航器 |
|---|---|---|---|
| 别名 | System i导航器 或IBM i Navigator | ACS | 我的导航器 |
| 它在哪里运行？ | Windows PC安装 | 可以使用Java的任何地方 | 浏览器 从IBM i 7.1和7.2提供 |
| 最近的服务水平？ | IBM i Access Windows Service Pack 7.1 – SI57907 | 版本1.1.5.0 | i PTF组的IBM HTTP Server： 7.2-SF99713 12级 7.1-SF99368等级37 |
| 最佳功能，适用于数据库用户 | 运行SQL脚本 视觉解释 许多其他功能 | 运行SQL脚本 SQL性能中心 | PDI观点 OmniFind管理 |
| 要观看的网页 | ibm.com /systems/power/software/i/access/windows_sp.html | ibm.com /systems/power/software/i/access/solutions_support.html | www-912.ibm.com/s_dir/SLINE003.NSF/PTFbyNumber/SF99713 www-912.ibm.com/s_dir/SLINE003.NSF/PTFbyNumber/SF99368 |
| 下一步（计划中）更新 | 2016年6月 | 2016年7月→版本1.1.6.0 | 每2至3个月建立新的PTF组 |
EVI RRN探测计划的索引建议
Index Advisor可能会建议将EVI索引与EVI RRN探测计划一起使用。 为了限制过多的索引建议，除非在查询的一个或多个投影列上至少有一个单列EVI，否则SQE不会考虑建议EOA。
EVI RRN探测计划建议需要将一个或多个索引创建为依赖集。 如果缺少任何EVI索引，优化器将无法进行成本估算并选择这些相关索引来实施EVI RRN探针。
如果直接查询QSYS2 / SYSIXADV，则“建议的原因”列将具有原因代码“ I8”。 如果使用IBM i Navigator检查索引建议，您将看到类似于图1所示的内容。
图1.索引建议和EOA
该建议基于查询的每个表。
仅当以下语句为真时才建议使用索引：
- 查询的选择列表中的至少一列需要具有现有的单列EVI。
- 与现有EVI不匹配的列数必须少于20。
- 所有列都必须符合作为索引键的条件。
当Index Advisor显示高度依赖的建议时，使用Show Statements中的完全匹配功能在计划缓存中查找查询会很有帮助。 找到后，使用Visual Explain查找特定于该查询的相关索引建议。
EVI RRN探测计划建议示例
在以下示例中，假定以下索引已存在。
- 列ORDERDATE上的基数索引
- 列ORDERPRIORITY上的EVI索引
SELECT QUANTITY, ORDERPRIORITY, EXTENDEDPRICE FROM ITEM_FACT
WHERE SHIPMODE = 'TRUCK'
ORDER BY ORDERDATE DESC
LIMIT 50
OFFSET 0;索引顾问将为所有缺少的列建议使用EOA风格的EVI索引：QUANTITY和EXTENDEDPRICE。 尽管EOA样式索引建议显示在IBM i Navigator索引顾问中，但是，如果您有特定的查询，则应使用Visual Explain的索引顾问来快速识别丢失的索引。
图2显示了使用Visual Explain检查建议时为查询生成的EVI建议。
图2. Visual Explain中的EOA和索引建议
每当您想知道SQE为什么不使用现有索引时，您都可以在两个地方查看以获得更多的见解。
- 分析：如果捕获SQL性能监视器，那么可以使用IBM i Navigator或IBM i Access Client Solutions来分析监视器。 如果您深入了解SQE的语句详细信息，则可以访问“ 考虑索引”操作以查看SQE考虑的索引以及为什么不使用索引的基本说明。 图3仅显示了原因码20。详细的原因可能会在将来的IBM i版本中出现。
- 直观说明：有关已考虑索引的相同信息，可以在“ 关于计划执行的信息”部分和“ 优化的索引列表”下找到 。
图4显示，由于原因20，优化器未使用EVI。
借助EOA支持，详细信息索引已扩展为包括两个附加原因码：
- 原因码20 ：由于编码矢量索引不适合内存，因此无法使用访问路径。
用户响应 ：考虑使用专用池，如下一节所述。 - 原因码21 ：由于并非所有引用的列都具有编码矢量索引，因此无法使用访问路径。
用户响应 ：在所有引用的列上创建单列EVI。
注：请参阅IBM Knowledge Center中 QQQ3007表的QQ1000列，以获取原因1到19的解释。
图3. IBM i Navigator分析考虑的索引
图4.已考虑但未使用的Visual Explain索引
公平的记忆份额
由于索引可能很大，因此SQE在考虑是否使用EOA时采取了保守的方法。 如果对EOA实施的内存影响将超过用户的合理内存份额，则SQE将避免使用EOA。
要缓解此问题，您可以配置一个私有存储池，并使用QAQQINI MEMORY_PREFERENCE选项将SQE定向为对该查询使用该池。 对于超出EOA的查询，这是一种有用的调优技术，但对于需要对大数据使用EOA的人来说，这是至关重要的成功因素。 有关内存首选项详细信息的指针，请参见本文结尾。
图5显示了Visual Explain的屏幕截图，其中包含我们创建建议的EVI索引并缓解了公平共享内存问题后的查询实现。
图5. EOA实现的可视化解释
德国足球和EOA
这两个主题的共同点超出了您的想象。 为了演示如何使用EOA，我们只需要看德国德甲联赛。 在这个虚构的示例中，我们有一个非常大的数据库表，每个风扇包含一行。 该行为我们提供了一些信息，例如粉丝的姓名，电子邮件地址，当然还有粉丝赖以生生，振奋和鼓励的团队，经历了风风雨雨，起起落落，得失。
此示例的查询非常简单。 查找位于法兰克福的Eintracht俱乐部所有粉丝的电子邮件地址。 图5直观地说明了EOA的实际作用。
我们从图5中编号为1的红色圆圈开始检查。使用在FCName列（即足球俱乐部名称）上建立的传统EVI，我们可以有效地在表中找到与选择标准匹配的行。 传统的EVI维护了一个符号表，其中包含各种足球俱乐部名称和该值的关联符号表代码。 因为德甲只有18个足球俱乐部，所以可以得出结论FCName的基数很低。
在编号为2的红色圆圈处，我们看到使用EVI符号表代码（5）的SQE，扫描EVI向量并标识与“ Eintracht”匹配的行。 SQE做得好，在人群中欢呼！
在编号为3的红色圆圈处，我们看到EOA出现。 上一步中的向量扫描不仅识别了选择行，而且由于向量是以相对行顺序构建的，因此我们可以利用这种见解快速识别任何关联的EVI的向量中的相同行。 在示例中，此类EVI构建在Email_Address列之上。 EOA可以访问从EVI向量开始并向上移动到EVI符号表的列值。 如示例所示，与使用EVI选择行相比，这是相反的处理顺序。
在编号为4的红色圆圈处，我们看到EVI矢量代码用于在EVI符号表中查找列值。 这种EOA样式的EVI可能具有非常高的基数并且仍然有用。 理解这一点很重要，因为EVI传统上是针对较低基数的数据选择的。 另一个考虑因素是，如果您知道EOA风格的EVI索引将具有更高的基数，则应使用WITH xx DISTINCT VALUES以便从宽EVI向量开始。 尽管随着基数的增加，DB2 for i可以扩展向量的大小，但是如果您预计列中会出现许多唯一值，则最好从最宽的向量开始。
图6.德甲足球和EOA
最后，在编号为5的红色圆圈处，我们的查询仅通过访问两个编码矢量索引来返回结果。 DB2 for i和SQE已使用EOA来实现“ ein Torschießen” ，即“达到目标” ！
摘要
本文的目的是提高对EOA的认识，并提供基本知识以帮助您入门。 索引不是免费的，因此您可能不应该只是继续在自己喜欢的表的列上构建单列EVI。 相反，请寻找效果不佳的查询，然后将EOA用作测试驱动器。
翻译自: https://www.ibm.com/developerworks/ibmi/library/i-evi-only-access-in-ibm-db2-for-i/index.html
612
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
