IBM Cognos BI 最佳实践报表设计高级提示和提示性能调优Word文档格式.docx
- 文档编号:16616714
- 上传时间:2022-11-24
- 格式:DOCX
- 页数:27
- 大小:266.61KB
IBM Cognos BI 最佳实践报表设计高级提示和提示性能调优Word文档格式.docx
《IBM Cognos BI 最佳实践报表设计高级提示和提示性能调优Word文档格式.docx》由会员分享,可在线阅读,更多相关《IBM Cognos BI 最佳实践报表设计高级提示和提示性能调优Word文档格式.docx(27页珍藏版)》请在冰豆网上搜索。
∙使用多个值需要适当的操作符,比如“in”:
[Ordernumber]in?
离散性:
简单值
∙等号表明了这一点。
∙值的范围需要适当的操作符,比如“in_range”:
[Ordernumber]in_range?
o如果一个参数在多个上下文中使用,那么对于是范围值的参数,所有引用都必须是范围值。
可选性:
可选的
∙这个筛选定义为可选的,所以参数也是可选的。
∙参数也可以是必需的。
如果一个参数在多个上下文中使用,那么对于可选的参数,所有引用都必须是可选的。
数据类型:
Numeric
∙这个参数是数字,因为Ordernumber数据项是数字。
现在,把参数的特性应用于引用它的提示。
这意味着,提示控件会体现参数的一部分特性,从而让提示控件与参数定义保持兼容。
如果在创建的提示页面中引用参数,会在运行时修改提示定义,以便与参数的基数、可选性和离散性匹配。
数据类型不匹配可能会导致运行时错误。
如果没有创建的提示页面,那么这些特性应用于生成的提示页面上的提示。
3.1.2数据项表达式
与通过宏表达式定义的参数不同,在数据项表达式中使用的参数是必需的。
3.1.3宏表达式
在宏表达式中定义的参数1可以是可选的或必需的,可以是单一值或多值。
请考虑宏表达式:
#prompt(‘pOrderNumber’,‘integer’)#
∙prompt()宏函数只接受单一输入值。
∙可以用prompt()定义多个值:
#promptmany(‘pOrderNumber’,‘integer’)#
∙提示宏总是简单值,而不是范围。
必需的
∙没有默认值(这个宏函数的第三个可选参数)表明了这一点。
∙包含可选参数的示例如下:
#prompt(‘pOrderNumber’,‘integer’,‘5’)#
3.2提示调节如何影响性能?
为了执行提示调节,IBMCognos8要检查查询,判断有哪些参数及其特性。
查询越大、越复杂,这个过程花费的时间越长。
在IBMCognos8.1中,一个包含200多个查询的客户报表需要超过40秒才能显示出第一个提示页面。
大多数时间花费在提示调节方面。
3.3在Cognos8.2中如何改进提示调节?
在IBMCognos8.2中通过三种方式改进提示调节:
∙更快的提示调节
∙用于提示调节调优的报表服务器属性
∙用于提示调节调优的查询属性
3.4IBMCognos8.2中更快的提示调节
首先,在IBMCognos8.2中提示调节过程已经得到优化,大大提高了速度。
与IBMCognos8.1相比,这个过程花费的时间减少了75%到90%。
例如,在IBMCognos8.2中客户示例报表的提示调节只花费了5秒,与IBMCognos8.1中的40多秒相比降低了80%。
只需迁移到IBMCognos8.2,就实现了80%的性能改进。
不需要采取其他措施。
3.5用于提示调节调优的报表服务器属性
IBMCognos8.2为整个系统和具体报表的提示调节调优提供了三个相互关联的选项。
第一个选项是一个针对整个报表服务器启用的报表服务器高级属性:
RSVP.PROMPT.RECONCILIATION。
这个属性有几个值:
COMPLETE-在显示第一个提示页面之前,调节所有查询。
这是默认设置,用来确保与以前版本的兼容性。
CHUNKED–分批调节所有查询,直到调节了第一个提示页面所需的参数为止。
以不固定的次序处理查询。
可以用高级服务器属性RSVP.PROMPT.RECONCILIATION.CHUNKSIZE修改CHUNK大小。
默认的CHUNK大小是5个查询。
GROUPED–按组调节查询,直到调节了第一个提示页面所需的参数为止。
这些组如下:
∙筛选的报表查询
∙筛选的提示查询
∙未筛选的报表查询
∙未筛选的提示查询
按这些组的次序处理查询,直到调节了第一个提示页面中引用的所有参数为止。
常常只需处理第一个或前两个组。
但是,在某些情况下,需要处理所有查询。
例如,如果在提示查询中的计算查询项中引用参数,就会发生这种情况。
报表服务器调节第一个提示页面的参数之后,向用户显示这个页面。
如果后续提示页面引用在已经处理的查询中没有的参数,在显示这些提示页面之前,报表服务器可能需要调节更多查询。
CHUNKEDGROUPED–分批调节查询组中的查询,直到调节了第一个提示页面所需的参数为止。
我们的客户场景只包含一个筛选的查询,但是假设报表中的所有200个查询都使用相同的参数进行筛选。
GROUPED会同时调节这200个查询,因为所有查询都属于筛选的报表查询组。
CHUNKED每次调节x个查询,x是CHUNKED大小(默认值为5)。
因此对于CHUNKEDGROUPED,将调节5个查询。
如果找到了第一个提示页面所需的参数,就显示页面。
如果没有找到,就处理后5个查询,直到找到参数为止。
以我们的客户报表为例,设置RSVP.PROMPT.RECONCILIATION=GROUPED会迫使提示调节首先处理包含筛选的查询(我们只有一个这样的查询)。
这导致客户示例报表的提示调节在IBMCognos8.2中只需花费不到1秒,与IBMCognos8.1中的40多秒相比性能提高了98%。
只需设置一个高级服务器属性,就实现了98%的性能改进。
坦白地说,这个示例不太典型,因为筛选的查询和非筛选的查询的比例高于一般水平。
但是,这个示例说明GROUPED调节选项的优点是只需要处理所有查询中的一部分。
关于如何处理大量的筛选查询,请参见“用于提示调节调优的查询属性”。
3.5.1最佳默认设置是什么?
如果使用COMPLETE之外的其他设置,可能会导致运行时错误,因为相同的参数可能在同一报表中以不同方式定义两次或更多次。
假设报表中有一个可选的筛选(比如Xin?
P1?
)和一个计算Y+?
。
筛选把P1定义为可选的和多值的。
计算把P1定义为必需的和单值的。
如果使用COMPLETE查询调节,就会处理所有查询,而且使用限制性最强的定义修改提示,这会产生必需的单值提示。
如果使用GROUPED,就只处理筛选的查询,这允许使用可选的多值提示。
如果用户跳过这个提示或者选择多个值,那么当处理计算时就会产生运行时错误。
说到这里要补充一点,在使用高级调节属性时,正确使用参数并解决这些不匹配的参数定义应该是创建者的责任。
在使用CHUNKEDGROUPED时,还可能有两个或更多筛选以不同方式定义同一个参数。
同样,这也是在创建报表时计划和实现不完善的表现。
出于性能考虑,CHUNKEDGROUPED是推荐的设置,因为它允许只处理部分查询组。
但是,应该进行适当的报表测试,以确保不会出现由于报表创建者使用参数的方式不一致所导致的运行时错误。
默认的CHUNK大小5对于大多数情况已足够。
3.6用于提示调节调优的查询属性
对于某些报表,仅仅设置高级报表服务器属性可能无法实现良好的性能,还需要手动调优。
报表创建者可以使用新的ReportStudio查询属性UseforParameterInfo决定提示调节的执行方式。
这个新属性只能在高级报表服务器属性RSVP.PROMPT.RECONCILIATION设置为GROUPED或CHUNKEDGROUPED时使用。
这个属性实际上创建一个新的查询处理组,系统在处理筛选的报表查询之前处理这个组。
新的处理次序是:
∙UseforParameterInfo=True查询
如果在第一个组中找到了所需的参数,就不再处理其他查询。
这个属性在两个场景中很有用。
3.6.1在多个查询筛选中使用相同的参数
仍然以包含200个查询的示例报表为例,假设所有200个查询中的筛选都引用相同的参数。
以前必须处理所有200个查询来调节参数。
实际上,只需处理其中任意一个查询,就可以收集到所需的信息。
报表创建者可以选择任何查询,并设置查询属性UseforParameterInfo=True。
系统只处理这个查询,就会找到所需的参数并显示第一个提示页面,不必处理其他查询。
3.6.2在每个查询筛选中使用不同的参数
现在,考虑一个完全不一样(有点儿不真实)的用例。
我们有200个查询,每个查询都引用一个不同的参数,在第一个提示页面中引用所有200个参数。
在这种情况下,必须处理所有查询,这会导致性能降低(回到5秒水平)。
有一个非常聪明的办法:
创建者可以创建一个定义所有200个参数的查询。
不创建任何引用这个新查询的布局(即,没有列表、交叉表或图表使用这个查询)。
只在这个查询上设置查询属性UseforParameterInfo=True。
现在,在运行报表时,只处理这一个查询。
因为在布局中不引用这个查询,它不会实际执行。
这样就解决了第一个提示页面的性能问题,而且不会有额外的开销。
包含200个查询而且每个查询使用不同的参数这样的示例有点儿极端,但是如果处理给定的查询或查询集造成了性能问题,就可以考虑使用这种方法。
估计只有非常少的报表需要使用UseforParameterInfo查询属性,因为IBMCognos8.2本身和使用RSVP.PROMPT.RECONCILIATIONGROUPED产生的性能改进能够解决大多数性能问题。
3.6.3提供不利提示
要确保您选择的查询提供所需的所有参数。
如果在没有定义所有参数的查询集上设置‘UseForParameterInfo’查询提示(hint),会对性能产生消极影响,因为第一个请求没有调节所有参数,还需要通过另一个请求获得其他参数的参数特性。
3.7SAP考虑事项
在有非层次化数据源变量的SAP环境中,变量数量大而且这些变量具有许多可能的值,这会显著影响性能。
建议不要在这些环境中使用高级服务器属性,但是可以使用‘UseForparameterInfo’查询提示改进性能。
4提示查询性能
提示查询用于填充提示控件。
在运行完提示查询之前,无法显示提示页面。
在默认情况下,这些查询在每次向用户显示提示页面时运行一次。
在改进提示查询性能时,要关注三个方面:
查询的数量
避免重复运行提示查询
并行地运行提示查询
4.1查询的数量
查询数量越大,处理提示页面花费的时间越长。
尽管下面讨论的机制可以减少所需的时间,但是有时候第一个提示页面包含的提示查询太多,必须处理它们才能显示提示页面。
可以把提示分割为两个或更多页面。
这样每个提示页面包含的查询就比较少了。
可以使用选项卡式的提示页面。
系统只运行实际向用户显示的提示控件所需的查询,不运行不活跃的选项卡的提示查询。
附录A讲解如何创建选项卡式提示界面。
可以使用隐藏在条件块中的提示,这些提示只在用户已经响应了一些提示并重新提示报表时显示。
同样,因为系统只运行实际向用户显示的提示控件所需的查询,不运行隐藏块中的提示查询。
4.2适当的提示控件
一些提示控件不适合容纳大量数据。
例如,包含100,000个条目的值提示(选择列表)性能会很差,而且使用很不方便。
对于这么大量的数据,更合适的控件是Select&
search提示、Cascading提示或Tree提示,因为它们在最初显示时并不装载整个数据集。
注意,如果创建者非要使用包含大量数据的提示,那么在默认情况下数据会在5000行处截断,而且系统并不给出警告。
可以使用提示控件的RowsPerPage属性显示更大的数据集。
4.3缓存提示查询
在IBMCognos8.1中,可以缓存提示查询。
如果提示中的值不经常变动(比如每天一次而不是随时),而且提示并不依靠另一个提示的值筛选提示查询,就可以使用这种技术。
例如,可以缓存父级联提示的值,但是不能缓存子(或孙)提示,因为这些后续提示依靠父提示的值执行查询。
使用作业执行提示查询并缓存报表的值。
用适当的调度计划(比如每天或每周)创建作业,从而反映提示值的变动频率。
在作业中添加需要刷新提示查询的报表之后,把DefaultRun选项设置为RunthereporttoRefreshtheReportCache(也可以为每个报表步骤设置这个选项)。
当作业运行时,它只执行提示查询并把结果缓存在ContentStore中。
如果在多个位置有提示,那么在作业步骤中设置这些位置,就会缓存所有位置的提示值。
当用户运行报表时,获取缓存的查询值;
这一般会提高性能。
注意,无论是否考虑性能因素,这也是减少对数据库的查询数量的好方法,因为在用户每次请求运行报表时不再需要执行提示查询了。
4.4并行地运行提示查询
如果提示值是高度动态的,缓存不是合适的选项,那么可以同时执行多个提示查询。
在默认情况下,单一报表中的所有查询一个接一个地运行。
可以同时运行提示查询或数据查询。
报表服务器使用helper的概念管理可以在报表服务器中同时执行的查询数量。
例如,把helper的数量设置为10就意味着整个报表服务器实例可以同时执行另外10个查询。
报表服务器高级属性RSVP.CONCURRENTQUERY.NUMHELPERSPERPROCESS用于设置服务器中可用的helper数量。
默认值是零。
如果不设置这个属性,就无法同时运行查询。
还必须使用报表服务器高级属性RSVP.CONCURRENTQUERY.MAXNUMHELPERSPERREPORT配置每个报表可以使用的helper数量。
默认值是1,即只允许每个报表每次执行一个查询;
必须把它至少设置为2,才能允许运行并行查询。
设置这两个选项之后,在默认情况下只对批执行运行并行查询。
这是因为在交互式执行时,这可能会导致运行查询,但是用户根本不看它的结果,因此不必要地消耗了资源。
假设一个报表有两个页面,每个页面有一个列表。
用户运行这个报表;
启用并行查询,让这两个列表查询同时运行。
用户看了第一个页面/列表,然后关闭浏览器。
第二个查询已经并行地运行了,但是未被使用,这浪费了资源。
稍后讨论如何更好地处理这种情况。
要想为交互式执行启用并行查询,需要把报表服务器高级属性RSVP.CONCURRENTQUERY.ENABLEDFORINTERACTIVEOUTPUT设置为True。
在给定的报表中,还必须使用查询属性ExecutionMethod决定哪些查询可以并行地运行:
图1.查询属性ExecutionMethod
在提示查询上设置这个属性允许它们并行地运行,这常常会提高性能。
5结束语
IBMCognos8.2显著改进了第一个提示页面的基本性能,即使不进行定制配置,性能也很好。
还可以通过以下措施进一步提高提示性能:
∙提示调节
∙明智的提示页面设计
∙提示查询缓存
∙并行的查询执行
为了进一步提高提示性能,建议在所有IBMCognos8.2服务器上设置RSVP.PROMPT.RECONCILIATIONCHUNKEDGROUPED(还应该进行适当的报表测试)。
6附录A–选项卡式提示页面
注意:
这份资料最初是一份单独的ProvenPractices文档。
这里的内容与原文档中相同。
6.1更快的选项卡式提示页面
这里的场景是,客户希望向最终用户提供报表,在提示页面中使用选项卡式用户界面而不是一系列提示页面。
最常用的提示出现在第一个选项卡中,其他选项卡显示不太常用的提示。
图2.选项卡式提示页面
我们见过的一些应用程序示例有多达60个提示,它们分布在6到8个选项卡上。
有两个问题会影响这些报表的性能。
首先,提示数量大意味着Cognos8在运行报表之前必须分析许多查询。
一般情况下,这意味着每个提示有一个查询,还要加上报表查询本身。
这个问题只能通过减少报表中使用的查询数量来解决,这超出了本文的范围。
第二,原来使用的HTML/JavaScript技术的性质决定了它们的性能非常差。
生成选项卡的标准HTML/JavaScript技术允许用户在不访问服务器的情况下切换选项卡。
这意味着必须在显示第一个选项卡之前填充所有提示(多达60个)。
因为在默认情况下查询是串行运行的,需要的提示查询越多,用户等待的时间就越长。
6.2解决方案概述
这个解决方案使用条件块显示提示。
选项卡本身仍然是用HTML和JavaScript创建的。
使用条件块的优点是,系统知道隐藏的块中的提示是不可见的,因此不运行填充它们所需的查询。
如果用户切换选项卡,提示变得可见并运行相关联的查询。
缺点是切换选项卡需要向服务器发出请求。
实现这种技术的提示页面使用条件块决定显示哪些提示。
请想像一系列重叠的矩形,在任何时候只显示其中的一个。
图3.条件块显示提示
这些块在任何时候只有其中的一个是可见的,但是所有选项卡都是一直可见的。
‘当前’选项卡的边框和文本颜色设置为黑色,让它看起来像在其他选项卡前面。
非当前的选项卡是灰色的,让它们不太突出。
图4.选定选项卡
从某种程度上来说,编写报表相当简单。
我们将创建一个条件块以及与选项卡数量相同的块——在以上示例中是4个。
然后,以表格单元格的形式创建基本选项卡结构(矩形),根据需要设置边框。
用HTML和一些简单的JavaScript创建选项卡中显示的文本。
当用户单击选项卡(实际上是单击选项卡中的文本)时,显示相关联的条件块,修改选项卡边框和文本颜色,显示相关联的块。
在后台,通过设置一个参数值指定显示哪个选项卡,然后重新提示报表。
在理想情况下,我们使用提示控件或提示按钮设置参数值并重新提示。
但是,没有提示控件或按钮能够满足要求。
一个提示可以设置参数值并重新提示(通过自动提交),但是无法看起来像文本。
6.3适用范围
这种技术应该适用于ReportNet或IBMCognos8的任何版本。
6.4未记录和不受支持的功能
正如下面详细讨论的,这个解决方案需要使用两个在IBMCognos8中未记录和不受支持的功能。
因此,在以后的版本中对这两个功能的支持可能会改变或完全取消,从而需要重写这个解决方案。
但是,这种风险很低,因为目前在这些方面没有修改计划。
6.5选项卡式提示报表项目
在我们的场景中,第一个选项卡让用户选择Orderyear(s),第二个选项卡让用户选择Productname(s),以便运行一个非常简单的列表报表。
我们将从头到尾介绍创建示例报表的整个过程。
为方便起见,我们只使用两个选项卡,每个选项卡上各有一个提示。
6.5.1创建基本报表
打开ReportStudio和GOSalesandRetailers包。
创建一个新的列表报表:
∙\Orders\Orderyear
∙\Orders\Productname
∙\Orders\Revenue
如图所示:
图5.创建基本报表
创建两个可选的详细信息筛选:
∙[Orderyear]in?
p_OrderYear?
∙[Productname]in?
p_ProductName?
这样就行了。
这就是将用来演示这种技术的基本报表。
6.5.2创建基本提示页面
尽管创建选项卡式提示用户界面并不难,但是过程很长。
大多数时间花在格式化方面。
实际功能花费的时间很少。
首先我们需要一个提示页面。
在报表中添加一个提示页面:
图6.添加一个提示页面
把一个一行两列的表格拖到提示页面体中,如图所示:
图7.把一个一行两列的表格拖到提示页面体中
我们暂时不管这个表格,但是稍后要使用它。
6.5.3创建选项卡体
条件块最终包含出现在每个选项卡上的提示。
图8.创建选项卡体
我们首先创建基本的选项卡体结构并使用一些文本项,让我们可以看出哪个选项卡是当前的。
把一个ConditionalBlock对象拖到页面体中:
图9.把一个ConditionalBlock对象拖到页面体中
选择条件块对象然后选择BlockVariable属性。
创建一个<
NewStringVariable>
,像这样:
∙Name:
TabToShow
∙Values:
Tab2
∙Expression:
ParamValue('
pTabToShow'
)
变量名TabToShow、值Tab2和参数pTabToShow很重要,这个项目要多次引用它们。
选择好块之后,把CurrentBlock属性设置为Other。
把一个文本项‘Tab1’拖到块中,像这样:
图10.把一个文本项‘Tab1’拖到块中
这个文本用于提醒我们哪个选项卡是当前正在查看的。
选择块,把CurrentBlock属性设置为Tab2。
‘Tab1’文本项会从块中消失。
把文本项‘Tab2’拖到块中,像这
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- IBM Cognos BI 最佳实践报表设计高级提示和提示性能调优 最佳 实践 报表 设计 高级 提示 性能