如何在SQLServer数据库中复制大量数据集

Question

我有一个要求，使用新的主键将当前数据库的“快照”复制到同一个数据库中。

有问题的模式由大约10个表组成，但少数表可能包含数十万至1百万条需要重复的记录。

我在这里有什么选择？

恐怕编写SPROC需要在整个操作过程中锁定有问题的数据库行（对于并发），这对其他用户来说很烦人。假设我们可以将其优化到sqlserver允许的最大范围，这种操作需要多长时间？执行这么多插入操作需要30秒到1分钟吗？我无法锁定整个表并进行批量插入，因为其他帐户下的其他用户正在独立使用相同的表。

根据业绩预期，另一种是将目前的DB转储到一个XML文件，然后异步复制从该XML文件的分贝在后台休闲。这样做的明显优点是数据库只在执行xml转储所需的时间内被锁定，并且插入可以在后台运行。

如果一个好的DBA可以得到“克隆”操作执行开始到结束，在10秒钟，然后它可能不值得的xmldump/Web服务解决方案的复杂性。但如果它是一个失败的原因，并且插入潜在的数百万行可能会及时膨胀，那么我宁愿立即开始使用xml方法。

或者也许有一个完全更好的方法？

非常感谢您提供的任何见解。

Answer 1

我建议备份向上数据库，然后恢复它作为你的服务器上的新数据库。您可以使用该新数据库作为您的来源。 我一定会建议对XML转储想法..

Answer 2

是否需要是完全一样的表吗？你可以做一套的“快照”的表，所有这些记录走了，你只需要单个插入+选择，像

insert into snapshots_source1 (user,col1, col2, ..., colN) 
select 'john', col1, col2, ..., colN from source1 

等。

你可以让snapshots_*有一个IDENTITY列，它将创建'新的PK'，并且如果你愿意的话也可以保留旧的。

这（几乎）没有锁定问题，看起来更加安全。

它确实需要在代码的改变，但不应该太硬，使应用程序在适当的时候指向快照表。

这也简化了清洁和维护问题

---8<------8<------8<---outdated answer---8<---8<------8<------8<------8<---

你为什么不只是采取现场备份和目的地克隆做数据操作（按键变化）？

现在，在一般情况下，该快照与新的主键想法听起来很可疑。如果你想要一个副本，你有日志传送和集群服务，如果你想要一个数据副本来生成一个'新的应用程序实例'，备份/恢复/操作过程应该足够了。

你不说你的DB多少占领，但你可以在10秒左右肯定备份2000万行（800MB？），这取决于您的磁盘子系统如何快速...