
⏹
更多企业学院: | ||
《中小企业管理全能版》 | 183套讲座+89700份资料 | |
《总经理、高层管理》 | 49套讲座+16388份资料 | |
《中层管理学院》 | 46套讲座+6020份资料 | |
《国学智慧、易经》 | 46套讲座 | |
《人力资源学院》 | 56套讲座+27123份资料 | |
《各阶段员工培训学院》 | 77套讲座+ 324份资料 | |
《员工管理企业学院》 | 67套讲座+ 8720份资料 | |
《工厂生产管理学院》 | 52套讲座+ 13920份资料 | |
《财务管理学院》 | 53套讲座+ 17945份资料 | |
《销售经理学院》 | 56套讲座+ 14350份资料 | |
《销售人员培训学院》 | 72套讲座+ 4879份资料 | |
⏹
更多企业学院: | ||
《中小企业管理全能版》 | 183套讲座+89700份资料 | |
《总经理、高层管理》 | 49套讲座+16388份资料 | |
《中层管理学院》 | 46套讲座+6020份资料 | |
《国学智慧、易经》 | 46套讲座 | |
《人力资源学院》 | 56套讲座+27123份资料 | |
《各阶段员工培训学院》 | 77套讲座+ 324份资料 | |
《员工管理企业学院》 | 67套讲座+ 8720份资料 | |
《工厂生产管理学院》 | 52套讲座+ 13920份资料 | |
《财务管理学院》 | 53套讲座+ 17945份资料 | |
《销售经理学院》 | 56套讲座+ 14350份资料 | |
《销售人员培训学院》 | 72套讲座+ 4879份资料 | |
⏹
更多企业学院: | ||
《中小企业管理全能版》 | 183套讲座+89700份资料 | |
《总经理、高层管理》 | 49套讲座+16388份资料 | |
《中层管理学院》 | 46套讲座+6020份资料 | |
《国学智慧、易经》 | 46套讲座 | |
《人力资源学院》 | 56套讲座+27123份资料 | |
《各阶段员工培训学院》 | 77套讲座+ 324份资料 | |
《员工管理企业学院》 | 67套讲座+ 8720份资料 | |
《工厂生产管理学院》 | 52套讲座+ 13920份资料 | |
《财务管理学院》 | 53套讲座+ 17945份资料 | |
《销售经理学院》 | 56套讲座+ 14350份资料 | |
《销售人员培训学院》 | 72套讲座+ 4879份资料 | |
IBM Cognos BI 最佳实践: 报表设计高级提示和提示性能调优
1 简介
1.1 目的
本文档旨在向报表创建者展示如何处理第一个提示页面性能低下的问题。
1.2 适用范围
这里的信息只适用于 IBM Cognos 8.2 BI。
2 第一个提示页面的性能
当用户运行包含多个复杂查询的报表时,常常需要等待很长时间才会看到第一个提示页面出现。例如,在一个客户场景中,报表用了 40 秒才显示出第一个提示页面。
可以通过两方面的努力改进第一个提示页面的性能:
1) 减少提示调节(prompt reconciliation)的时间
2) 减少为提示控件获取数据的时间
3 提示调节
3.1 什么是提示调节?
提示调节确保参数定义与参数的用法匹配。在筛选和计算中定义参数。在提示中使用定义好的参数。
参数定义包含几个关键项:
∙ 基数 – 可以提供给参数的输入值的数量。
∙ 离散性 – 决定输入值是定义单一值,还是定义一个值范围。
∙ 可选性 – 决定参数在筛选或计算的上下文中是必需的,还是可选的。
∙ 数据类型 – 为了与引用的其他数据项或常量匹配,在筛选或计算的上下文中期望的数据类型。数据类型可以是 Numeric、Date、Time、Date Time、Interval、String 或 Member Unique Name (MUN) 。
3.1.1 筛选表达式
请考虑可选的筛选:
[Order number] = ?pOrderNumber? |
通过分析这个筛选,可以判断出参数 pOrderNumber 的一些性质:
基数:单一值
∙ 等号表明只能使用单一值。
∙ 使用多个值需要适当的操作符,比如“in”:
[Order number] in ?pOrderNumber? |
离散性:简单值
∙ 等号表明了这一点。
∙ 值的范围需要适当的操作符,比如“in_range”:
[Order number] in_range ?pOrderNumber? |
o 如果一个参数在多个上下文中使用,那么对于是范围值的参数,所有引用都必须是范围值。
可选性:可选的
∙ 这个筛选定义为可选的,所以参数也是可选的。
∙ 参数也可以是必需的。如果一个参数在多个上下文中使用,那么对于可选的参数,所有引用都必须是可选的。
数据类型:Numeric
∙ 这个参数是数字,因为 Order number 数据项是数字。
现在,把参数的特性应用于引用它的提示。这意味着,提示控件会体现参数的一部分特性,从而让提示控件与参数定义保持兼容。如果在创建的提示页面中引用参数,会在运行时修改提示定义,以便与参数的基数、可选性和离散性匹配。数据类型不匹配可能会导致运行时错误。如果没有创建的提示页面,那么这些特性应用于生成的提示页面上的提示。
3.1.2 数据项表达式
与通过宏表达式定义的参数不同,在数据项表达式中使用的参数是必需的。
3.1.3 宏表达式
在宏表达式中定义的参数 1 可以是可选的或必需的,可以是单一值或多值。
请考虑宏表达式:
#prompt ( ‘ pOrderNumber ’ , ‘ integer ’ )# |
基数:单一值
∙ prompt() 宏函数只接受单一输入值。
∙ 可以用 prompt() 定义多个值:
#promptmany ( ‘ pOrderNumber ’ , ‘ integer ’ )# |
离散性:简单值
∙ 提示宏总是简单值,而不是范围。
可选性:必需的
∙ 没有默认值(这个宏函数的第三个可选参数)表明了这一点。
∙ 包含可选参数的示例如下:
#prompt ( ‘ pOrderNumber ’ , ‘ integer ’ , ‘ 5 ’ )# |
3.2 提示调节如何影响性能?
为了执行提示调节,IBM Cognos 8 要检查查询,判断有哪些参数及其特性。查询越大、越复杂,这个过程花费的时间越长。
在 IBM Cognos 8.1 中,一个包含 200 多个查询的客户报表需要超过 40 秒才能显示出第一个提示页面。大多数时间花费在提示调节方面。
3.3 在 Cognos 8.2 中如何改进提示调节?
在 IBM Cognos 8.2 中通过三种方式改进提示调节:
∙ 更快的提示调节
∙ 用于提示调节调优的报表服务器属性
∙ 用于提示调节调优的查询属性
3.4 IBM Cognos 8.2 中更快的提示调节
首先,在 IBM Cognos 8.2 中提示调节过程已经得到优化,大大提高了速度。与 IBM Cognos 8.1 相比,这个过程花费的时间减少了 75% 到 90%。
例如,在 IBM Cognos 8.2 中客户示例报表的提示调节只花费了 5 秒,与 IBM Cognos 8.1 中的 40 多秒相比降低了 80%。
只需迁移到 IBM Cognos 8.2,就实现了 80% 的性能改进。不需要采取其他措施。
3.5 用于提示调节调优的报表服务器属性
IBM Cognos 8.2 为整个系统和具体报表的提示调节调优提供了三个相互关联的选项。
第一个选项是一个针对整个报表服务器启用的报表服务器高级属性:RSVP.PROMPT.RECONCILIATION。这个属性有几个值:
COMPLETE - 在显示第一个提示页面之前,调节所有查询。这是默认设置,用来确保与以前版本的兼容性。
CHUNKED – 分批调节所有查询,直到调节了第一个提示页面所需的参数为止。以不固定的次序处理查询。可以用高级服务器属性 RSVP.PROMPT.RECONCILIATION.CHUNKSIZE 修改 CHUNK 大小。默认的 CHUNK 大小是 5 个查询。
GROUPED – 按组调节查询,直到调节了第一个提示页面所需的参数为止。这些组如下:
∙ 筛选的报表查询
∙ 筛选的提示查询
∙ 未筛选的报表查询
∙ 未筛选的提示查询
按这些组的次序处理查询,直到调节了第一个提示页面中引用的所有参数为止。常常只需处理第一个或前两个组。但是,在某些情况下,需要处理所有查询。例如,如果在提示查询中的计算查询项中引用参数,就会发生这种情况。报表服务器调节第一个提示页面的参数之后,向用户显示这个页面。如果后续提示页面引用在已经处理的查询中没有的参数,在显示这些提示页面之前,报表服务器可能需要调节更多查询。
CHUNKED GROUPED – 分批调节查询组中的查询,直到调节了第一个提示页面所需的参数为止。
我们的客户场景只包含一个筛选的查询,但是假设报表中的所有 200 个查询都使用相同的参数进行筛选。GROUPED 会同时调节这 200 个查询,因为所有查询都属于筛选的报表查询组。CHUNKED 每次调节 x 个查询,x 是 CHUNKED 大小(默认值为 5)。因此对于 CHUNKED GROUPED,将调节 5 个查询。如果找到了第一个提示页面所需的参数,就显示页面。如果没有找到,就处理后 5 个查询,直到找到参数为止。
以我们的客户报表为例,设置 RSVP.PROMPT.RECONCILIATION = GROUPED 会迫使提示调节首先处理包含筛选的查询(我们只有一个这样的查询)。
这导致客户示例报表的提示调节在 IBM Cognos 8.2 中只需花费不到 1 秒,与 IBM Cognos 8.1 中的 40 多秒相比性能提高了 98%。
只需设置一个高级服务器属性,就实现了 98% 的性能改进。不需要采取其他措施。
坦白地说,这个示例不太典型,因为筛选的查询和非筛选的查询的比例高于一般水平。但是,这个示例说明 GROUPED 调节选项的优点是只需要处理所有查询中的一部分。关于如何处理大量的筛选查询,请参见“用于提示调节调优的查询属性”。
3.5.1 最佳默认设置是什么?
如果使用 COMPLETE 之外的其他设置,可能会导致运行时错误,因为相同的参数可能在同一报表中以不同方式定义两次或更多次。
假设报表中有一个可选的筛选(比如 X in ?P1?)和一个计算 Y + ?P1? 。
筛选把 P1 定义为可选的和多值的。
计算把 P1 定义为必需的和单值的。
如果使用 COMPLETE 查询调节,就会处理所有查询,而且使用限制性最强的定义修改提示,这会产生必需的单值提示。
如果使用 GROUPED,就只处理筛选的查询,这允许使用可选的多值提示。如果用户跳过这个提示或者选择多个值,那么当处理计算时就会产生运行时错误。
👁️ 阅读量:0
© 版权声明:本文《IBMCognosBI实践之报表设计高级提示与提示性能调优》内容均为本站精心整理或网友自愿分享,如需转载请注明原文出处:https://www.zastudy.cn/jiangzuo/1685901409a51957.html。