【问题标题】:Cognos Report Studio: Cascading Prompts populating really slowCognos Report Studio:级联提示填充速度非常慢
【发布时间】:2014-02-01 00:19:19
【问题描述】:

我有一个 Cognos 报告,其中有级联提示。层次结构在所附图像中定义。

第一个父级(除法)在 3-5 秒内填充两个级联子级。 但是当我选择任何策略(将填充下面的两个孩子)时,大约需要 2 分钟。

事实:

  • 两分钟后的结果集正常(~20行)
  • 所有提示后面的查询都很简单Select DISTINCT Col_Name
  • 我已经在所有提示列上创建了索引。
  • 尝试将本地缓存和执行方法开启为并发。
  • 我使用的是 Cognos Report Studio 10.1

任何帮助将不胜感激。 谢谢,

【问题讨论】:

  • 首先,尝试仅级联其中一个,并了解问题出在 AL-No 或 Claim No 中。索引应该在 where 列而不是 display 列上创建。您是否扫描事实表以获取不同的值?这不是一个好习惯。
  • 嗨,冉,对不起,我错过了那个。问题在于 Al-No,如果我从级联中删除 AL,一切都很顺利。 Policy-No 下的 Claim No. 被快速过滤。即使是不同的 Al-No 也会在几秒钟内显示出来。问题是当我们要根据选定的 Policy-No 过滤 Al-No 时。有很多重复的 Al-No。总计为 36652106,不同的是 22478。我从详细信息表中获取此信息。谢谢。
  • 我对一件事感到困惑,级联背后的查询逻辑是什么?当我们从级联提示中进行选择时,查询结束时实际发生了什么?任何想法在哪里挖?谢谢。
  • 您从什么类型的数据库中查询?
  • DW 内容存储在 DB2 中

标签: query-optimization cognos cognos-bi cognos-10


【解决方案1】:

有一种替代一次性维度表的方法。在框架中为您的 AL-No 提示创建一个查询主题。在查询本身中,构建一个获得不同 AL-No 的查询(您说这很快,可能是因为 AL-No 上有一个索引)。将其包装在对“#prompt('pPolicy')#' 进行过滤的选择中(假设您的策略提示键为 ?pPolicy?)

这将在将 Policy 发送到数据库之前强制将其放入 sql,但包装不同的 AL-No 将允许您使用 AL-No 索引。

select AL_NO from 
(
    select AL_NO, Policy_NO
    from CLAIMS
    group by AL_NO, Policy_NO
)
where Policy_NO = #prompt('pPolicyNo')#

【讨论】:

  • 您好,您的逻辑非常好。但是,如果我从不同的查询主题中获取所有三列,如何应用它。 (Policy_no、Emp_Al_No 和 Claim_no)这三个都是从不同的表中获取的。它们之间存在连接逻辑。我相信,我被卡住了,因为框架的设计者就是这样设计的。 :\
  • 我的解决方案需要更改框架。如果您无权访问,则不适用。如果您想保留他们的设置,但可以添加新的数据源,请尝试创建一个新的命名空间,并将您自己的自定义 QuerySubjects 放在那里。将查询主题指向您的数据库。如果需要,您可以为每个提示查询设置一个单独的查询主题,您不必为多个不同的提示使用单个查询主题。
【解决方案2】:

您的问题是表格扫描过多。通常,人们会从基于维度的表而不是事实表构建提示页面,尽管我承认这对于级联提示并不总是可行的。理想的解决方案是使用这些不同的值创建一次性维度表,然后严格按照提示建模。

注意索引每个字段,因为值的选择性将不会使用索引。字段的复合索引可能会起作用。与您对 DDL 进行更改的任何时候一样 - 打开 SQL 分析器并查看 SQL Cognos 生成的内容,然后在更改之前/之后运行解释计划。

【讨论】:

  • 嘿托德,是的,我的想法是一样的。没有其他选择了。我在框架中交叉检查了数据获取范例,并且连接模式需要很多时间。模式必须是这种方式才能获取有意义的数据。感谢您的洞察力。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2017-07-19
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2012-08-19
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多