Webi Intelligence报表性能调优技巧

1.1 – 使用HTML Interface来得到更快的表示/刷新报表体验

1.4 – 确保JRE Client Side Caching是打开的

在遇到JRE性能问题的时候，第一件事情需要确认的就是JRE Caching是打开并WORKING的。有很多JER性能问题是由于JRECaching被禁止或者配置错误造成的，也有可能有的系统由于配置的关系，造成JRE Caching并不工作从而导致性能问题。

Citrix系统上面曾经有个这样的事例。这个系统上，每个用户都有唯一但是动态的“User”文件夹，每个session的缓存有可能不是存放在一起的。解决方法就是将缓存设定到同一个地址，这样在不同session直接就不存在缓存的问题。

下面的Wiki有关于JER Caching的详细配置及检测方法。

WIKI -Tips for Fine Tuning Performance for the Webi Applet

1.5 – 确保您的JER没有Security Change相关的问题发生

Java Security Update造成了非常多的关于Java Applet Interface的问题。下面是大家比较常见的一些问题：

WIKI – Web Intelligence and Oracle Java Runtime Engine Known Issues

上面的文章安装XI3.1和BI4.x分成不同章节进行了说明。下面这2个是BI4.0和BI4.1的具体章节。

这些问题都不是技术上的性能问题，但这些问题的存在会使您的终端用户在产品使用过程中遇到性能过慢等问题。

SAP一般在每几个月提供Patches/Support Packs等更新，一旦Oracle的Security机制发生更新，由于相对Oracle的更新BI的更新会稍微有些延迟，这就会导致您使用过程中出现由于oracle security 机制变更引起的问题。所以当您升级JRE版本的时候，请考虑以上因素再决定是否升级。

1.6 – 选择适合您的客户端 – Webi Rich Client vs HTML vs Applet Interfaces

每个客户端类型都有自己的特点及优点。在功能，性能以及简易型之间找到平衡是选择适合您的客户端的唯一标准。

WebI用户指南的章节1.4解释了各种客户端的区别，详读会有助于您的选择。使用哪种客户端并没有硬性规定，有的用户也许喜欢用HTML
interface查看报表，但是用Rich Client Interface来新建和编辑报表。

Help portal里面Web Intelligence相关文档的链接：

PORTAL – SAP BusinessObjects Web Intelligence 4.1 – SAP Help Portal Page

下面是BI4.1 SP6的文档链接：

GUIDE – BI 4.1 SP06  Web Intelligence User Guide – Direct Link

一般情况下，我们会做如下推荐：

Webi HTML Interface

适合主要查看已经做好的报表，或者只做少许更改的用户。

HTML interface在内部连接的是64位Backend server，但是比Applet Interface少些功能。

Webi Applet Interface

适合报表设计者，或者需要对报表进行数据分析的用户。

Applet Interface也是内部连接的是64位Backend server，并且通常能够处理大数据量或者计算量的操作，他依靠Backend server进行大压力操作。但是这是基于Web Application，所以在长时间操作，或是刷新大数据时会经常发生timeout.

Webi Rich Client Interface

拥有基本上所有的Applet Interface的功能，并且有自己的附加功能。推荐高级版设计者使用，以便在对大型文档操作时获得更稳定的设计环境。

可连接本地数据源比如Excel & Access，同样可以使用3层模式来连接Backend Server以获得更高的数据处理能力。

第2章 –实施最佳方案.     

当说到实施最佳方案，我们通常是指在业务中优化Web Intelligence报表在实际业务中的使用流程及方法。本章节将为你介绍一些较为常用的业务优化方案..

2.1 –通过报表计划来节省时间和资源

这看起来很容易，但是实际上无数的support incident都是可以用合理利用计划和实时参照来规避的。.

您可以以5分钟为分界点，如果一个报表需要5分钟以上的时间刷新才能得到结果，那么建议用计划。计划报表可以将进程交给后台服务器处理从而将您从屏幕前漫长的等待中解脱出来。

计划报表的好处

• 在运用正确的情况下可以降低用户的等待时间
• 允许均衡执行时间避免用户高峰
• 可以帮助减少并发用户
• 减小对数据库的压力
• 可以用报表链接来合并实例从而产生更小更快的文档

研究表明在当今世界，终端用户甚至都不愿意用5秒多来等待视频加载,比如你在YouTube上点了播放按钮，你会愿意花5秒中等待视频加载吗？我想大部分人会直接放弃或是反复刷新。对于WebApplication用户来说也是一样的，如果一张报表用了一两分钟都打不开，用户就会选择关闭报表重试，或者干脆放弃。这样做的风险就是不断增加的请求加大了服务器的工作量。这有个典型的例子：

1. 用户A 登录到 BI
   Launchpad 并浏文档Monster
   Finance Report
2. 用户A查看了文档内容并点击了刷新按钮用来取得最新数据
3. 两分钟，用户A看到报表仍在刷新中，他失去了耐心认为刷新动作卡住了，于是关掉了浏览窗
4. 用户A决定碰碰运气再试一遍。这其实创建了一个获取相同数据的新请求，那么就可能和已经在BI服务器和数据库正在执行的请求发生冲突
5. 又过了几分钟，用户放弃操作并退出。但是他并不知道自己的操作用掉了多少后台的资源

