我需要获取当前数据库的“快照”，并使用新的主键将其克隆到同一个数据库中。
有问题的模式包含大约10个表，但有些表可能包含需要复制的数十万到100万条记录。
我有什么选择？
我担心编写SPROC需要在整个操作期间锁定有问题的数据库行（用于并发），这对其他用户来说非常烦人。假设我们可以在sqlserver允许的最大范围内优化它，这样的操作需要多长时间？是否需要30秒到1分钟来执行这么多插入？我无法锁定整个表并进行批量插入，因为其他帐户下的其他用户独立使用相同的表。
根据性能预期，另一种方法是将当前db转储到xml文件中，然后在后台悠闲地从此xml文件中异步克隆db。这样做的明显优点是db只能在执行xml转储时锁定，并且插入可以在后台运行。
如果一个优秀的DBA可以在10秒内完成“克隆”操作以执行开始结束，那么它可能不值得xmldump / webservice解决方案的复杂性。但是，如果它是一个失败的原因，并且可能数百万行插入可能会及时爆发，那么我宁愿立即开始使用xml方法。
或者可能有一个完全更好的方法？
非常感谢您提供的任何见解。
答案 0 :(得分：1)
我建议支持up数据库，然后将其恢复为服务器上的新数据库。您可以使用该新数据库作为源。 我肯定会建议不要使用xml转储的想法..
答案 1 :(得分：0)
是否需要在完全相同的表格中？您可以制作一组所有这些记录的“快照”表，您只需要一个插入+选择，例如
insert into snapshots_source1 (user,col1, col2, ..., colN)
select 'john', col1, col2, ..., colN from source1
等等。
您可以让snapshots_*拥有一个IDENTITY列，该列将创建“新PK”，如果您愿意，也可以保留旧PK。
这（几乎）没有锁定问题，看起来更加理智。
它确实需要更改代码，但是在适当的时候不应该让应用程序指向快照表。
这也简化了清洁和维护问题
---8<------8<------8<---outdated answer---8<---8<------8<------8<------8<---
为什么不直接进行实时备份并对目标克隆进行数据操作（更改密钥）？
现在，一般来说，这个带有新主键概念的快照听起来很可疑。如果您需要副本，则需要日志传送和群集服务，如果您希望数据副本生成“新应用程序实例”，则备份/恢复/操作过程应该足够。
你没有说你的数据库占用多少，但你可以在大约10秒内备份2000万行（800MB？），具体取决于你的磁盘子系统的速度......