要求:
我正在寻找使用SSIS的优化方法。
正在考虑这些选项:
答案 0 :(得分:1)
这里要考虑的许多问题。例如位于同一域,位于同一网络中的服务器等等。
在大多数情况下,您都不想将数据作为数百万条记录中的单个大块来移动,但数量较少。 SSIS包可以为您处理该逻辑,但是您始终可以重新创建它,但是更容易迭代更改。有时候,这是更频繁地推送更改的原因,而不是等一整个星期,因为较小的同步更易于管理,停机时间更少。
另一个考虑因素是确保您了解增量,并确保已进行所有更改。因此,我通常建议在目标服务器上使用登台表。通过将更改移至登台,然后将其加载到最终表中,可以更轻松地确保更改已正确应用。考虑一下增量混乱(身份插入),日期时间排序错误或1个块失败的情况。使用临时表时,您不必仅依赖id /日期,而实际上可以对主键进行联接以查找更改。
Alex K.提出的链接服务器非常适合,但是您需要密切注意以下几点。始终从目标服务器上执行此操作,以便它是“推”式而不是“推”式。链接服务器查询数据的速度很快,但是批量更新/插入操作却很糟糕。表中根本不能包含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
如果必须每周一次。只是考虑仍然以小块的方式进行操作,以使每个插入操作对您的事务日志,生产表上的实际锁定时间等影响最小。请确保您永远不允许加载部分暂存/传输的数据,否则可能会导致增量搞砸了,您可能最终会丢失更改/等。
另一个想法是,如果是类似报告实例的场景,并且您有足够的服务器资源。您可以将整个表从生产环境转移到暂存中,或者在目标位置更新该表的副本,然后只需删除当前表并重命名暂存表即可。这是一种极端的情况,不是我通常喜欢的一种情况,但是有可能,并且对用户的实际影响是非常小的。
答案 1 :(得分:1)
对于SQL Server> 2005版,根据我的经验,通过导出将文件导出到文件等于或慢于使用SSIS在表之间直接传输数据。
话虽如此,除了@Matt提出的要点外,这是我进行此类转让的常用模式。
在目标数据库中创建一组表,这些表具有与源系统中的表相同的表模式。
使用SSIS数据流任务将数据从源拉到目标中的副本表。
在目标数据库中创建存储过程,以将数据转换为最终表中所需的形状。
使用SSIS执行SQL任务来调用存储过程。
(可选)如果转换很复杂,需要中间数据集,则可能需要为此步骤创建一个单独的Staging数据库架构。
您将必须决定是要使用存储过程将数据放入最终目标表中,还是要使过程写入中间表,然后将转换后的数据直接移入决赛桌。使用中间表可以最大程度地减少最终表的停机时间,但是,如果您的转换简单或很快,那么这对您来说可能不是问题。
根据所有这一切所需的软件包数量,您可能想要创建一个Master SSIS软件包,该软件包将依次调用提取软件包,转换软件包,然后使用中间处理表,即最终装载包。
答案 2 :(得分:1)
我认为SSIS擅长传输数据,这里的方法是:
1 。使用一个数据流任务创建一个程序包以传输数据。如果两个表的结构不同,那么可以,只需将它们映射即可。
2 。创建 SQL Server代理作业,以每个周末运行包
此外,功能跟踪数据更改(SQL Server)也很不错。您可以在想要同步数据时进行配置,并且它也具有出色的性能