在上述的例子中，我们看到了下列不好的结果：

• 用户A永远得不到他想要的报表，而且拥有了一次非常糟糕的用户体验
• 后台资源被浪费却没有达到期望的结果.

通过合理的利用流程安排和计划，上述的问题都是可以避免的。下面为大家介绍一下如何合理的优化计划：.

1. 指导用户用计划来完成需耗时5分钟以上的工作
2. 鼓励用户在非高峰时段运行计划
3. 按照终端用户需要的格式例如Excel，Text或PDF等执行计划。这样可以节省时间和资源
4. 当多个用户对同样报表有不同需求时合理优化发布

更多计划 和发布相关内容, 请参照下属链接：

文档 – BI 4.1 SP6BI 启动板用户指南 – 第七章–计划对象

文档 – BI 4.1 SP6 BI启动版用户指南 – 第十章–关于发布

2.2 –使用CMC中计划时的重试功能

尽管这不是一个真正的性能改善技巧，但是我们发现很多人都忽略了通过CMC执行报表计划时的重试选项。该功能允许设置当计划失败时间隔多久执行多少次的重试操作。.

下面是BI 4.1中该选项的截图：.

这个选项可以帮你节省计划失败后重新手动计划的时间。有些偶然的计划失败往往是由于服务器资源的不足等原因造成的，通过这种自动重试就可以是你在一台负荷大的服务器上避免许多类似的临时失败。
.

该选线既可以在默认设置/重复发生中设置也可以在计划/重复发生中设置。不同点在于前者可以适用于多有的计划工作，而后者作用于个别的计划工作。.

注意:  该选项只在CMC上进行计划时存在， BI Launchpad上目前还没有该功

2.3 –通过限制功能来减少环境中的计划实例数

再介绍个小功能叫做限制，同样可以帮助改善系统性能。实例限制可以设置在文件夹或具体对象上面。.

基本概念就是通过该功能来限制文件夹和对象保有的实例数，一旦超过这个限制，CMS会自动清理久实例来减少CMS DB和File
Store 磁盘中的数据，释放一定资源。.

下面是CMC 帮助文档中关于如何激活设定限制的介绍：.

设置限制可以允许自动删除BI Platform上的报表实例, 如果限制指定在文件夹上则作用于文件夹中的所有对象。

对于文件夹，您可以设定：

• 每个对象，用户和用户组的限制实例数
• 在多少天后为某个用户或组群删除实例

.
在CMC上激活限制功能的方法

1. 登录CMC，打开文件夹页面
2. 选择目标文件夹，点击限制
3. 在限制画面中，选择当某个对象存在多余N个实例时，删除多余的实例选项，然后输入限定的实例数，默认值为100.点击更新
4. 限制用户和组群的实例数，点击为一下用户/组删除多余的实例旁边的添加按钮
5. 选择一个用户或者组，点击>添加到选定的用户/组，点击OK
6. 为添加后的用户或组设置每个用户每个对象的最大实例数。默认值为100
7. 限制每个用户和组实例保存天数，点击在N天后删除以下用户/组的实例旁边的添加按钮
8. 选择一个用户或者组，点击>添加到选定的用户/组，点击OK
9. 为添加后的用户或组设置最长实例期限。默认值为100
10. 点击更新

下面是该功能的设定截图：

2.4 –调整平台搜索

您是否遇到过在没有任何用户操作下系统资源被占用的情况?如果有那很有可能是因为平台搜索.

什么是平台搜索？.

平台搜索功能使您可以在BI Platform存储中搜索需要的内容。它可以根据内容的关联性对搜索的结果进行分组和排序。.无疑这是一个很好的功能，我们只是需要在调整系统性能的时候对其加以考虑和调整。.

这面的文档介绍了这个功能以及如何配置：.

文档– BI平台管理员指南(BI 4.1 SP6) – 第二十二章– 平台搜索..

当BI4.0发布后，技术支持看到很多用户在迁移到4.0后遇到了很多的系统性能，资源消耗问题。.经过大量的研究，我们发现大多数的事例中问题都是由于新系统中对添加对象的索引导致的。那它是如何影响性能的呢？

平台查询程序会检测是否又新的内容需要被索引化和目录化。这就意味着任何一个新对象 (Webi Doc, Universe,Crystal Report等) 都需要进行分析，目录化，索引化。而完成后那个这些工作需要APS 上的搜索服务，当添加的报表存在很多的数据，对象，关键字时就会给系统带来很大负荷.如果您发现这占用了大量的系统资源时，可以用计划选项控制检索执行的时间。避开业务高峰时段应该可以帮助您改善性能。

相关信息您可以参照管理者指南文档的22章内容。简而言之，除非您有无穷无尽的资源否则一定要确保平台查询在您的监控范围内。

更多信息:

KBA – 1640934– How to safely use Platform Search Service in BI 4.0 without overloading the server?

BLOG – What is the optimal configuration for Platform Search in BI 4.x? – By Simone Caneparo

第3章 –报表设计最佳方案

