0

这是关于 SQL Server 2008 R2 和 SSIS。

我需要使用另一台服务器上的生产表中的新数据更新一台服务器上的数十个历史表。

两台服务器没有也不会链接。

一些历史表有数百百万行，一些生产表有几千万行。

我目前为每个使用以下数据流组件的表制定了一个流程：

  1. OLEDB Source 任务拉取适当的生产数据。
  2. 查找任务以检查生产数据的键是否已存在于历史表中并使用“重定向到错误输出” -
  3. 将丢失的数据传输到 OLEDB 目标历史记录表。

对于大表来说，这个过程太慢了。一定有更好的方法。有人可以帮忙吗？

我知道服务器是否链接了基于单个集合的查询可以轻松有效地完成任务，但服务器没有链接。

4

2 回答 2

1

将您的问题细分为更小的问题。这是你解决这个问题的唯一方法。

让我们检查一下问题。

  1. 您正在插入和/或更新现有数据。在数据库级别，行被打包到页面中。它很少完全适合，并且通常在页面中留下一些可用空间。当您更新一行时，假设 Name 字段从“bob”变为“Robert Michael Stuckenschneider III”。那一排需要更多的空间来居住，虽然页面上还有一些空间，但还不够。其他行可能会被拖到下一页，只是为了给这一行一些肘部空间。这将导致大量磁盘活动。是的，鉴于您正在添加更多数据，这是不可避免的，但重要的是要了解如何您的数据将会增长，并确保您的数据库本身已为这种增长做好准备。也许，您在目标表上有一些非聚集索引。禁用/删除它们应该可以提高插入/更新性能。如果您仍然将数据库和日志设置为以 10% 或 1MB 或任何默认值增长，则存储引擎将花费所有时间来尝试增长文件，而没有时间实际写入数据。带走：确保您的系统准备好接收大量数据。与您的 DBA、LAN 和 SAN 团队合作

  2. 您的 OLTP 系统中有数千万行，归档系统中有数亿行。从 OLTP 数据开始，您需要确定历史系统中不存在的内容。鉴于您的数据量，我会计划让这个包在处理过程中出现问题，并且需要“可重新启动”。我将拥有一个数据流，其中仅包含从 OLTP 中选择的用于与目标表进行匹配的业务键。将这些键写入位于 OLTP 服务器 (ToBeTransfered) 上的表中。有第二个包，它使用这些键的子集（N 行）作为源连接回原始表。它直接连接到目标，因此不需要查找。该胖数据行仅在网络上流动一次。然后让执行 SQL 任务进入并删除您刚刚发送到存档服务器的批处理。这种批处理方法可以让您在多个服务器上运行第二个包。SSIS 团队在他们的论文中更好地描述了它：我们在 30 分钟内加载了 1TB

  3. 确保查找是表单的查询SELECT key1, key2 FROM MyTable更好的是，您可以为查找提供过滤器吗？WHERE ProcessingYear = 2013因为如果 OLTP 仅包含 2013 年的数据，则无需在 2012 年浪费缓存。

  4. 您可能需要修改Connection Manager 上的PacketSize并让网络人员设置巨型帧。

  5. 查看您的查询。你有好的计划吗？您的表格是否被过度索引？请记住，每个索引都会导致执行的写入次数增加。如果您可以在处理完成后转储它们并重新创建，您会认为您的 SAN 管理员为您购买了一些 FusionIO 驱动器。我知道当我从只有 10 列的十亿行表中删除 14 个 NC 索引时我做到了。

如果您仍然遇到性能问题，请建立一个理论基线（在现实世界中永远不会发生的理想条件下，我可以在 N 个单位时间内将 1GB 从 A 推送到 B）并从那里开始工作到您的实际是。您必须有一个限制因素（IO、CPU、内存或网络）。找到罪魁祸首并投入更多资金或重组解决方案，直到它不再是滞后指标。

于 2013-07-18T03:28:58.543 回答
0

步骤 1. 将适当的产品数据增量批量导入到新服务器。参考：将数据从单个客户端（或流）导入非空表 http://msdn.microsoft.com/en-us/library/ms177445(v=sql.105).aspx

步骤 2. 使用 Merge Statement 识别新的/现有的记录并对其进行操作。

我意识到这将占用新服务器上的大量磁盘空间，但该过程会运行得更快。

于 2013-07-17T22:06:17.570 回答