大家好，
今天我将分享一个最有效的方法和修复长时间运行的负载。
在我们的一个应用程序中，有delta负载通常在几秒钟内完成，但从过去2天开始，它的运行时间比通常的时间长。我们通过检查BG作业开始调查，它被挂断了，我们厌倦了做满负荷也没有发生。
实际上没有错误消息。而通常运行几秒钟的负载现在需要5个多小时，仍然没有处理任何数据。source有56000条记录需要处理。然而，DTP运行了将近4.5个小时，没有处理任何记录。
因此，我们不得不取消加载并删除请求，因为它妨碍了其余的进程。
然后我们尝试运行，将数据包大小从50000减少到1000，并在销售组织、部门、客户销售和分销上设置语义分组我们还考虑通过启用设置"按请求获取所有新数据请求"来运行负载。（由于源有多个delta请求）
根据源A和目标B之间的逻辑，它将根据销售组织、部门、客户销售和分销渠道从目标DSO B中提取所有记录
现在DTP负载正在尝试处理120405条记录，记录模式="N"，您可以想象它是什么时候开始的有没有查过B DSO会带来多少记录（肯定会超过50万条？）当达到最大值时，ABAP堆内存限制将达到。因此，我们继续使用小数据包大小和语义分组运行。因此，查找成本和处理也将得到优化。
现在相同的负载在15分钟内成功完成。在对DTP设置进行以下建议的更改后。
从下面的屏幕打印中，您可以找到源程序包（DSO）的爆炸比较读取的行和传输的行列。
在DSO中创建的总增量为12万，爆炸到340万；就体积而言，云发布，这是27倍！！在单个数据包中容纳340万条记录是不现实的
分析：
在初始DTP设置下，即数据包大小=50000条记录，没有语义分组+并行处理=3，您可以想象总共会创建3个包（拆分记录50000+50000+24901），然后如果不按语义分组，则在包1中处理的具有键组合Sales org、division、customer Sales和distribution channel的同一组记录也可能在其他数据包中处理。因此，企业信息化软件，从逻辑上讲，记录的数量与每个后台作业保留的ABAP堆内存量之间的关系急剧增加，这肯定不足以完成此数据加载。
当然，这就是我们在ST22中发现ABAP内存转储不足的原因，当进程以PRIV内存模式运行时，但是，云服务器购买，如果它没有找到足够的内存来进一步处理，则会发现作业没有进行，因为它将等待任何其他作业释放内存
在加载类型=delta或full时到达另一部分：无论是delta还是full，逻辑都将以相同的方式处理加载。。因为我们不考虑记录模式="X"（更改日志），因此，尽管您使用与更改日志中相同的选择运行加载，但它不会产生任何差异（增量或完全）。
此外，全民淘客，
即使在过去6K记录爆炸到.6 M（~100倍大！！）完成此作业的总运行时间为38分钟。
解决方案：
确保语义分组始终保持在满负载和增量负载中。
首选将数据包大小保持在50000到1000之间，如果仍然发现性能问题，您可以考虑使用更小的数据包大小（例如，宁波大数据，每个包500条记录）运行。
为了提高负载性能，您可以考虑使用最多6个并行工作进程。
谢谢，
Siva
这是您的意见……
您正在处理症状，而不是攻击问题的实际原因。你应该调查一下为什么负载从几秒钟变成了几个小时……
M.
修补DTP包大小、语义键和批处理过程只能节省你这么多时间。除此之外，您还需要开始研究转换中的ABAP逻辑。
减少直接数据库读取的次数，确保对表进行排序并尽可能使用二进制搜索，删除不必要的循环，将开始和结束例程置于行级例程之上，这将使您获得更大的性能提升。