本章节将为大家介绍一些通过报表设计提高报表性能的技巧，这些内容不单适用于新建的报表，对既存的报表也是可以少做改动进行应用的。.

强烈推荐这篇由William Marcy撰写的报表设计技巧相关文档，该文档对报表设计提供了绝对的指导作用，建议报表设计者必读。

文档 – Webi 4.x Tricks – By William Marcy & various other contributors

3.1 –避免超大文档

所谓的超大文档是指含有多张报表的文档。一个 Web Intelligence文档可以含有多个报表。当我们说起报表时通常是指文档中的报表页。我们经常说报表来表达一个Webi文档,其实这种说法是不对的，一个文档可以包含多张报表。.

创建文档时，我们需要从实际业务需求出发。我们可以想相关人员确认下列问题：.

1. 这个文档的主要目的是什么?
2. 这个文档需要给出什么答案?
3. 多少不同的用户会用这个文档?
4. 这个文档是否可以根据具体的需求分割成不同的多个文档?.

通过上面的问题我们可以钻取到客户的真正需求，通过这些答案来避免资源的浪费。也就是说如果我们设计了一个包含所有客户可能会看的脚本的超大文档，那我们就会浪费很多时间在报表的设计和阅读上。举个例子，如果一个文档只有10-20% 会被应用于用户的日常使用，那么剩余的80-90% 就是浪费了。.一旦我们了解了客户的业务需求，我们就可以设计出更有针对性的文档。.

下面是一些您在设计文档时需要铭记于心的建议：.

1. 避免在同一个文档中用大量的报表页。
   1. 10以下是比较合理的数值
   2. 应避免用超过20个报表页
2. 针对特殊的业务需求创建小文档便于提高执行和分析速度。
   1. 用文档链接来关联小文档，相关内容请参照技巧3.1
   2. 一个文档针对1-2个业务需求
3. 在文档上只提供业务上需要的数据
   1. 每个文档50.000行数据属于一个比较合理的数据量
   2. 每个文档不要超过500.000行
4. 不要添加跟业务需求无法的数据源
   1. 每个文档5个数据源是比较合理的
   2. 每个文档最多不要超过 15个数据源

当然在实际的操作中会有一些例外和上述建议不太符合，但是我们仍然建议您寻找其他方法来防止报表过大。.

使用基于您业务需求的可重复利用的小文档将给您带来如下好处：

• 减少文档加载的时间
• 减少刷新的时间
• 减少客户端和服务器端的资源占用
• 改善了修改文档时的速度
• 改善了用户查询分析的速度

3.2 –运用报表链接

报表链接可以有效的关联文档，通过把文档互相关联的方式减小单个文档的大小，从而达到提高报表性能的目的。这个概念非常简单，就是在一个文档中插入另外一个文档的超链接，也可以通过超链接传递提示值到目标文档。下面这个例子可以为您简单介绍一下这个概念：

• Sales_Summary是一张总结公司XYZ在100地区销售情况的报表
• Sales_Summary报表上有一个超链接允许用户钻取到另一张叫Sales_Details的报表查看100个地区中任何一个地区的具体销售情况
• Sales_Summary上设置了每天晚上执行计划，大概需要20分钟执行完毕
• 用户只需要几秒钟就可以看到最新的报表实例
• 用户可以通过报表链接和过滤器提示值钻取到任何一个地区查看数据
• 因为用到了提示值过滤，所以用户点击链接后看到的就是他想看到的特定区域的值.

在上面的例子里，我们可以看到运用链接的一些好处：

1. Sales_Summary报表上只有总结的内容，比总结和详细放在一张报表上执行起来要快很多
2. Sales_Summary报表单独执行起来很快
3. 当钻取的时候用户打开的是一张只包含详细内容的独立报表所以速度想对来说也会很快

在Web Intelligence用户指南的章节5.1.3 -Linking to another document in the CMS中也有相关内容供您参考

.文档 – Web Intelligence用户指南– BI 4.1 SP06 – 第五章

创建文档链接最简单的方法就是用超链接向导，目前HTML模式下是有直接添加文档链接的功能的。如果您需要手写文档链接，建议您参考下面的文档：.

文档 – Viewing Documents Using OpenDocument

下面是添加文档链接的功能键位置和截图：

这些操作可能会花去你一些报表设计的时间，精力，但是可以让您的用户节省很多等待的时间。在添加文档链接时您可以选择是否需要打开目标文档时自动刷新或是打开最新的文档实例，通常我们建议尽量选择打开文档实例。这样可以把加载的工作交给后台从而减少了用户看到报表的时间。

3.3 –避免在不必要的情况下使用自动调整

自动调整的功能可以让您设计的单元格，表和交叉表的大小随着数据的大小自动改变。下面是Applet 界面下该功能的设置画面：

该功能有利于报表画面的显示，但是同时也会对报表的性能有一定的影响。.

注意:  该选项默认值为勾选。所以了解该功能如何影响报表性能是十分必要的。.

那么该功能到底是如何影响报表的性能的呢？.

勾选上该选项后，当每次报表展现之前Processer server都会根据数据从新评估一遍单元格或是表格的大小。简而言之，这个功能增加了服务器报表展现的工作。而固定的大小则不会需要这样的额外工作。

