要求：
将数百万条记录从源（SQL Server）传输到目标（SQL Server） .
源表的结构与目标表不同 .
在目标服务器中每周刷新一次数据 .
处理的最短时间 .
我正在寻找使用SSIS的优化方法 .
正在考虑这些选择：
从源服务器创建Sql转储并将该转储导入目标服务器 .
直接将表从源服务器复制到目标服务器 .
对于SQL Server版本> 2005，根据我的经验，转储到具有导出的文件等于或慢于使用SSIS直接从表到表传输数据 .
也就是说，除了@Matt所做的优秀点之外，这是我为这种转移所遵循的通常模式 .
在目标数据库中创建一组表，这些表与源系统中的表具有相同的表模式 .
我通常将这些放入自己的数据库模式中，因此它们的目的很明确 .
我通常也使用SSIS OLE DB Destination包的"New"按钮来创建表 .
在编辑它提供的CREATE TABLE语句时，请注意[Schema] . [TableName]上的方括号 .
使用SSIS数据流任务将数据从源提取到目标中的副本表 .
这可以是一个包也可以是多个，具体取决于您拉过多少个表 .
在目标数据库中创建存储过程，以将数据转换为最终表中所需的形状 .
使用SSIS数据转换几乎毫无例外地比使用服务器端SQL处理效率低 .
使用SSIS执行SQL任务来调用存储过程 .
尽可能使用序列容器进行并行处理以节省时间 .
这可以是一个包或多个包，具体取决于您要转换的表数 .
（可选）如果转换很复杂，需要中间数据集，则可能需要为此步骤创建单独的Staging数据库架构 .
您必须决定是否要使用存储过程将数据置于最终目标表中，或者是否要将过程写入中间表，然后将转换后的数据直接移动到最终表中 . 使用中间表可以最大限度地缩短最终表的停机时间，但如果您的转换很简单或非常快，那么这对您来说可能不是问题 .
如果使用中间表，则需要一个或多个包来管理目标表中的最终数据加载 .
根据所有这些所需的包的数量，您可能想要创建一个主SSIS包，它将调用提取包，然后是转换包，然后，如果您使用中间处理表，最终装载包 .
这里要考虑很多问题 . 例如同一域中的服务器，同一网络上的服务器等 .
大多数情况下，您不希望将数据作为单个大块数百万条记录移动，但数量较少 . SSIS包为您处理该逻辑，但您也可以随时重新创建它，但更容易迭代更改 . 有时，这是更频繁地推动更改的原因，而不是等待整整一周，因为较小的同步更容易管理，停机时间更短 .
另一个考虑因素是确保您了解delta并确保您拥有所有更改 . 出于这个原因，我通常建议在目标服务器上使用临时表 . 通过将更改移至暂存，然后加载到最终表，您可以更轻松地确保正确应用更改 . 想象一下增量失序（标识插入），日期时间错误排序或1个块失败的情况 . 使用登台表时，您不必仅依赖于id / date，并且实际上可以在主键上进行连接以查找更改 .
Alex K.提出的链接服务器非常合适，但您需要密切关注一些事情 . 始终从目标服务器执行此操作，以便它是一个PULL而不是推送 . 链接服务器快速查询数据，但在批量更新/插入时非常糟糕 . 1列XML列根本不在表中 . 您可能需要设置一些具体的分布式事务的属性 .
我已经完成了这个任务，我会说SSIS确实比Linked Server有一点优势，因为它具有强大的错误处理，线程逻辑和使用不同适配器的能力（OLEDB，ODBC等等，它们具有不同的性能）进行搜索，你会发现一些结果） . 但是＃4的关键是在较小的块和临时表中进行，如果你能更频繁地做到这一点，就不太可能产生影响 . 例如 . 每日意味着它已经是每周大小的1/7，假设每天都有变化 .
Take 10,000,000 records changed a week. Once weekly = 10mill once daily = 1.4 mill Once hourly = 59K records Once Every 5 minutes = less than 5K records
如果必须每周一次 . 只考虑仍然在小块中执行它，以便每个插入对事务日志的影响更小， 生产环境 表上的实际锁定时间等 . 确保您永远不允许加载部分暂存/传输的数据，否则识别delta可能会得到搞砸了，你最终可能会错过更改/等等 .
另一个想法是，如果这是一个类似报告实例的场景，并且您有足够的服务器资源 . 您可以将整个表从 生产环境 转移到临时表或在目标处更新表的副本，然后只需执行一些当前表并重命名临时表 . 这是一个极端的情况，并不是我一般喜欢的情况，但它是可能的，对用户的实际影响将非常明显 .
我认为SSIS擅长传输数据，我的方法在这里：
1 . 使用一个 Data Flow Task 创建一个包以传输数据 . 如果两个表的结构不同那么它没关系，只需映射它们即可 .2 . 创建一个 SQL Server Agent job 以在每个周末运行您的包
另外，功能 Track Data Changes （SQL Server）也很好看 . 您可以配置何时想要同步数据，并且它也具有良好的性能
3 回答
对于SQL Server版本> 2005，根据我的经验，转储到具有导出的文件等于或慢于使用SSIS直接从表到表传输数据 .
也就是说，除了@Matt所做的优秀点之外，这是我为这种转移所遵循的通常模式 .
在目标数据库中创建一组表，这些表与源系统中的表具有相同的表模式 .
我通常将这些放入自己的数据库模式中，因此它们的目的很明确 .
我通常也使用SSIS OLE DB Destination包的"New"按钮来创建表 .
在编辑它提供的CREATE TABLE语句时，请注意[Schema] . [TableName]上的方括号 .
使用SSIS数据流任务将数据从源提取到目标中的副本表 .
这可以是一个包也可以是多个，具体取决于您拉过多少个表 .
在目标数据库中创建存储过程，以将数据转换为最终表中所需的形状 .
使用SSIS数据转换几乎毫无例外地比使用服务器端SQL处理效率低 .
使用SSIS执行SQL任务来调用存储过程 .
尽可能使用序列容器进行并行处理以节省时间 .
这可以是一个包或多个包，具体取决于您要转换的表数 .
（可选）如果转换很复杂，需要中间数据集，则可能需要为此步骤创建单独的Staging数据库架构 .
您必须决定是否要使用存储过程将数据置于最终目标表中，或者是否要将过程写入中间表，然后将转换后的数据直接移动到最终表中 . 使用中间表可以最大限度地缩短最终表的停机时间，但如果您的转换很简单或非常快，那么这对您来说可能不是问题 .
如果使用中间表，则需要一个或多个包来管理目标表中的最终数据加载 .
根据所有这些所需的包的数量，您可能想要创建一个主SSIS包，它将调用提取包，然后是转换包，然后，如果您使用中间处理表，最终装载包 .
这里要考虑很多问题 . 例如同一域中的服务器，同一网络上的服务器等 .
大多数情况下，您不希望将数据作为单个大块数百万条记录移动，但数量较少 . SSIS包为您处理该逻辑，但您也可以随时重新创建它，但更容易迭代更改 . 有时，这是更频繁地推动更改的原因，而不是等待整整一周，因为较小的同步更容易管理，停机时间更短 .
另一个考虑因素是确保您了解delta并确保您拥有所有更改 . 出于这个原因，我通常建议在目标服务器上使用临时表 . 通过将更改移至暂存，然后加载到最终表，您可以更轻松地确保正确应用更改 . 想象一下增量失序（标识插入），日期时间错误排序或1个块失败的情况 . 使用登台表时，您不必仅依赖于id / date，并且实际上可以在主键上进行连接以查找更改 .
Alex K.提出的链接服务器非常合适，但您需要密切关注一些事情 . 始终从目标服务器执行此操作，以便它是一个PULL而不是推送 . 链接服务器快速查询数据，但在批量更新/插入时非常糟糕 . 1列XML列根本不在表中 . 您可能需要设置一些具体的分布式事务的属性 .
我已经完成了这个任务，我会说SSIS确实比Linked Server有一点优势，因为它具有强大的错误处理，线程逻辑和使用不同适配器的能力（OLEDB，ODBC等等，它们具有不同的性能）进行搜索，你会发现一些结果） . 但是＃4的关键是在较小的块和临时表中进行，如果你能更频繁地做到这一点，就不太可能产生影响 . 例如 . 每日意味着它已经是每周大小的1/7，假设每天都有变化 .
如果必须每周一次 . 只考虑仍然在小块中执行它，以便每个插入对事务日志的影响更小， 生产环境 表上的实际锁定时间等 . 确保您永远不允许加载部分暂存/传输的数据，否则识别delta可能会得到搞砸了，你最终可能会错过更改/等等 .
另一个想法是，如果这是一个类似报告实例的场景，并且您有足够的服务器资源 . 您可以将整个表从 生产环境 转移到临时表或在目标处更新表的副本，然后只需执行一些当前表并重命名临时表 . 这是一个极端的情况，并不是我一般喜欢的情况，但它是可能的，对用户的实际影响将非常明显 .
我认为SSIS擅长传输数据，我的方法在这里：
1 . 使用一个 Data Flow Task 创建一个包以传输数据 . 如果两个表的结构不同那么它没关系，只需映射它们即可 .
2 . 创建一个 SQL Server Agent job 以在每个周末运行您的包
另外，功能 Track Data Changes （SQL Server）也很好看 . 您可以配置何时想要同步数据，并且它也具有良好的性能