缓慢的 cognos 报告

Question

我们刚刚将一份报告从 Cognos reportnet 迁移到 Cognos 8.4，但该报告现在太慢了。

该报告只有一个交叉表，嵌套在一个列表中，其中包含期间/季度/半/年的聚合

报告设计：

• mainqueryitem (queryitem) 得到 通过手动sql获取数据。
• 手动sql依次有4条查询 联合起来。
• 所有 4 个查询都只是选择 来自不同表的连接（没有 组/排序/过滤器）。
• PlanningLevel（查询项）获取 来自 mainqueryitem 的数据。 （例如：if mainqueryitem.name = 'Black' then mainqueryitem.quantity else null。 PlanningLevel的所有DataItems都使用上述格式）
• Report Page由一个 嵌套在列表内的交叉表 （分段）。
• 该列表与一个关联 主查询。
• 交叉表关联到 规划层面。
• 交叉表包含聚合 还。
• 提示页面包含一个 多选列表。

即使对于较小的提示值，报告也非常慢。

然后，我将 PlanningLevel 查询项的属性“OverrideDimInfo”更改为“no”，该查询项在从 reportnet 迁移时已经有一些 DimensionInfo（不知道它是什么），

然后报告运行速度更快，编号更少。标准（<1 分钟）。 （快 400 倍） 但更多的是没有。选项/标准（>2），报告仍然较慢。 （对于所选的最大报告所有条件，最多 3.5 小时）

在 Toad 中运行最大报告时，mainqueryitem sql 的执行时间不超过 5 分钟。 最大的报告需要 3.5 小时，而在 Reportnet 中只需几分钟即可运行。

有什么想法可以提高性能吗？

Answer 1

我在 8.4 中观察到的一件事是，当使用嵌套在列表对象中并通过主从关系连接在一起的交叉表对象时，主查询（与列表关联）应该尽可能有限和简单。我不知道你的情况，但通常包含主查询的列表的目的是根据维度属性将交叉表结果分组，而详细查询更复杂并且还包含事实信息。在这种情况下，Cognos 不会执行两个查询来提取 Cognos 服务器上的所有数据和格式（正如人们所期望的那样），而是为每个分组触发一个单独的查询。有时，您可以通过尽可能简化主查询来提高性能。很多时候，人们只是复制详细查询，将其重命名为主查询，然后不做任何修改地连接回详细查询。删除主查询中不需要的任何内容。您的情况可能并非如此，但我们在报告中多次观察到这种行为，调整主查询通常会有所帮助。

使用列表部分时可能遇到的另一个问题（不确定这是否是分段的意思），具体取决于报表的构建方式，Cognos 有时会为每个部分触发重复的查询。您可以通过选择“工具>”来查看执行了多少查询。从菜单中显示“生成的 SQL/MDX”。