所以您可以想象当报表有很多行数据和很多页时，在报表展现之前服务器需要做的工作会多出多少。如果报表行数页数不多，这个选项的影响可以忽略，但是如果用到大报表的时候这个影响就不能忽略了。

3.4 –尽可能多用查询过滤器来替代报表过滤器.

查询过滤器会直接添加过滤条件到 SQL语句中,从而限制数据库的返回数据集。.

报表过滤器则是针对报表上已经从数据库取得的数据在报表层面进行过滤。实际上数据库返回的数据还是存在的，只不过展示出来的是没有被过滤掉的一部分。.

了解这二者的区别是十分重要的，可以帮助您减少不必要的报表生成和刷新时间。查询过滤器最好在语意层设计不过您也可以手动在报表上添加,下面是在查询面板中添加查询过滤器的画面：

上述两种添加方法都是在 SQL语句中添加WHERE子句来限制返回的数据。.

下面是报表过滤器的截图：

在这种报表过滤器中，及时您选择了指定的年份，所有年份的数据也已经是全部从数据库返回了，只有您指定的年份数据会在报表层面显示出来。所以在考虑报表性能的时候，请注意这个设计点。.

3.5 –避免在图表上用过多的数据点

BI 4.0引入了一种新的图表引擎叫 Common Visualization Object Model,简称 CVOM.  这个一种用SDK可以为Web Intelligence或者SAP其他产品提供图表视图功能。该服务作为一种视图服务加载在Adaptive Process Server (APS) 上。

另外,尽管这个服务是默认添加在APS 服务器上的，但是根据您部署的情况，可以按照系统配置向导或是APS分割说明将其单独分割出来。.

在CMC>APS>编辑公共服务下，您会看到下列服务列表：

有时候在生成图表时，由于资源分配情况该服务会出现瓶颈导致性能问题。我们将在稍后的章节中讨论服务器的分割问题。.

我们曾经问过开发如何能改善视图性能，开发的建议简单明了，那就是尽量避免使用有很多数据点的大图表，尽量多用数据比较少的多个小图表来代替它。.

文档 – Webi 用户指南 – Chapter 4.3

3.6 –限制使用分析范围.

下面的内容摘自WebI用户指南:

查询的分析范围是用户能够从数据库检索的额外数据，这些数据能够提供有关返回的结果的更多详细信息。

这些额外数据不会出现在初始结果报表中，但它会在数据多维数据集中保持可用。可以将此数据提取到报表中，以便随时访问更多详细信息。将数据细化到较低明细级别的过程称为向下钻取对象。

在Universe 中，分析范围对应于为查询选取的对象下面的层次级别。例如，对象“Year”（年份）下一级别的分析范围将包括对象“Quarter（季度）”，对象“Quarter（季度）”会出现在紧随“Year”（年份）的下面。

您可以在构建查询时设置此级别。它允许对象降低层次以包含在查询中，而不让它们出现在“结果对象”窗格中。Universe 中的层次允许您选择分析范围，相应地，也允许您选择可用的钻取级别。也可以通过选择要包含在范围中的特定维，创建自定义分析范围。

分析范围是为钻取维度提前加载数据的一个好方法，也会影响到产品的性能。  需要注意添加对象到分析范围，就相当于把他们加到了发送到DB的查询中，这会影响实时查询，需要您谨慎决定使用与否。

另外，报表链接可以提供类似的按需向下钻取功能，同时确保钻取的额外数据只在用户需要时被读取，在应用时更加普遍。.

下面是一个分析范围的例子，尽管结果中只有年但是分析范围中有季度，月份和星期等对象：

这实际上是把星期，月，季度加到了查询中，返回的数据就会相应变多。.简言之，您需要确保分析范围的使用是经过深思熟虑的并且会受益于终端用户的。.

3.7 –显示数据提供者的数量

我们推荐的最佳方案是控制数据提供者的数量在15一下以确保报表执行速度。若果您需要15以上的数据源，那么建议您用ETL之类的工具来抽取数据，合并数据。从而在BI 产品之前一层完成数据的提炼工作。.

现在Webi Processing Server设计是按顺序执行数据提供源的，这就意味着数据源是一个一个的一次执行而不是平行执行，那么报表取数据的时间就是所有数据源执行的累加时间。.如下图：.

除此之外，如果有多个数据源的话不同数据源之间的维度合并也会带来额外的时间消耗，所以为了确保报表的性能尽量使用简单的报表设计。.

3.8 –不要关闭报表缓存

.Web Intelligence用磁盘和内存缓存机制来改善文档和universe的加载、运行速度。.
通常情况下缓存功能都是默认打开的，需要您注意的是有些情况下缓存功能是不能用：.

下面这些函数会强制文档忽略缓存：.

CurrentDate()

CurrentTime()

CurrentUser()

GetDominantPreferredViewingLocale()

GetPreferredViewingLocale()

GetLocale()

GetContentLocale()

如果您在文档中用到了上述函数，那么缓存是不会被调用的。这些常见函数的影响需要您注意。.

目前，缓存是作用于整个文档而不是当个报表页，所以不管这些函数被用到哪里，缓存都不会被用到。..

3.9 –尝试使用查询钻取

