我正在使用 SSIS 包将 SAP 数据库表中的数据提取到 SQL Server 表中。我正在使用 OLEDB 源/目标连接来实现此目的。
现在的问题是 SAP 中的一个表有 500 万条记录，需要大约 2 小时才能将这些数据提取到我的 SQL Server 表中。我使用了 trunc-dump 方法（截断 SQL Server 中的表并将数据从 SAP 表转储到其中），并尝试使用多个哈希键引入更新/新记录。
哈希键的问题在于它仍然需要扫描整个表来查找更改/新记录，因此所需的时间几乎与 trunc-dump 方法相同。
我正在寻找一种新的方法或改变现有的方法来减少完成此提取所需的时间。
正如您提到的，您正在使用 OLEDB 源连接来访问 SAP，如果这意味着您正在直接访问 SAP 的底层数据库，那么您应该出于以下三个原因暂停这样做，直到获得明确的 IT 批准：
- 您跳过了 SAP 的应用程序层安全性。可能存在企业安全合规问题；
- 您公司的 SAP 许可证可能不允许您这样做。如果你的公司只有SAP间接访问许可，那么你可能只能停留在应用层；
- 直接访问底层数据库并不能获得SAP的官方支持。
您有多种选项可以通过 SAP 应用程序层使用 SSIS 获取数据：
- 使用商业 SSIS 自定义组件来完成此工作（免责声明：AecorSoft 是提供此类连接组件的领先供应商之一）；
- 查看 SAP 自己的 OData Gateway 接口来使用数据。
- 请求您的 SAP ABAP 团队编写自定义 ABAP 程序，将 SAP 数据转储到 CSV 文件中，然后使用 SSIS 获取它们。
现在让我们看看性能方面：
SAP ETL 性能取决于许多因素，但一般来说，即使对于具有 100 多个列的 SAP 事务表，每几个小时提取 500 万行也被认为非常慢。例如，我们见过以每 1-2 分钟 1M 行的一致性能提取标准 SAP General Ledger 标题表 BKPF（几乎 100 列）的案例。当然，这样的性能是通过商业组件和 SSIS 实现的，但即使对于上面的#3 选项（通过中间 CSV 文件），您也应该期望每 10 分钟至少 1M。在底层，通过 SAP 应用程序层，所有 3 个选项都将利用 SAP Open SQL（与底层数据库提供的“本机 SQL”相反）来访问 SAP 表，因此，如果您遇到应用程序层性能问题，您可以分析 Open SQL 端。
正如您还提到的更新/新记录场景，这是一个典型的增量提取问题。通常，在 SAP 事务表中，有“创建日期”和“更改日期”字段可以帮助您捕获增量。在这种情况下，为了避免全表扫描，请通过 SAP 应用程序层在这些“增量字段”上应用索引。例如，如果您需要提取销售凭证标题VBAK表，您可以按ERDAT（创建日期）和AEDAT（更改日期）进行过滤。 Delta 是 SAP 中的一个复杂主题。没有简单的语句来描述增量解决方案，因为 SAP 数据模型非常复杂，并且各个功能模块之间差异很大。增量分析始终是具体情况具体分析的工作。有些人可能还简单地推荐使用“delta extractors”，但不要将其视为灵丹妙药，因为提取器有其自身的问题。简而言之，如果您研究基于表的提取，请重点关注这一点，并尝试与您的 SAP 功能团队合作来确定合适的增量字段。尝试避免进行全表扫描和散列。对先前提取的一些可选重叠进行增量加载（例如加载今天和昨天的记录），并进行合并以吸收更改。
在极少数情况下，您可能无法找到任何增量字段，并且始终满载是不切实际的。地址主数据表 ADRC 就是一个很好的例子。在这种情况下，如果您需要在此类表上执行增量加载，则必须请求 SAP 职能团队为您计算出增量（这意味着他们将自定义逻辑注入到可以创建、更新或创建地址主数据的每个位置）已删除），或者您必须要求 SAP Basis 团队在底层数据库表上创建数据库触发器，并在应用程序层公开触发器表。这样就可以在主表和触发表上创建一个应用层视图来做delta。尽管如此，您的解决方案仍无法直接访问数据库。 DB 层触发器由 SAP Basis 团队完全管理和控制，他们也支持数据库。
希望这可以帮助！
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
