Cognos report studio 清单表优化实录

背景：财务有张清单表的逻辑非常简单，在数据库查询工具中查非常快，但是一发布到Cognos，一个月的数据就要取30分钟以上。值得注意的是，这是一张使用很久一直在运维的清单表，由于工作人员缺乏稳定性，几经转手之后没有人知道为什么报表突然慢了下来，要找到问题原因并解决性能问题

记录如下：

假设1：因为cognos内存不够，数据量大导致超负荷，进而影响性能。

 解决方案1：尝试了新建视图，把报表上的表关联全部都转移给数据库，所有的数据查询都在视图里处理。此方法不修改报表report里的任何设计，只修改Framework Manager里的模型。

测试结果1：结果不很理想，改成数据改成从视图中获取后，报表查询性能没有任何提升。

结论1：改成视图的方法不可用。

需要另外想办法。或许是假设1不成立。需要梳理新的思路：

假设2：报表Report Studio里有加很多过滤器，考虑过滤器影响性能

解决方案2：删除所有的过滤器

测试结果2：测试结果不理想，性能没有任何提升。

结论2：影响性能的点不在过滤器

结合理论可以直接推翻假设2，但是还是试了一下。

还是需要找问题，在调优过程中有个问题一直得不到很好的解释：为什么在数据库管理工具中5秒的查询，报表上就要30分钟，报表究竟做了什么处理？

假设3：报表的查询中存在影响性能的设置，

解决方案3：尝试调试查询的执行优化改成第一行、修改自动分组和汇总为否、使用SQL WITH 子句、累计处理改成本地、使用本地高速缓存（这个是当时的第一猜想，但是后面证实问题不在这里）改为是、按照与1.x相同的运行方式运行……

测试结果3：性能没有任何提升。

结论3：影响性能的点不在查询的属性。

假设4：查询字段做了类max()的聚合函数等逻辑运算。

解决方案4：考虑到是清单报表，没有加分组和聚合函数的必要，所以一开始排除了这种情况。但是目前所有结论都指向字段。是特定的字段影响了整体性能。这里使用二分法测试问题点。

测试结果4：经过n轮二分法，问题最终定位在统计时间这个字段上。当控制查询区间在一月份时，不加统计时间这个字段，查询5秒即可完成。显然问题在统计时间。但是统计时间没有加聚合函数，究竟是怎么影响的性能呢？经过检查统计时间的属性，发现统计时间的预排序属性设置为“降序”，尝试把这里设置为：“不排序”……不到5秒。（完美

/*

为了解决这个困惑，尝试新建了一个空白表，重新拖所有表字段。从0-1的过程可控性高，这里希望可以通过正向的操作对比现在的报表中存在的影响性能的设置或者属性。

很幸运。第一次尝试就发现，直接拖进来的字段构成的新清单没有性能问题。

那么现在至少方向是对的，而且逐渐接近真相，就在字段里，极可能是哪个字段的设置影响了性能。

通过多次二分法定位到问题字段是统计时间，设置了排序。

这段草稿里的内容，以注释的形式保留在本记录中。

*/

结论4：字段预排序会扫描全表，非常影响性能。

关于cognos底层实现预排序的机制，暂时没有找到权威的解释，但是通过此次优化，有如下猜想：当字段进行预排序时，会先把结果集全部查询出来放到cognos工具临时表空间里，随后并做全表扫描完成排序动作。此报表6月截至目前有至少12万条记录，显然这个数据量对于报表工具而言是超负荷的。

至此报表优化的思路总结如下：

1.检查并优化取数逻辑；

2.清单表查询的自动分组和汇总属性选择否；

3.排查是否在报表层加max和排序；--排序时，底层会将数据全部载入后一一排序，最后才展示出来，非常耗时；

以上。

2021.06.22 

中国上海 Esther 苏