什么是查询钻取呢？WebI 用户指南中是这样介绍的:.

“激活查询钻取后，通过修改基础查询（添加和删除维以及查询过滤器）并应用钻取过滤器来进行钻取。

在报表含有在数据库级别上计算的聚合度量时使用查询钻取。查询钻取是专为提供适合 Oracle 9i OLAP 等数据库的钻取模式而设计的，这类数据库包含的聚合函数在 Web Intelligence 中不受支持，或无法在钻取会话期间在报表中准确计算。

查询钻取对于减少在钻取会话期间以本地方式存储的数据量也很有用。因为在向上钻取时查询钻取可以缩小分析范围，所以它能够清除不需要的数据。.”.

通过减少webi文档数据和推送一些计算到数据库端可以改善性能。查询钻取选项的选择与否可能会也可以不会改变文档的性能，但是这是个非常简单的操作，您完全可以尝试着勾选这个选项看看性能有没有改善，下面是该选项的截图：

3.10 –必选提示和可选提示

我们的工程师曾经处理过这样一个问题，客户注意到用必选提示的报表和可选提示的报表属性速度相差了大概30秒，尽管后者的数据量要更小一些。再查看trace的时候我们发现用可选提示的文档执行时后台运行了两次 SQLGeneration ，所以用到了相对多的时间。

这是个发生在XI3.1SP7的问题，数据源是UNV universe，我们可以用efashion再现这个问题，并把取得的日志文件和BIAR 文件都提供给了开发。开发产看了code，用可选提示的时候，可选提示可能有值也可能没有值，所以.SQLgeneration在提示对话窗出现后有可能改变，所以运行两边也是正常的。举个例子，，如果可选提示没有值，那么WHERE语句会忽略这个对象。相反，如果用的是必选提示，SQL 结构是不需要改变的。

简而言之，可选提示和必选提示会有不同的表现。但是这并不意味着您不能使用可选提示，而是提醒您注意这也是影响性能的一个元素需要在设计过程中引起注意。

第4章–语义层最佳方案

.
下面会提到很多关于语义层的改进方案，从而帮助您设计运行更快的查询达到提高webi文档性能的目的。

4.1 –只在需要时结合维度

结合维度就是把不同数据源中的数据同步的过程。比如说您的文档中有两个数据提供源，每一个里面都有“Product
Name” 这个维度，你可以做一个结合维度拥有来自两个数据源中这个维度的完整值列表。.

Web Intelligence在BI 4.x版本中默认自动结合维度，所以您可以评估这些结合维度是否可以为您改善报表的性能。如果您不希望自动结合，就可以在文档属性中手动勾处自动合并维。

目前有两个选项可以控制合并维度：

自动合并维–自动合并同名维或来自相同universe的维
扩展合并维值–自动包含结合维值即使结合维并没有用在表里
.会

过度使用合并维会影响报表的性能，所以在使用过程中尽量拆开没有必要的合并维度。当然在需要的时候您可以随时合并需要的维度。

4.2 – 根据业务需求创建Universe和查询

创建一张成功的webi文档关键在于精准的把握业务需求，很好的计划实施。

就像我们前面提到的避免超大文档一样，在设计的过程中也应该避免超大减小universe和查询。事实上超大universe和查询对报表性能的影响更大。所以我们不仅要专注于确定业务需求，还要尽量减小查询的大小缩短报表的实时运行时间..

我曾经看到过有客户的报表查询中有300多个对象，整个报表执行完需要45分钟，返回数据超过500000行。然而这些对象大概只要四分之一会用在报表上。貌似客户是想用一张报表来涵盖多有的业务流程，这显然是没有业务针对性的。

.4.3 – 优化Array Fetch Size

Array Fetch Size (AFS)是每次运行Web Intelligence文档时取得的最大行数。如果一条查询返回100,000行数据而 Array
Fetch Size设为100,那么它会执行1000次每次抓取100行数据从而返回所有行数。
在 Web Intelligence的新版本中,AFS时根据您查询中的对象自动生成的，通常都是系统认识的最优数据，但是对于一些个别情况，手动设定这个值时可以对提升性能又一点帮助的。
.

我们做了下面的测试：

从上面的结果中我们可以看到不同的AFS同一查询执行的时间时不同的。系统认为的最优化AFS值大概需要30秒来返回所有数据，如果把找个值改为1000的话就可以为我们节省12秒，显然这是个很大的进步。但是必须注意大的数据传输必然会带来更多的网络和内存消耗。
.

该参数值一般默认用于新建的连接和universe。您可以通过universe parameter “DISABLE_ARRAY_FETCH_SIZE_OPTIMIZATION”来无效化默认值。更多信息，建议您参照下列文档:

文档 – 信息设计工具用户指南

文档 – 设计工具用户指南

4.4 – 启用查询剥离

查询剥离

该功能最初只能适用于基于BEx 查询的BICS连接,在BI4.1SP3以后也同样适用于关系型数据库的连接了。.当您用关系型数据库时，可以用下列方法来启用查询剥离：.

1. 在UNX文件中的业务层中选择“允许查询剥离” 选项

2.  在Webi文档中的文档属性中启用.

3. 在查询属性中启用

