关于ODQ的一些理解以及ODQDATA表过大解决办法！-CSDN博客

本文链接：https://blog.csdn.net/weixin_47794727/article/details/126617936

在项目上碰到一个问题，就是ODQdata表中内存过大，然而没有抽发删除机制，导致此表越来越大！后查询找到一个办法，有一个note可以解决此问题！
懒得再写一篇我把这个办法我放在本文在最后！就是那个超链接哦！

Operational Delta Queue Cleanup 相关的系统逻辑和要求的理解

一般操作增量队列清理
Operation Delta Queue Cleanup 的主要目的是删除所有超过 24 小时（默认值）的已确认和已取消请求。默认情况下，作业安排在每天 01:23:45 系统时间。作业的技术名称还包含客户端编号，其中必须进行清理，例如 ODQ_CLEANUP_CLIENT_004。它指的是客户端 004 中的清理作业。如果需要，可以在事务 SM37 中调整开始时间和频率。如果需要，还可以调整恢复的保留时间。

您可以在 ODQMON 中的“Goto”和“Reorganize delta queues”菜单中访问它。这将打开 ABAP 程序 ODQ_CLEANUP（在事务 SE38 中）。
在这里插入图片描述

保留期
有三个不同的时期：

恢复已取消的增量进程：这是队列表中标记为已在增量进程中检索或已取消的数据的最短保留期。一旦此期限到期，所有标记为已检索或无效的数据都将通过定期安排的重组过程从增量队列中删除。此时始终可以为单个订阅者重置或重复增量过程。最短保留期以小时为单位。默认设置为 24 小时。

对于低相关性的数据：一旦这个时间段过去，周期性重组过程会删除队列中满足以下条件的所有数据：

它尚未被声明为已检索或无效
所有订阅者都以低相关性订阅了它。这段时间以天为单位。默认值为 1 周。
对于中等相关性的数据：一旦这个时间段过去，周期性重组过程将删除队列中满足以下条件的所有数据：

它尚未被声明为已检索或无效
所有订阅者都以最多中等相关性订阅了它。
这段时间以天为单位。默认值为 31 天（4 周加上一个额外的周末）。

数据相关性分类
尚未检索且对业务至关重要的数据永远不会被重组过程自动删除。

目前，系统并未对增量数据进行任何相关性区分。增量队列中的所有数据都被视为业务关键数据，因此在被标记为已检索或无效之前不会被删除。

由于预期的数据量特别大，来自增量初始化请求和标准请求的数据也被归类为低相关性。

安排重组运行
激活增量队列时，如果还没有定期调度，则会自动调度重组运行（程序 ODQ_CLEANUP）。可以通过在第一个增量请求之前手动安排它们或通过随后更改自动安排的作业来修改上面指定的周期。为此，您可以直接从程序 ODQ_CLEANUP 调用作业管理，或使用修改的选择参数执行“快速调度”。

在默认设置中，重组运行计划在每天凌晨 1 点到 2 点（系统时间）运行一次。如果需要，可以更改开始时间和期间。

如果已在同一客户端中对程序 ODQ_CLEANUP 执行了定期调度，则不存在自动调度。要将重组延迟特定时间，例如出于故障排除目的，必须将计划作业从状态已发布重置为状态已计划或已发布/暂停。如果计划的作业被删除，则在下次进行增量初始化或标准请求时重新计划。

模拟运行
还可以通过设置标志来安排“模拟运行”。
在这里插入图片描述
请确保应用 SAP Note 2286619中的更正。SAP Note 与以下版本/SP 相关：

依赖项
如果周期性重组过程删除了尚未声明为检索或无效的低或中等相关性数据，则属于它的增量进程（订阅）也将被重置。然后必须重新初始化这些。