Sql server 将数据从SAP提取到SQL Server

我正在使用SSIS包将数据从SAP数据库表提取到SQL Server表中。我使用OLEDB源/目标连接来实现这一点

现在的问题是SAP中的一个表有500万条记录，将这些数据提取到我的SQL Server表中大约需要2小时。我使用了trunc dump方法（截断sql server中的表并将数据从SAP表转储到其中），还尝试使用多个哈希键来引入更新/新记录

哈希键的问题是，它仍然必须扫描整个表以查找更改/新记录，因此所用的时间几乎与trunc dump方法相同

---

我正在寻找一种新方法或改变现有方法，以减少完成此提取所需的时间。

正如您提到的，您使用OLEDB源连接访问SAP，如果这意味着您直接访问SAP的底层数据库，您应该暂停此操作，原因有三个，直到获得明确的IT批准：

您跳过了SAP的应用程序层安全性。可能存在企业安全合规性问题

您公司的SAP许可证可能不允许您这样做。如果您的公司只有SAP间接访问许可证，那么您可能必须留在应用层

通过直接访问底层数据库，您将无法获得SAP的官方支持

通过SAP应用程序层使用SSI获取数据有多种选项：

为此作业使用商用SSIS自定义组件（免责声明：AecorSoft是提供此类连接组件的领先供应商之一）

查看SAP自己的OData网关接口以使用数据

请您的SAP ABAP团队编写自定义ABAP程序，将SAP数据转储到CSV文件中，然后使用SSI获取它们

现在让我们看看性能方面：

SAP ETL性能取决于许多因素，但一般来说，即使是具有100多列的SAP事务表，每两小时提取500万行也被认为是非常缓慢的。例如，我们看到过以每1-2分钟1百万行的一致性能提取标准SAP总账标题表BKPF（几乎100列）的案例。当然，这样的性能是通过商业组件和SSI实现的，但即使对于上面的#3选项，通过中间CSV文件，您也应该期望每10分钟至少有1M的性能。在后台，通过SAP应用层，所有3个选项都将利用SAP Open SQL（与基础数据库提供的“本机SQL”不同）访问SAP表，因此，如果您遇到应用层性能问题，您可以分析Open SQL端

正如您还提到的更新/新记录场景，这是一个典型的增量提取问题。通常，在SAP事务表中，有Create Date和Changed Date字段可以帮助您捕获增量。在这种情况下，为了避免全表扫描，请通过SAP应用程序层在这些“增量字段”上应用索引。例如，如果需要提取销售文档标题VBAK表，则可以按ERDAT（在上创建）和AEDAT（在上更改）进行筛选。在SAP中，增量是一个复杂的主题。没有简单的语句来描述delta解决方案，因为SAP数据模型非常复杂，并且在各个功能模块之间差异很大。增量分析始终是逐案进行的。有些人也可能简单地建议使用“delta提取器”，但不要将其视为银弹，因为提取器有自己的问题。简言之，如果您研究基于表的提取，请关注这一点，并尝试与您的SAP职能团队合作，以确定合适的增量字段。尽量避免进行全表扫描和散列。使用以前提取的一些可选重叠进行增量加载（例如，加载今天和昨天的记录），并进行合并以吸收更改

在少数情况下，您可能无法找到任何delta字段，并且始终满负荷运行是不现实的。一个很好的例子是地址主数据表ADRC。在这种情况下，如果您需要在这样的表上执行增量加载，您必须请求SAP功能团队为您计算增量（这意味着他们将自定义逻辑注入到可以创建、更新或删除Address master的每个位置），或者您必须请求SAP Basis团队在基础数据库表上创建DB触发器，并在应用层公开触发器表。这样，您就可以在主表和触发器表上创建一个应用程序层视图来执行增量。不过，您的解决方案无法直接访问数据库。数据库层触发器完全由您的SAP Basis团队管理和控制，该团队也支持数据库

---

希望这有帮助

您有权访问SAP表吗？是否可以将WhenUpdated datetime字段添加到其中，然后使用此字段过滤/刷新数据？如果可以，请在WhenUpdated字段上创建索引，也是。@VitalyBorisov SAP是一个专有软件，如果我们对SAP标准表进行更改，我们将失去SAP支持，我不相信我的公司已经准备好进行更改。SAP是否允许在其中构建任何逻辑？比如动力学？触发？@VitalyBorisov这是我对你的第一个建议的回答。我希望我能对表格做任何这样的更改，但我不能。我认为不可能捕获更改数据。你还有别的想法吗？