在使用过程中您最好确保上述三处都被正确设置，否则可能得不到想要的结果。.

有一个非常简单的方法来确认它的工作原理。在启用该功能的基础上刷新查询然后回到查询面板上通过产看生成的SQL您就会发现查询只用到了报表上用到的对象。像下面的例子，我们在报表上只用到了6个对象中的三个，所以查询只会选择这些对象：

该功能对于基于BICS的文档是默认自动启用的。

4.5 – 参考优化SAP BW (BICS) 报表的最佳方案

下列的文档中含有很多相关信息，建议您在优化方面参照该文档内容：.

文档 – How to Performance Optimize SAP BusinessObjects Reports Based Upon SAP BW using BICS Connectivity

4.6 –使用索引感知来提高性能

在信息设计工具指南12.7章节中关于索引感知有如下介绍：

“在关系业务层中，索引感知能够利用键列上的索引改进查询性能。

业务层中的对象均基于对查询数据有意义的数据库列。例如，某 Customer（客户）对象检索客户表的客户名称列中的值。在许多数据库中，该客户表具有唯一识别每个客户的主键（例如一个整数）。对于创建报表，该键值的意义不大，但它对于数据库性能却很重要。

当用户设置索引感知时，定义了数据库中的哪些列是针对业务层中维和特性的主键和外键。定义索引感知的好处包括：

与非键列相比，根据键列进行联接和过滤速度更快。

查询中所需联接较少，因此请求的表较少。例如，在一个星模式的数据库中，如果在一个维表中生成涉及到对一个值过滤的查询，则该查询可以通过使用维表外键直接对事实表应用该过滤器。

过滤器和值列表的唯一性均被考虑在内。例如，如果两个客户同名，则应用程序只检索一个客户，除非它意识到每个客户有各自的主键。”

使用索引感知可以加快数据库方面的查询和链接速度。具体请参照下列文档：

文档 – 信息设计工具用户指南 – 第十二章

4.7 – 使用聚合感知

在信息设计工具指南12.9章节中关于聚合感知有如下介绍：.

“聚合感知是关系 Universe 利用包含预聚合数据（聚合表）的数据库表的能力。设置聚合感知后，可处理更少的事实并聚合更少的行，从而加快查询速度。

如果查询中包含聚合感知对象，运行时查询生成器从匹配查询明细级别的、聚合级别最高的表检索数据。

例如，数据基础中有一个带交易级别明细的事实表和一个按日汇总销售额的聚合表。如果查询需要销售明细，则使用交易表。如果查询需要每日销售额，则使用聚合表。用户可看到使用了哪个表。

在 Universe 中设置聚合感知需要执行若干步骤。请参见相关主题，了解更多信息。“

利用数据库提前聚合能够提高webi文档的运行速度。因为Webi Processingserver不再需要计算，聚合数据库返回的数据从而节省了计算时间。

4.8 – 利用 JOIN_BY_SQL避免多个查询

参数 JOIN_BY_SQL 可以制定如何处理多个SQL 语句。在很多情况下 SQL语句是不会自动合并的，那么通过合并SQL 语句必然会带来一定的性能提高。该参数可以在业务层和数据基础中的查询脚本参数中设置，下面是相关的设定画面：.

把参数值改成“Yes”, 您就可以启用SQL生成流程合并SQL语句。建议您测试该选项从而达到更好的执行速度。..

4.9 – 语义层的安全管理

毋庸置疑，数据的安全问题是非常重要的。该章节目的在于提醒您检查安全设置确保其精确有效。有的时候复杂的安全模式也同样会影响到产品的性能。.

我们曾经遇到过这样一个例子，客户用管理者和另一个用户分别打来同一张报表速度上的差异又10~40%。原因就在于这个用户归属于70多个用户组，很多的时间就用在了权限的统合和查找上。.

我们同样发现产品code上确实有些不足需要在未来的版本中加以修复，希望能够通过进一步调整能够使没有注意到权限影响的用户能够得到更好的用户体验。.综上所属，需要您在今后中注意到的几点如下：.

1. 审查您的业务需求，在universe层减少不必要的安全配置文件
2. 如果不想让任何用户看到某对象，考虑用 对象的“隐藏“状态来 达到该目的
3. 考虑用业务层中的Access Levels 来控制哪些用户可以用哪些对象
4. 减少用户所归属的用户组角色
5. 用管理者用户测试结果和限制用户的测试结果进行比较来评估权限对性能的影响.

第5章 – 公式&计算引擎相关

.5.1 –  小心在嵌套节中使用条件

嵌套节或者是子节往往是互相关联的，比如说您在国家对象上做了节设置然后在节里面又设置了地区节，这就是个嵌套节的结构了。这种结构会增加报表的生成及执行时间，特别是当您设置了“Hide section when…”. 的逻辑判断时。当然，这并不是说不可以使用嵌套节的结构，而是提醒您在大量使用该结构的时候注意它对报表性能的影响。

下面是一个4层嵌套节结构的报表：

下面是过度使用对性能有影响的的格式设定：

当在嵌套节中使用条件，计算引擎需要去分辨哪些节需要显示，节越多，需要的时间就越多。再次强调，这种结构在报表中很有用，但是当一个节中含有成百上千的对象时，它就会对性能产生影响了。.

