慢Cognos报告

Question

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

报告只是有嵌套超过周期/季度/半区/年

报表设计聚集列表内交叉表：

• 的mainqueryitem（queryitem）获得通过手动SQL 数据。
• 手册sql有4个查询inturn 联合。
• 所有4个查询是刚刚选择 来自不同表的接合（没有 组/排序/过滤器）。
• PlanningLevel（queryitem）从mainqueryitem获取 数据。 （例如：if mainqueryitem.name = 'Black' then mainqueryitem.quantity else null 所有PlanningLevel的DataItems使用上述格式）
• 报告页面由一个 交叉嵌套列表 内部的（分段）。
• 该列表与主查询关联 。
• 交叉表与计划级别 相关联。
• 交叉表也包含集合 。
• 提示页面包含一个 多选列表。

该报告甚至更小的提示值非常缓慢。

然后，我改变了属性“OverrideDimInfo”到“否” PlanningLevel queryitem从ReportNet迁移时有一些DimensionInfos已经（不知道这是什么）

然后报告跑得更快了不小的。的标准（< 1分钟）。 （400倍更快） 但更多没有。的选项/标准（> 2），报告仍然较慢。 （选择最大的报告 - 所有标准最多3.5小时）

当在最大报告的蟾蜍中运行时，mainqueryitem sql需要5分钟执行<。 最大的报告需要3.5小时，在reportnet中以分钟运行。

任何想法如何提高性能？

Answer 1

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

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