调度程序是否有机会估算程序包的数量（特别是具有或多或少的良好上限）？

然后，您可以考虑使用一个包含关键字段的帮助数据库表

• 运行ID（调度程序和任务已知）
• 运行中的任务ID（对于每个任务，由调度程序分配）

和用于成功过帐累计金额的数据字段。

然后调度程序可以跟踪

• 在助手表中没有条目的已启动任务及其估计的累积量
• 所有此类程序包的总估算值-启动程序包时需要增加，而在调度程序识别出助手表上的条目时应减去
• 在帮助者表中具有所有条目的任务的累计累积金额

并根据上述内容和对下一个软件包的估计，可以决定并行启动它，或者等待所有未完成的任务，然后开始以串行方式执行软件包（对于最后一个[few]软件包 ]）。

为了减少同步，应最小化DB helper表上的锁定时间（例如，通过将其插入通过PERFORM ON COMMIT调用的子例程中）。

（在通过RFC调用进行并行化的情况下，还有一种方法可以将RFC响应中的累计量发送回-执行中...在任务结束和接收结果等时-但是，响应将不会成为一部分 逻辑工作单元，并且可能在COMMIT WORK之后但在RFC响应之前带来终止的风险-原始方法更安全，因为helper DB表是LUW的一部分）

否则，据我所知，严格遵守上限的要求将始终意味着大量同步，这将大大限制并行化。

Sandra Rossi 谢谢您的投入，

只是想了解您的答复，每个FI帖子大约要等待10毫秒，所以100,000帖子的等待时间将是100万毫秒-> 1000 s，大约是16分钟，如果我的理解错了，请纠正我。 我知道这是100,000条记录的最坏情况。

这里很少担心，

1）累积/比较逻辑在增强中，我的理解是更新表，并在此处写入COMMIT并不是一个好主意，因为它关闭了当前的LUW。 发布完成后，我想立即提交。

2）要添加更多有关该问题的详细信息，我已经在问题中提到，我们需要允许过帐直到金额上限，该上限是针对不同参数（例如公司代码，工作细目分类）的组合设置的 结构元素等..因此，表最终将增长，我不确定10毫秒是否仍然有效。

3）我正在对此进行频繁的数据库表更新，不确定是否建议这样做。

是的，您说的很正确1000 s。 我给出了错误的论点； 我想说的是，对于一个持续约1秒，10毫秒的发布来说，并不重要。

1）执行FI发布，更新Z表，然后提交工作。

p>

2）即使Z表中还有其他键列，更新的持续时间与FI过帐的持续时间相比仍然不重要。

3）为什么不？ 少于FI发布更新的表数。

对于共享缓冲区，我不理解"服务器中资源不可用"异常-您能否提供更多详细信息 ？