5.2 – 尽可能用 IN代替 ForEach和ForAll

根据跟开发人员交流中得到的信息，从代码角度来看，处理IN上下文的时间要优于处理ForEach或ForAll 。

下面的文档包含了webi 文档上函数，公式，计算和上下文使用的相关内容：.

文档 – Using functions, formulas,and calculations in Web Intelligence

文档章节
4.3.1.1中包含了如何使用“IN”的例子. 简单的说， IN准确指定了上下文中的维度。.

文档章节
4.3.1.2 和4.3.1.3中包含了如何使用ForEach和 ForAll 。简而言之,这两个函数可以允许您更改默认上下文。

在很多的情况下，IN可以达到使用ForEach和 ForAll的类似效果。所以您可以试着改用IN来改善性能问题。.

5.3 – 尽可能用 IF…THEN…ELSE 代替 .

在多数情况下，IF/THEN/ELSE是可以取代 Where的.开发人员提到从计算引擎角度来看 IF/THEN/ELSE的效果更好。如果您怀疑 Where导致出现了性能问题，可以试着把它改成IF语句。

更多详细信息，请参照下列文档：..

文档 – Using functions, formulas,and calculations in Web Intelligence

文章章节6.2.4.14包含了 Where的用法。.

文章章节6.1.10.11 包含了IF…Then…Else 的用法。

5.4 – 重复利用变量

利用变量来构建新的变量是一种很有效的使用方法. 例如：.

v_H1_Sales = Sum([Sales Revenue]) Where ([Quarter] InList(“Q1″;”Q2”))

v_H2_Sales = Sum([Sales Revenue]) Where ([Quarter] InList(“Q3″;”Q4”))

我们可以用上面两个变量构建新的变量Years sales (H1+H2 )，通过这种方法可以节省再次计算的时间。

.v_Year_Sales = v_H1_Sales +v_H2_Sales

..

第6章 – 优化系统

优化报表性能很重要的一点是优化整体系统使其正确有效的分配资源，满足系统长期运行的需要。.下面的文章介绍了很多相关方面的建议，供您参考：.

BLOG – Revisit the Sizing for your deployment of BI 4.x Web Intelligence Processing Servers!

6.1 – 用这些资源来优系统环境

每次新的系统安装，我们都需要又不同的内容，节点，权限，数据，服务器分割等设置，下面的这些文档会对您的工作又很大帮助：.

文档–Sizing and Deploying SAP BI 4 and SAP Lumira

文档–SAP BusinessObjects BI4 Sizing Guide

XLS- SAP BI 4x Resource UsageEstimator

6.2 – 不要在BI4.X的系统上用XI3.1的优化方案.

很多系统管理员经常范的错误就是在BI4.X环境中依然使用XI3.1的系统设置。BI4.X并不是简单的升级，它在整体构架上做了很多调整，其中一个重要的改变就是引入了64bit处理机制，从而克服了XI3.1上的内存限制。.

XI 3.1 用的全部是 32-bit处理进程 。在Windows 系统上，这就一位上每个进程最多可以用约2G的内存，显然这很容易造成服务器达到处理上限。在 Linux系统上这个数据可以提升到4G，但还是很容易在运行大报表时达到临界值。基于这个原因，我们建议在单个节点上创建多个Web
Intelligence Processing Servers (WIPS)，然后通过负载均衡防止达到内存上限。.

BI 4.x, the WIPS 现在使用64-bit处理进程.这就意味着2GB限制已经不再是个问题。您可以不再需要使用12太的WIPS，而只需要2台就可以调用系统上的所有资源。尽管用一台也可以，我们仍然建议您有另一台做备用。.

6.3 –确保 Adaptive Processing Server 正确分割配置

BI4.0刚发布后，出现了很多由于AdaptiveProcessing Server (APS) 资源不足导致的性能问题。在BI4.X中APS上载有从平台搜索到universe连接等21+项服务。如果不对APS进行分割设置的话，您肯定会遇到资源不足和性能问题。.

目前位置，我们发现以下三大服务会影响Web Intelligence文档的运行。它们分别是：

• DSL 桥 服务 用于运行BICS
  (SAP BW Direct access)和
• 可视化 服务 用于在webi文档中创建报表和视图
• 数据联合服务用于联合多个Universes和数据基础

平台查询服务也同样会影响webi的性能，因为该服务需要用到Processing Servers来索引化webi报表的主数据.

在BI 4.0发布不久后, SAP发布了指导如何分割APS的指南。详细内容请参照下列文档：.

文档–Best Practices for SAPBO BI 4.0 Adaptive Processing Servers

另外，在中央管理控制台(CMC)的初始界面同样添加了系统配置向导来指导您进行APS分割。

6.4 – 确保系统所在网络的稳定性

网络传输同样是影响Webi文档性能的重要因素。您需要确保WebIntelligence Processing Server / APS (DSL 桥服务)和报表数据库之间连接的网络顺畅，稳定。尽量把Processing Servers和数据库放在同一个网段里面，如果不能，也要确保它们之间沟通的网络稳定，高速。

