利用 Informix 对 PeopleSoft 的 nVision 进行性能调优
资料简介：
简介
PeopleSoft® 的 nVision™ 是一个报告生成工具，它是 Microsoft® Excel™ 的扩展，主要用于总帐财务（General Ledger Financial）报告生成。用户创建访问总帐的报告模板，汇总总帐数据，并将选择器树用于汇总目的。该数据被选择、汇总并放入 Excel 电子表格的单元格中。选择器树用 pstreeselectxx表表示，其中 xx表示存储在树中的图字段（chartfield）的长度。例如， pstreeselect06将包含与长度为 6 的图字段相关联的树；最常见的可能是 account。
许多 PeopleSoft 客户通常抱怨 nVision 报告的性能。对于某些客户而言，只要有几个 nVision 报告正在运行，就使他们的系统大大减慢。我对 nVision 生成的查询和他们导致的性能问题有许多切身的体验。这些性能问题不是特定于 Informix® 的，但是 Informix 优化器的复杂性促使了 PeopleSoft 进行一些更改。为此，PeopleSoft 已经对 nVision 做了一些极佳的性能增强，这些增强可以在运行时间方面获得实质的改进，并且显著减少系统负载。
本文将讨论这些更改、它们对生成的 SQL 的影响，以及如何在 Informix 环境中利用这些更改。在 PeopleTools V5.12.20+、V6.1+ 和 V7.x 中可以使用 nVision 性能选项。此外，V5.12.19 发行说明包含了对这些更改的详细描述，这也非常有用。这些更改最早可在 5.12.19 中使用，但是在 5.12.20 中使用更佳。
nVision 性能
nVision 报告通常不会对数据库执行大量选择操作，但是被执行的选择操作是复杂的，退一步说，执行的效果很差。报告令人失望的方面在于生成的 SQL 不能由用户进行更改。但是，性能选项允许用户对如何生成 SQL 进行某些控制。下面的 清单 1显示了这些选择操作的一个示例，该示例汇总帐户和部门标识信息。
清单 1：标准 nVision 查询
在某个客户机的站点上，该查询花费的运行时间是一小时。该查询的问题在于，Informix 优化器不能很好地处理它，并且通常会选择错误的查询路径。优化器不喜欢对 tree_node_num 使用“BETWEEN”，也不喜欢对 account 和 deptid 字段使用“>=”和“<=”。这使得查询路径很容易更改。我发现该查询的最佳路径是从 pstreeselect06开始读取，然后是 ledger，最后是 pstreeselect05表。但是，由于对 ps_ledger 表使用了过滤条件 — 对 ledger、fiscal_year、business_unit 和 accounting_period 字段使用过滤条件 — 优化器选择从 ps_ledger表开始读取。我已经尝试了很多事情以便使优化器选择最优的路径，但是成功的次数有限。即使路径正确，由于强制执行最优路径所需的索引，查询也不会执行得很有效率。这使我们转而使用 PeopleSoft 所做的增强。
这些增强旨在改进被构造的查询，以便优化器可以更好地选择查询路径。这些更改的另一个优点是，它们可以真正帮助引擎更有效地执行查询。必须为每个单独的报告布局和该布局中使用的每棵树设置这些性能更改。到目前为止，还不能进行全局设置。尽管在 1998 年 PeopleSoft 的用户大会上提出了有关将性能选项存储在数据库而不是布局文件中的话题，以及允许为树进行全局设置的话题。通过打开报告布局并且选择菜单项 nVision -> Performance，会弹出如 图 1所示的对话框，从而可以访问性能选项。
第一步是选择要在报告中使用的树名。这些选项不仅特定于报告，而且也特定于要在报告中使用的单独的树。为报告中的某个树而不为其它树设置性能参数是可能的。一旦选定树，那么我们现在可以研究屏幕上的其它选项。
PeopleSoft® 的 nVision™ 是一个报告生成工具，它是 Microsoft® Excel™ 的扩展，主要用于总帐财务（General Ledger Financial）报告生成。用户创建访问总帐的报告模板，汇总总帐数据，并将选择器树用于汇总目的。该数据被选择、汇总并放入 Excel 电子表格的单元格中。选择器树用 pstreeselectxx表表示，其中 xx表示存储在树中的图字段（chartfield）的长度。例如， pstreeselect06将包含与长度为 6 的图字段相关联的树；最常见的可能是 account。
许多 PeopleSoft 客户通常抱怨 nVision 报告的性能。对于某些客户而言，只要有几个 nVision 报告正在运行，就使他们的系统大大减慢。我对 nVision 生成的查询和他们导致的性能问题有许多切身的体验。这些性能问题不是特定于 Informix® 的，但是 Informix 优化器的复杂性促使了 PeopleSoft 进行一些更改。为此，PeopleSoft 已经对 nVision 做了一些极佳的性能增强，这些增强可以在运行时间方面获得实质的改进，并且显著减少系统负载。
本文将讨论这些更改、它们对生成的 SQL 的影响，以及如何在 Informix 环境中利用这些更改。在 PeopleTools V5.12.20+、V6.1+ 和 V7.x 中可以使用 nVision 性能选项。此外，V5.12.19 发行说明包含了对这些更改的详细描述，这也非常有用。这些更改最早可在 5.12.19 中使用，但是在 5.12.20 中使用更佳。
nVision 性能
nVision 报告通常不会对数据库执行大量选择操作，但是被执行的选择操作是复杂的，退一步说，执行的效果很差。报告令人失望的方面在于生成的 SQL 不能由用户进行更改。但是，性能选项允许用户对如何生成 SQL 进行某些控制。下面的 清单 1显示了这些选择操作的一个示例，该示例汇总帐户和部门标识信息。
清单 1：标准 nVision 查询
SELECT A.ACCOUNT, L1.TREE_NODE_NUM, SUM(A.POSTED_TOTAL_AMT) FROM PS_LEDGER A, PSTREESELECT06 L, PSTREESELECT05 L1 WHERE A.LEDGER='ACTUALS' AND A.FISCAL_YEAR = 1997 AND A.ACCOUNTING_PERIOD BETWEEN 1 AND 6 AND A.BUSINESS_UNIT = 'XYZCO' AND L.SELECTOR_NUM = 100 AND ( L.TREE_NODE_NUM BETWEEN 1000001 AND 1000100 OR L.TREE_NODE_NUM BETWEEN 1000300 AND 1000400 OR L.TREE_NODE_NUM BETWEEN 1000500 AND 1000600 ... ) AND A.ACCOUNT >= L.RANGE_FROM_06 AND A.ACCOUNT <= L.RANGE_TO_06 AND L1.SELECTOR_NUM = 101 AND ( L1.TREE_NODE_NUM BETWEEN 5000000 AND 5000100 OR L1.TREE_NODE_NUM BETWEEN 5000300 AND 5000400 OR L1.TREE_NODE_NUM BETWEEN 5000500 AND 5000600 ... ) AND A.DEPTID >= L1.RANGE_FROM_05 AND A.DEPTID <= L1.RANGE_TO_05 AND A.CURRENCY_CD = 'USD' AND A.STAISTICS_CODE = ' ' GROUP BY A.ACCOUNT, L1.TREE_NODE_NUM注：“...”表明这些 OR 条件还有许多行。
在某个客户机的站点上，该查询花费的运行时间是一小时。该查询的问题在于，Informix 优化器不能很好地处理它，并且通常会选择错误的查询路径。优化器不喜欢对 tree_node_num 使用“BETWEEN”，也不喜欢对 account 和 deptid 字段使用“>=”和“<=”。这使得查询路径很容易更改。我发现该查询的最佳路径是从 pstreeselect06开始读取，然后是 ledger，最后是 pstreeselect05表。但是，由于对 ps_ledger 表使用了过滤条件 — 对 ledger、fiscal_year、business_unit 和 accounting_period 字段使用过滤条件 — 优化器选择从 ps_ledger表开始读取。我已经尝试了很多事情以便使优化器选择最优的路径，但是成功的次数有限。即使路径正确，由于强制执行最优路径所需的索引，查询也不会执行得很有效率。这使我们转而使用 PeopleSoft 所做的增强。
这些增强旨在改进被构造的查询，以便优化器可以更好地选择查询路径。这些更改的另一个优点是，它们可以真正帮助引擎更有效地执行查询。必须为每个单独的报告布局和该布局中使用的每棵树设置这些性能更改。到目前为止，还不能进行全局设置。尽管在 1998 年 PeopleSoft 的用户大会上提出了有关将性能选项存储在数据库而不是布局文件中的话题，以及允许为树进行全局设置的话题。通过打开报告布局并且选择菜单项 nVision -> Performance，会弹出如 图 1所示的对话框，从而可以访问性能选项。
第一步是选择要在报告中使用的树名。这些选项不仅特定于报告，而且也特定于要在报告中使用的单独的树。为报告中的某个树而不为其它树设置性能参数是可能的。一旦选定树，那么我们现在可以研究屏幕上的其它选项。
2012-09-24
浏览4488
下载0
已下载用户的评价
您还未下载该资料，不能发表评价；
查看我的 待评价资源
查看我的 待评价资源
没用
结束语 这些更改是在一个客户机站点上进行的，测试报告的最长运行时间为 3 分 30 秒。在这些更改之前，通常的运行时间是 2 至 4 小时。正如我前面提及的，这些更改是 显著的。它表明，通过为给定报告中的所有树使用 Dynamic Selectors和 Single Values选项可以获得最佳性能。这就是为这个客户机所做的工作。根据多个单独的客户机使用的报告和树，应当更改这些选项以获得更佳的性能。目标是运行报告、检查生成的查询、更改一些设置，以及重新检查查询以查看新的设置是否生成了更有效的查询。
结束语 这些更改是在一个客户机站点上进行的，测试报告的最长运行时间为 3 分 30 秒。在这些更改之前，通常的运行时间是 2 至 4 小时。正如我前面提及的，这些更改是 显著的。它表明，通过为给定报告中的所有树使用 Dynamic Selectors和 Single Values选项可以获得最佳性能。这就是为这个客户机所做的工作。根据多个单独的客户机使用的报告和树，应当更改这些选项以获得更佳的性能。目标是运行报告、检查生成的查询、更改一些设置，以及重新检查查询以查看新的设置是否生成了更有效的查询。
没用
选择器选项 Ranges of values (>=...<=)选项使用原始的方法构建查询。 Ranges of values (BETWEEN)选项利用如下所示的 BETWEEN 子句生成查询：[code]AND A.DEPTID BETWEEN L1.RANGE_FROM_05 AND L1.RANGE_TO_05[/code]这两个选项都不能帮助我们消除范围，因此没用。但是， Single Values选项很有用。该选项只能与上面提及的 Dynamic Selectors选项一起使用，它使 nVision 可以在复制选择器号时“扩展”范围值。使用上面的数据，新的选择器号将包含如 表 3所示的记录，假定有效的帐户是 1、2、3、4、10、20 和 30。 [attach]111211[/attach] 现在，拥有 7 个没有范围只有单个值的记录，而不是两个范围分别为 1 到 4 和 10 到 30 的记录。利用这个为 account 树 pstreeselect06设置的选项，查询变成如 清单 3所示： 清单 3：选择了“Single Values”的 nVision 查询[code]SELECT A.ACCOUNT, L1.TREE_NODE_NUM, SUM(A.POSTED_TOTAL_AMT) FROM PS_LEDGER A, PSTREESELECT06 L, PSTREESELECT05 L1 WHERE A.LEDGER='ACTUALS' AND A.FISCAL_YEAR = 1997 AND A.ACCOUNTING_PERIOD BETWEEN 1 AND 6 AND A.BUSINESS_UNIT = 'XYZCO' AND L.SELECTOR_NUM = 200 - Note the equi-join on the account field vs. >= and <= AND A.ACCOUNT = L.RANGE_FROM_06 AND L1.SELECTOR_NUM = 201 AND A.DEPTID >= L1.RANGE_FROM_05 AND A.DEPTID <= L1.RANGE_TO_05 AND A.CURRENCY_CD = 'USD' AND A.STAISTICS_CODE = ' ' GROUP BY A.ACCOUNT, L1.TREE_NODE_NUM[/code]该查询简单得多，优化器更容易选择合适的路径。在这种情况下，最优路径是 pstreelect06、ps_ledger，然后是 pstreeselect05。对 pstreeselect06 表中的 tree_node_num 使用的 OR 条件已经被消除，对 account 字段使用的范围已经被等值连接所替代。由于对 ps_ledger表使用了合适的索引（ 表 4）： [attach]6134[/attach] 查询执行下列路径： 利用下列下限索引过滤器对 pstreeselect06进行仅键索引扫描： selector_num = 200 利用下列下限索引过滤器： ledger = 'ACTUALS' account = pstreeselect06.range_from fiscal_year = 1997 business_unit = 'XYZCO' accounting_period >= 1 和上限索引过滤器 accounting_period <= 6 对 ps_ledger 进行仅键索引扫描 利用下列上限索引过滤器对 pstreeselect05进行索引扫描： range_from_05 <= ps_ledger.deptid 该查询的运行时间大约是 25 分钟。请注意，从 pstreeselect05 读取的最后一个表将对范围（ range_from_05 <= ps_ledger.deptid ）执行非仅键索引扫描，但是没有下限索引过滤器。这样没有效率，因为可能有许多被扫描的 deptid 小于当前的 deptid ，但是它们并不在我们正在查找的范围内。要修正这一问题，我们可以为 deptid 树 — pstreeselect05设置 Single Values选项。执行该操作可以得到下列查询（ 清单 4）： 清单 4：为 deptid 树选定“Single Values”的 nVision 查询 SELECT A.ACCOUNT, L1.TREE_NODE_NUM, SUM(A.POSTED_TOTAL_AMT) FROM PS_LEDGER A, PSTREESELECT06 L, PSTREESELECT05 L1 WHERE A.LEDGER='ACTUALS' AND A.FISCAL_YEAR = 1997 AND A.ACCOUNTING_PERIOD BETWEEN 1 AND 6 AND A.BUSINESS_UNIT = 'XYZCO' AND L.SELECTOR_NUM = 200 - Note the equi-join on the account field vs. <= and >= AND A.ACCOUNT = L.RANGE_FROM_06 AND L1.SELECTOR_NUM = 201 - Note the equi-join on the account field vs. <= and >= AND A.DEPTID = L1.RANGE_FROM_05 AND A.CURRENCY_CD = 'USD' AND A.STAISTICS_CODE = ' ' GROUP BY A.ACCOUNT, L1.TREE_NODE_NUM 对 pstreeselect05表使用下列索引（ 表 5）： [attach]6135[/attach] 查询路径如下所示： 利用下列下限索引过滤器对 pstreeselect06 进行仅键索引扫描： selector_num = 200 利用下列下限索引过滤器：[code]ledger = 'ACTUALS' account = pstreeselect06.range_from fiscal_year = 1997 business_unit = 'XYZCO' accounting_period >= 1[/code]和上限索引扫描过滤器 accounting_period<= 6 对 ps_ledger 进行仅键索引扫描 利用下列下限索引过滤器对 pstreeselect05 进行仅键索引扫描：[code]selector_num = 201 range_from_05 = ps_ledger.deptid[/code]该查询非常有效，因为用于 pstreeselect05表的下限索引过滤器是一个等值连接，而不是一个不带下限索引过滤器的上限索引过滤器。相对于最初的一小时运行时间，该查询的运行时间为 10 秒。
选择器选项 Ranges of values (>=...<=)选项使用原始的方法构建查询。 Ranges of values (BETWEEN)选项利用如下所示的 BETWEEN 子句生成查询：[code]AND A.DEPTID BETWEEN L1.RANGE_FROM_05 AND L1.RANGE_TO_05[/code]这两个选项都不能帮助我们消除范围，因此没用。但是， Single Values选项很有用。该选项只能与上面提及的 Dynamic Selectors选项一起使用，它使 nVision 可以在复制选择器号时“扩展”范围值。使用上面的数据，新的选择器号将包含如 表 3所示的记录，假定有效的帐户是 1、2、3、4、10、20 和 30。 [attach]111211[/attach] 现在，拥有 7 个没有范围只有单个值的记录，而不是两个范围分别为 1 到 4 和 10 到 30 的记录。利用这个为 account 树 pstreeselect06设置的选项，查询变成如 清单 3所示： 清单 3：选择了“Single Values”的 nVision 查询[code]SELECT A.ACCOUNT, L1.TREE_NODE_NUM, SUM(A.POSTED_TOTAL_AMT) FROM PS_LEDGER A, PSTREESELECT06 L, PSTREESELECT05 L1 WHERE A.LEDGER='ACTUALS' AND A.FISCAL_YEAR = 1997 AND A.ACCOUNTING_PERIOD BETWEEN 1 AND 6 AND A.BUSINESS_UNIT = 'XYZCO' AND L.SELECTOR_NUM = 200 - Note the equi-join on the account field vs. >= and <= AND A.ACCOUNT = L.RANGE_FROM_06 AND L1.SELECTOR_NUM = 201 AND A.DEPTID >= L1.RANGE_FROM_05 AND A.DEPTID <= L1.RANGE_TO_05 AND A.CURRENCY_CD = 'USD' AND A.STAISTICS_CODE = ' ' GROUP BY A.ACCOUNT, L1.TREE_NODE_NUM[/code]该查询简单得多，优化器更容易选择合适的路径。在这种情况下，最优路径是 pstreelect06、ps_ledger，然后是 pstreeselect05。对 pstreeselect06 表中的 tree_node_num 使用的 OR 条件已经被消除，对 account 字段使用的范围已经被等值连接所替代。由于对 ps_ledger表使用了合适的索引（ 表 4）： [attach]6134[/attach] 查询执行下列路径： 利用下列下限索引过滤器对 pstreeselect06进行仅键索引扫描： selector_num = 200 利用下列下限索引过滤器： ledger = 'ACTUALS' account = pstreeselect06.range_from fiscal_year = 1997 business_unit = 'XYZCO' accounting_period >= 1 和上限索引过滤器 accounting_period <= 6 对 ps_ledger 进行仅键索引扫描 利用下列上限索引过滤器对 pstreeselect05进行索引扫描： range_from_05 <= ps_ledger.deptid 该查询的运行时间大约是 25 分钟。请注意，从 pstreeselect05 读取的最后一个表将对范围（ range_from_05 <= ps_ledger.deptid ）执行非仅键索引扫描，但是没有下限索引过滤器。这样没有效率，因为可能有许多被扫描的 deptid 小于当前的 deptid ，但是它们并不在我们正在查找的范围内。要修正这一问题，我们可以为 deptid 树 — pstreeselect05设置 Single Values选项。执行该操作可以得到下列查询（ 清单 4）： 清单 4：为 deptid 树选定“Single Values”的 nVision 查询 SELECT A.ACCOUNT, L1.TREE_NODE_NUM, SUM(A.POSTED_TOTAL_AMT) FROM PS_LEDGER A, PSTREESELECT06 L, PSTREESELECT05 L1 WHERE A.LEDGER='ACTUALS' AND A.FISCAL_YEAR = 1997 AND A.ACCOUNTING_PERIOD BETWEEN 1 AND 6 AND A.BUSINESS_UNIT = 'XYZCO' AND L.SELECTOR_NUM = 200 - Note the equi-join on the account field vs. <= and >= AND A.ACCOUNT = L.RANGE_FROM_06 AND L1.SELECTOR_NUM = 201 - Note the equi-join on the account field vs. <= and >= AND A.DEPTID = L1.RANGE_FROM_05 AND A.CURRENCY_CD = 'USD' AND A.STAISTICS_CODE = ' ' GROUP BY A.ACCOUNT, L1.TREE_NODE_NUM 对 pstreeselect05表使用下列索引（ 表 5）： [attach]6135[/attach] 查询路径如下所示： 利用下列下限索引过滤器对 pstreeselect06 进行仅键索引扫描： selector_num = 200 利用下列下限索引过滤器：[code]ledger = 'ACTUALS' account = pstreeselect06.range_from fiscal_year = 1997 business_unit = 'XYZCO' accounting_period >= 1[/code]和上限索引扫描过滤器 accounting_period<= 6 对 ps_ledger 进行仅键索引扫描 利用下列下限索引过滤器对 pstreeselect05 进行仅键索引扫描：[code]selector_num = 201 range_from_05 = ps_ledger.deptid[/code]该查询非常有效，因为用于 pstreeselect05表的下限索引过滤器是一个等值连接，而不是一个不带下限索引过滤器的上限索引过滤器。相对于最初的一小时运行时间，该查询的运行时间为 10 秒。
没用
树选择器 选择 Static Selector则使用原始方法（也就是性能选项前的方法）构建查询。查询将使用存储在表中的选择器号。 Dynamic Selectors选项使 nVision 将选择器号复制到新的选择器号，然后将那个新的选择器号用于报告的当前运行。 例如，如果号码为 100 的选择器包含 表 1 所示的记录，则可以将它们复制到号码为 200 的选择器。其中的主要好处在于，当选择器号被复制时，应用了对 tree_node_num 使用的条件，因此消除了 清单 1 的查询中对优化器不“友好”的 OR 条件。让我们假定 OR 条件将消除 tree_node_num 为 30 的记录，那么新的选择器号将包含如 表 2所示的记录。 [attach]111209[/attach] 假定在我们布局的两个树（ account 和 deptid ）上都选择了这些选项，那么生成的查询看上去将类似 清单 2。 清单 2：选择了“Dynamic Selectors”的 nVision 查询[code]SELECT A.ACCOUNT, L1.TREE_NODE_NUM, SUM(A.POSTED_TOTAL_AMT) FROM PS_LEDGER A, PSTREESELECT06 L, PSTREESELECT05 L1 WHERE A.LEDGER='ACTUALS' AND A.FISCAL_YEAR = 1997 AND A.ACCOUNTING_PERIOD BETWEEN 1 AND 6 AND A.BUSINESS_UNIT = 'XYZCO' AND L.SELECTOR_NUM = 200 - Note the missing OR conditions on tree_node_num AND A.ACCOUNT >= L.RANGE_FROM_06 AND A.ACCOUNT <= L.RANGE_TO_06 AND L1.SELECTOR_NUM = 201 - Note the missing OR conditions on tree_node_num AND A.DEPTID >= L1.RANGE_FROM_05 AND A.DEPTID <= L1.RANGE_TO_05 AND A.CURRENCY_CD = 'USD' AND A.STAISTICS_CODE = ' ' GROUP BY A.ACCOUNT, L1.TREE_NODE_NUM[/code]该查询不但看上去更美观，而且优化器不会对 tree_node_num 使用 OR 条件，因此更有可能选择较佳的路径。但是，那些恼人的“>=”和“<=”子句仍然存在，它们会引起问题。这就是下一部分对话框的用处所在。
树选择器 选择 Static Selector则使用原始方法（也就是性能选项前的方法）构建查询。查询将使用存储在表中的选择器号。 Dynamic Selectors选项使 nVision 将选择器号复制到新的选择器号，然后将那个新的选择器号用于报告的当前运行。 例如，如果号码为 100 的选择器包含 表 1 所示的记录，则可以将它们复制到号码为 200 的选择器。其中的主要好处在于，当选择器号被复制时，应用了对 tree_node_num 使用的条件，因此消除了 清单 1 的查询中对优化器不“友好”的 OR 条件。让我们假定 OR 条件将消除 tree_node_num 为 30 的记录，那么新的选择器号将包含如 表 2所示的记录。 [attach]111209[/attach] 假定在我们布局的两个树（ account 和 deptid ）上都选择了这些选项，那么生成的查询看上去将类似 清单 2。 清单 2：选择了“Dynamic Selectors”的 nVision 查询[code]SELECT A.ACCOUNT, L1.TREE_NODE_NUM, SUM(A.POSTED_TOTAL_AMT) FROM PS_LEDGER A, PSTREESELECT06 L, PSTREESELECT05 L1 WHERE A.LEDGER='ACTUALS' AND A.FISCAL_YEAR = 1997 AND A.ACCOUNTING_PERIOD BETWEEN 1 AND 6 AND A.BUSINESS_UNIT = 'XYZCO' AND L.SELECTOR_NUM = 200 - Note the missing OR conditions on tree_node_num AND A.ACCOUNT >= L.RANGE_FROM_06 AND A.ACCOUNT <= L.RANGE_TO_06 AND L1.SELECTOR_NUM = 201 - Note the missing OR conditions on tree_node_num AND A.DEPTID >= L1.RANGE_FROM_05 AND A.DEPTID <= L1.RANGE_TO_05 AND A.CURRENCY_CD = 'USD' AND A.STAISTICS_CODE = ' ' GROUP BY A.ACCOUNT, L1.TREE_NODE_NUM[/code]该查询不但看上去更美观，而且优化器不会对 tree_node_num 使用 OR 条件，因此更有可能选择较佳的路径。但是，那些恼人的“>=”和“<=”子句仍然存在，它们会引起问题。这就是下一部分对话框的用处所在。