慢的认知报告

时间:2010-09-29 11:07:26

标签: migration cognos

我们刚刚将Cognos reportnet的报告迁移到Cognos 8.4,现在报告太慢了。

该报告只有一个嵌套在列表中的交叉表,其中包含句点/季度/半/年

报告设计:

  • mainqueryitem(queryitem)获取 数据通过手动sql。
  • 手动sql有4个查询 联合在一起。
  • 所有4个查询都只是选择 从不同的表加入(没有 组/排序/过滤器)。
  • PlanningLevel(queryitem)获取 来自mainqueryitem的数据。 (例如:if mainqueryitem.name = 'Black' then mainqueryitem.quantity else null。 PlanningLevel的所有DataItem都使用上述格式)
  • 报告页面由a组成 交叉表嵌套在列表中 (分段)。
  • 列表与a关联 masterquery。
  • 交叉表与之相关联 规划水平。
  • 交叉表包含聚合 也
  • 提示页面包含一个 多选列表。

即使是较小的提示值,报告也非常缓慢。

然后我将PlanningLevel queryitem的属性'OverrideDimInfo'更改为'no',当从reportnet迁移时已经有一些DimensionInfos(不知道它是什么)

然后报告的速度越来越快。标准(<1分钟)。 (快400倍) 但是更多没有。选项/标准(&gt; 2),报告仍然较慢。 (最多3.5小时,最大的报告 - 选择所有标准)

在toad中运行最大报告时,mainqueryitem sql需要<5分钟才能执行。 最大的报告耗时3.5小时,在报告网络中以分钟为单位运行。

如何提高性能?

1 个答案:

答案 0 :(得分:2)

我在8.4中观察到的一件事是,当使用嵌套在列表对象中的交叉表对象(与主 - 细节关系连接在一起)时,您的主查询(与列表相关联)应该尽可能有限且简单。我不了解您的情况,但通常包含主查询的列表的目的是基于维度属性将交叉表结果分段为组,并且详细信息查询更复杂并且还包括事实信息。在这种情况下,Cognos不会执行2个查询来提取Cognos服务器上的所有数据和格式(正如人们所期望的那样),而是为每个分组激发单独的查询。有时,您可以通过尽可能简化主查询来获得性能方面的一些改进。很多时候人们只会复制详细信息查询,将其重命名为主数据并加入回详细查询而不进行任何修改。摆脱主查询中不需要的任何内容。在您的情况下情况可能并非如此,但我们在报告中多次观察到此行为,并且调整主查询通常会有所帮助。

使用列表部分时可能遇到的另一个问题(不确定这是否是您通过细分的意思)取决于报告的构建方式,Cognos有时会为每个部分触发重复查询。您可以通过选择“工具&gt;”来查看执行了多少查询从菜单中显示Generated SQL / MDX'。