IBM Cognos BI 最佳实践_报表设计高级提示和提示性能调优

IBMCognosBI最佳实践:报表设计高级提示和提示性能调优1简介1.1目的本文档旨在向报表创建者展示如何处理第一个提示页面性能低下的问题。1.2适用范围这里的信息只适用于IBMCognos8.2BI。2第一个提示页面的性能当用户运行包含多个复杂查询的报表时，常常需要等待很长时间才会看到第一个提示页面出现。例如，在一个客户场景中，报表用了40秒才显示出第一个提示页面。可以通过两方面的努力改进第一个提示页面的性能：1)减少提示调节（promptreconciliation）的时间2)减少为提示控件获取数据的时间3提示调节3.1什么是提示调节？提示调节确保参数定义与参数的用法匹配。在筛选和计算中定义参数。在提示中使用定义好的参数。参数定义包含几个关键项：基数–可以提供给参数的输入值的数量。离散性–决定输入值是定义单一值，还是定义一个值范围。可选性–决定参数在筛选或计算的上下文中是必需的，还是可选的。数据类型–为了与引用的其他数据项或常量匹配，在筛选或计算的上下文中期望的数据类型。数据类型可以是Numeric、Date、Time、DateTime、Interval、String或MemberUniqueName(MUN)。3.1.1筛选表达式请考虑可选的筛选：[Ordernumber]=?pOrderNumber?通过分析这个筛选，可以判断出参数pOrderNumber的一些性质：基数：单一值等号表明只能使用单一值。使用多个值需要适当的操作符，比如“in”：[Ordernumber]in?pOrderNumber?离散性：简单值等号表明了这一点。值的范围需要适当的操作符，比如“in_range”：[Ordernumber]in_range?pOrderNumber?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定义为可选的和多值的。计算把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讲解如何创建选项卡式提示界面。可以使用隐藏在条件块中的提示，这些提示只在用户已经响应了一些提示并重新提示报表