如果您猜测遇到的性能问题是网络原因造成的，那么可以通过 BI Platform,Network 或者数据库的 traces来确认问题在哪儿。.

6.5 – 确保缓存和临时文件的快速本地存储

.

有些系统管理员把WebIntelligence Processing Servers的缓存和临时文件路径改到网盘上,但实际上这是没有什么必要的，有时候还会出现问题。缓存和临时文件并不是那么的重要，当. WIPS找不到它们时自然会重新生成。如果运用网盘的话，又时候会导致文件系统溢出或是网络传输性能问题。本地硬盘相对更便宜而且更加快捷。

6.6 – 确保足够的 CPU速度

系统处理器的速度无疑是影响BI系统处理速度的有一个重要因素。当然，现今社会大部分的机器上都配有很快的处理器，但是如果用的是很旧的UNIX系统，就需要引起您的注意了。

6.7 – 用BI Platform Support Tool 进行系统检测

BI Platform Support Tool (BIPST)是一个可以搜集您BI4.X系统全盘配置数据的工具。如果您还没有用，建议您通过下列链接来下载使用：.

WIKI – BI Platform Support Tool

对于系统检测，该工具可以提供全体服务器概况和参数设置情况。它会给出一份简单明了的报表显示您当前系统的部署情况,以便您做出相应调整来改善系统性能。

第7章 – XI 3.1 & BI 4.x的结构差异

本章节概括了XI 3.1 & BI 4.x的主要结构变化，通过了解这些不同相信对您的升级和安装会有所帮助.关于4.x的结构，您可以参照下列文档：

文档 –BI Platform 4.1 Architecture Diagram

7.1 –  32-bit vs 64-bit – 是什么意思？

XI 3.1 和 BI 4.x比较最大的不同是BI4.X有一些应用程序开始改为64-bit。64-bit处理方式可以调用比32-bit程序多的内存。由于32-bit程序的限制，在XI3.1中WIReportServer.exe (Web Intelligence Processing Server)很容易就达到2GB的上限，整个系统变的不稳定。.

64-bit的Webi Processing Server 意味着需要使用 64-bit的数据库客户端和驱动,要求Operating System 和硬件也是64-bits的.

这个改变跟BI4.X系统的优化是息息相关的。在以前的版本中我们建议在单独节点上使用多个webi 服务器来调用多余2GB的内存，在BI4.X上单独的webi procesingserer就可以掉用所有的可用资源。.

7.2 –  BI4.X搭载更多的服务

BI4.x 表面看起来和以前类似，但是有个重要的后台变化是搭载服务到处理流程而不是单纯的服务器。某个流程就可能用到其他服务器上的服务来完成任务。例如， WIPS需要用APS上的 DSL 桥服务来完成基于 UNX Universe 和BICS 连接语义层的处理工作。这意味着我们在优化系统环境时需要考虑更多的可变因素。

其中一些注意点是需要主要的：

• 流程可能需要跨节点的服务，复杂度变高
• 需要考虑流程的复杂性，加大优化难度
• 网络状况更加重要

一般情况下，这些服务都是加载在Adaptive Servers (Job/ Processing) 上的，所以主要变化都是围绕这些服务器的。

7.3 –处理流程

下面是BI4.X中一些事务处理中用到的服务器和服务：

• Web Intelligence Processing Server -> 处理和创建文档
• 可视化服务生成图表
• DLS桥服务新语义层和BICS 连接
• 数据联合服务多源Universe
• Connection Server (64-bits) ->三层模式连接
• Connection Server (32-bits) ->两层模式连接
• 安全标记服务
• WebI 监控服务监控客户端
• Web Application Server -> 生成页面
• Central Management 服务-> 认证，服务器通讯和权限等
• File Repository服务文件恢复/实例存储
• 发布服务(APS) -> Web Intelligence发布流程
• Adaptive Job Server -> 发布和计划.

  我有可能漏掉一两个，不过对比下面XI3.1您会发现差异所在：.

• Web Intelligence Processing Server ->处理和创建文档
• Connection Server (32-bits) ->三层模式连接
• Web Application Server ->生成页面
• Central Management Service ->认证，服务器通讯和权限等
• File Repository Service ->文件恢复/实例存储
• Adaptive Job Server ->发布和计划

下面列出了当前现有的 Web Intelligence处理流程，您可以通过下列的网页得到更多详细信息：.
文档 – SAP BusinessObjects Business Intelligence Platform 4.x

• Web Intelligence 文档上设置计划     processflow
• 执行Web Intelligence 文档计划process flow
• 查看Web Intelligence文档      process flow
• 导出文档processflow
• 刷新基于多源universe的文档    processflow
• 刷新基于OLAPdata source的universe的文档process flow
• 在单层模式下刷新Web Intelligence Desktop报表process flow
• 在2层模式下刷新Web Intelligence Desktop报表process flow
• 在3层模式下刷新Web Intelligence Desktop报表process flow
• 刷新基于连接的报表process flow
• 刷新基于SAP Netweaver BW UNX的报表processflow
• 刷新基于多源的关系型UNX的报表   processflow
• 刷新基于OLAP的UNV universe报表    processflow
• 刷新基于OLAP的UNX universe报表   process flow