当使用BICS连接BW做成Web  Intelligence报表时，在一些情况下会出现报表刷新慢等性能不好的问题。针对这些问题，这篇文章会提供给你一些关于调查的切入点和建议

步骤1：

首先我们得评估一下在BI启动板中刷新报表所用的时间。 这个时间的评估是需要多次刷新来确定的。根据这个评估我们需要知道，究竟是每次刷新都很慢呢，还是只是偶尔的几次是慢的。如果只是偶尔地出现刷新慢的情况，你就需要考虑一下DSL桥服务和WEBI Processing server的性能情况。 如果是每次都慢的话，你可以进入下一步的调查了。在这个阶段，在胖客户端上的测试也是必要的，因为在使用胖客户端的时候是不需要调用BO服务器的DSL桥服务和WEBI Processing Server.

下面所讲的步骤，用到了这样一个例子：一个使用BICS的WEBI报表用了5分多刷新才结束。

步骤2：

针对WEBI中引用的BEX查询，利用BW的Query Designer进行调整， 使其默认的行和列中包含跟WEBI一样的特性和关键值。然后通过SAP GUI登录BW系统，执行RSRT。在RSRT中执行这个报表。如果再RSRT中执行时间也很长的话，则需要寻求BW工程师的帮助看看是否在建模和系统配置上是否有问题。如果RSRT上性能很好的话，则问题可能是由BICS这个中间层导致的，你可以进入下一个步骤的调查。

步骤3：

抓取和分析RSTT日志。关于如果抓取RSTT日志，请参照SAP Note 1925924

在得到完整的RSTT日志后，不需要去执行这个日志。你只需要按照下面截图的样子做一下和就能得到究竟在BICS中层所花费的时间。这里的时间单位是微秒。

下面是我们这个例子的截图。

我们会发现所有的BICS function call一共用了大约2.2分钟。但是大部分的时间都花在了【BICS_PROV_GET_RESULT_SET】这个function上。

通常情况下， 【BICS_PROV_GET_RESULT_SET】和【BICS_PROV_GET_MEMBERS】会花费很长时间，因为他们回去数据库中读取数据。

接下来将针对【BICS_PROV_GET_RESULT_SET】这个function进行debug。关于Debug的一些方法可以参考SAP Note 1944598。使用debug mode执行RSTT 日志。将程序断点设置在这个function的开始和结尾处，以便我们得到有用的数据。在debug模式下，请关注ABAP程序中E_T_ROWS[]这个变量，在这个例子中BW返回了2864768条数据。这也说明了为什么在BICS层花费了2分多钟。E_T_ROWS[]的这个数字，并不是我们在WEBI报表中能看到的数据的量，这个数字反映了这个function call取回数据的量，而最终WEBI中显示数据是基于这些数据计算而来的。

步骤4

抓取E2E日志分析在DSL桥服务所用的时间。

在E2E日志中看到的时间总和等于BICS function call时间+数据数据传输时间+DSL桥服务的处理时间。

首先在trace中得找到DSL桥服务执行时生成的日志部分。具体E2E日志的查看技巧请参考文章【BI 4.x里如何生成E2E的trace日志进行查错分析（针对不含Solution Manager的系统）】

当我们找到相应的DSL桥服务的日志后，就会发现在类似JCO call日志记录的后面有一条时间记录。

在这个例子中可以看到 DSL桥服务一共用了大约4分钟从BW取回了358092数据。

最后通过以上的调查可以确定在各个部分花费的时间如下：

Area	Time spend
WebI Server	1 minutes
BICS Function Call	2 minutes
DSL Others	2 minutes

在这个例子中，从数据库返回了 358092条数据，所以在上面列表里所用到的时间是在正常的范围内。接下来我们还可以深入的了解为什么在BW系统中花费了2分多时间。我们通过使用ST12取到BW的性能日志来帮助我们BW数据中的一些情况。

首先,在RSTT中执行一遍日志， 并且使用SM50找到这个动作对应的PID号

然后执行T-code ST12，选中下面截图里的Performance trace的选项。

选中那个PID之后，点击激活。

下面是在日志中生成后的总结，他会提供给我们一些BW数据库里的性能信息。

这篇简要地介绍了一些关于连接BW Bex时报表问题的调查方法。虽然这里我介绍的调查方法可能不会解决具体的性能问题，但是会帮助大家细化问题，然后针对报表运行过程中每一个部分的性能情况进行评估，进而有针对性的实施相应的优化。

以上。