SAP咨询公司（尤其是BW咨询公司）经常会受到三角洲提取问题的困扰。我们共同关心的一些问题是：

与delta相关的问题和Ping超时错误的痛点主要归因于巨大的负载（满负载）和提取所需的相应执行时间。

解决方案很简单，即将Full转换为delta。

我在满负载提取程序上遇到了类似的死角，然后启动创建增量，但问题是，此提取器是SAP表上基于视图的提取器，可提取30M+条记录，没有时间戳或数字指针的作用域，只能通过完全上载（ODS或InfoPackage选择）来实现增量。

目标：详细说明在没有时间戳/日期/数字指针的情况下实现增量的逻辑在范围和负载是完全基于这里的看法。

目前，我们是在HANA，即我们有BSoH在我们的系统中可用，这就是为什么我继续转换这个特定的提取器到三角洲与一个非常简单的逻辑和下推到HANA取得了很大的成果。相同的算法如下：

使用HANA，与使用SQL类的原始提取器相比，我在性能上实现了下推和重大改进，人工智能网络，但并没有对内存占用造成太大影响，但这并不意味着这种逻辑不能应用于非HANA环境以实现增量。

内存管理是我们在使用C等语言时所做的编码的一部分为什么不优化提取器程序，与提取器的键一起工作，以实现减法功能和所需的输出。

明显的优点/缺点：

缺点：

进一步：

分步流程：

逻辑检查：在上图中，您可以看到DFLAG为"A"的记录是"A-B"的结果，这意味着要为增量添加最新的映像增量和更改，DFLAG为"D"表示需要从上一个映像（即"B-A"）中删除的记录，以获得提取器的总体最终增量映像。

在我的情况下，我打开了ECCHANA 30米以上的记录处理用了48秒来生成增量，互联网大数据，截断和更新到映像表用了不到3分钟的时间，这比SAPI（ABAP）上相同系统的满载提取所需的1260多秒或21多分钟要好得多。此操作及其保存数据的时间段所消耗的内存再次减少比较高效。

在SAP中，我们有各种不同的增量方法来满足不同的增量需求，但在这个场景中，所有这些都没有得到满足。本文档的目的非常简单，即即使没有可用的Delta选项，也可以在提取结构级别将任何满载转换为Delta。其目的是分享想法/逻辑，而不仅仅是实现增量的确切代码在我的情况下，只需要捕获添加和删除，此代码很好地服务于其目的它可以进一步修改以满足您的要求，但在使用此模式之前，请在资源消耗和内存处理方面进行权衡。

在如果您需要跟踪每一个更改，有什么免费的云服务器，您可能希望查看更改指针的选项，淘客返利app，或者使用基于触发器的更新机制来直接跟踪到原始表的影子表中的更改，这同样取决于顾问和架构师的考虑，因为允许应用程序表上的触发器从来都不是一个好主意好主意，然而，需要是发明之母，我相信在某个地方有人会有一个伟大的想法，以满足这一点太多了。

我的PoC范围是有限的，虚拟主机，有这么多的选择从SAP的三角洲可用，我们不会总是在三角洲提取不足，但任何输入本文件总是受欢迎的。