长时间运行导入的数据库快照或临时表?

时间:2014-01-24 16:34:11

标签: sql .net sql-server wcf

我正在处理的应用程序需要从旧SQL系统(客户端)提取数据并将其导入我的应用程序的SQL数据库(服务器)。该方法使用WCF实现。我无法对客户端数据库进行任何架构更改。初始导入后,将根据客户端修改和创建的时间戳列生成后续导入。我需要从客户端数据库中提取3个不同表中的数据。

以下是我目前正在研究的解决方案,任何有关利弊的反馈都会很棒。作为一个概念验证,我在WCF上使用net.tcp进行初始导入过程,一次页面大小为100条记录,WCF事务需要0.5秒,在我的服务器上执行插入SPROC大约需要1.5-2.0秒(试图对此进行更多优化,SPROC必须在插入之前对服务器数据库进行一些检查,我认为这会导致阻塞。

服务器端处理 连接到客户端数据库主表,然后对于我需要从其他表创建的数据,向客户端创建另一个请求以提供该数据。这需要从服务器到客户端的大多数“往返”,但由于它只是发送数据,因此客户端需要的工作量最少。

临时表 在我的服务器上记录事务开始时间,在客户端创建一个临时表,将我需要的所有表连接在一起,然后返回发送到服务器的结果。操作完成后,将临时表放在客户端上。我以这种方式领先,即使我将在管道中发送更大的结果集,我的瓶颈是INSERT语句,如果我在发送之前将其全部处理成一个更大的表,我可以在服务器端执行所有操作插入SPROC而不是多个插入。

第三方工具 使用一些执行数据差异的第三方工具将客户端表的时间点副本执行到我的服务器数据库,然后在我的服务器数据库上本地处理它

MS Sync Framework 我排除了这个选项,我无法在客户端表上进行架构更改,它似乎需要跟踪更改。我很难理解自定义同步提供程序\接口。

合并复制 由于无法对客户进行更改,因此再次将其排除在外。

我的一些顾虑包括使用创建的表\修改时间戳行进行后续同步。我在该主题上阅读的大部分内容都表明,这不是处理数据同步的最佳做法,主要关注的问题是在同步之前开始但在同步之后才完成的事务,以便时间戳似乎已经导入。有没有更好的方法来跟踪变化?

我的同步解决方案实际上是单向同步,因为在服务器上创建的记录实际上是发送到客户端SPROC以便插入那里,然后在导入时我们将来自客户端的PK ID与FK ID进行比较。服务器,以确保我们不会导致循环或导入重复记录。如果我确实有冲突,客户总是赢。目前,我正在为每个导入会话引导一个临时表。

反馈

0 个答案:

没有答案