当使用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时报表问题的调查方法。虽然这里我介绍的调查方法可能不会解决具体的性能问题,但是会帮助大家细化问题,然后针对报表运行过程中每一个部分的性能情况进行评估,进而有针对性的实施相应的优化。