我曾有机会在一位使用sapbw/4HANA的客户身上尝试一些测试，以提高他的报告的性能。该客户拥有SAP BW/4HANA（BW 7.5，HDB 2.0）的现代化基础设施，以及使用AFO、webi和其他第三方工具的密集报告。
报告模型是使用混合（或混合）场景按照LSA++方法构建的。不同的模型是异构的，有些模型主要基于HANA视图（对于采集层使用BW"only"，顶部有一个复合提供者+查询），有些模型使用复杂的复合提供者
使用一个生产环境的副本，物联网是什么意思，我们想尝试不同的行动，应该需要低努力，以改善绩效报告。这些操作将仅从技术角度进行设计（未分析功能主题）。
我们的系统有大量记录（在某些情况下为数十亿条记录），每天加载4次。
我们比较了应用操作前后的性能。
有一些公认的最佳实践不需要详细解释在这个邮递员这篇文章的目的是解释应用这些技术后获得的结果，以便对它们进行评估。
3.1 ADSO分区（物理和逻辑分区）
我们的BW4有几个ADSO比其他的大得多，所以逻辑开始关注这些ADSO。我不得不承认，结果与我的预期大相径庭，这让我大吃一惊：我们只在某些情况下取得了相应的改进。
关于分区……物理分区还是逻辑分区？
我们使用物理和逻辑分区（使用语义组）进行了测试，在性能上有以下改进：
我的结论是：
根据所做的选择和深入研究，在同一个查询中我们（显然）有不同的结果。只有当ADSO有超过20亿条记录时，分区才起作用。ADSO不足20亿，物理分区可能有害。带有语义组的逻辑分区是中立的（但出于其他原因，而不仅仅是性能原因，实现它可能会很有趣）。
（*）显然，如果我们按会计期间进行分区，并且我们的查询要求会计年度，我们必须更改此项（有一些方法可以做到）。
！：重要提示：测试的模型有一些比其他模型大得多的ADSO，但是这些模型也很复杂，这就是说，这些模型不仅有一个大的ADSO，而且还涉及几个连接和其他ADSO。正因为如此，分区带来的收益在某些情况下是适度的。
出于同样的原因，从这些ADSO中删除历史数据并没有相应的改进：我们删除了这些ADSO中20%的历史数据，我们只获得了2-5%的性能增益。
另一种情况是一个相对简单的模型，只有一个相关的ADSO拥有10亿条记录。我们检测到这个ADSO是按会计年度划分的，但是查询使用的是会计期间。改变分区标准后，根据查询中选择的值，企业管理软件下载，增益为8%-35%。
最后，评论我们对这些大ADSO的"改造过程"有一些问题。我们最终决定先做一个拷贝，把数据放到ADSO中，做分区，然后从拷贝中重新加载。
3.2在HANA视图中添加输入参数
SAP建议必须使用输入参数尽早过滤数据。这意味着，例如，如果您有一个读取ADSO的投影，您应该在该投影中有一个输入参数（或/和一个过滤器，如果可能）。
一些模型的BW查询中的过滤器（变量）位于顶部。通过添加输入参数而不是查询过滤器来更改模型，根据模型和请求的数据，我们大约有5-20%的改进。
3.3键列和索引列的连接
有时，我们认为主键和索引在HANA环境中不相关。但是，SAP建议所有相关的连接都应该使用键列或索引列来完成。
我们检查了所有的主连接，并在需要的地方添加了索引。我不得不承认结果不好。在大多数情况下，增益并不相关，甚至有点糟糕。
只有在一种情况下，一些字段用于视图中的多个连接，我们获得了大约17%的性能。这个连接是在一个拥有7亿条记录的ADSO中的客户级连接。
认为这个操作在大多数情况下不会产生积极的结果，我建议检查这个，很容易测试。
3.4"优化连接列"标志
我不得不承认，在阅读了一些像这样有用的帖子之后，我真的不太明白这个旗子是怎么起作用的。但是，我们发现在一个HANA视图中，性能很差，问题只集中在一个连接中，而这个连接显然没有其他连接复杂。激活此标志后，我们的性能提高了约50%。
3.5在顶部用HANA unions替换复合unions
根据其他项目的经验，我可以肯定，如果您有带unions的复合提供商，用HANA unions替换此BW unions是个好主意。是的，我知道，你觉得这没道理。但这是我的经验，而且收益是相关的。
在这个客户中，只有一个型号处于这种情况，而更改是不相关的，我认为这是因为根据查询中的选择，并不是所有的ADSO都同时被读取。然而，我推荐这个动作。
3.6导航属性
在我测试的同时，一个项目中的一些同事发现了一件有趣的事情…其中一个模型的顶部有一个复合提供者，其中一些属性有很多导航属性：
这个想法是最重要的，将导航属性"重新映射"到它们自己的infoobject上。这是：
第1步：使用投影中的"旧"CP创建新的HANA视图：
第2步：使用新的HANA-视图创建新的CP
第3步：根据查询中使用的导航属性数，将导航属性重新映射到自己的infoobject
，改进约为25%-45%。
