2

我需要获取当前数据库的“快照”并将其克隆到同一个数据库中，并使用新的主键。

有问题的模式由大约 10 个表组成，但其中一些表可能包含需要复制的数十万到 100 万条记录。

我在这里有什么选择？

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

根据性能预期，另一种方法是将当前数据库转储到 xml 文件中，然后在后台闲暇时从该 xml 文件异步克隆数据库。这样做的明显优势是数据库仅在执行 xml 转储所需的时间内被锁定，并且插入可以在后台运行。

如果一个优秀的 DBA 可以让“克隆”操作在 10 秒内从头到尾执行，那么 xmldump/webservice 解决方案的复杂性可能不值得。但是，如果这是一个失败的原因，并且插入数百万行可能会及时膨胀，那么我宁愿立即开始使用 xml 方法。

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

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

4

2 回答 2

1

我建议备份数据库，然后将其还原为服务器上的新数据库。您可以使用该新数据库作为您的来源。我肯定会推荐反对 xml 转储的想法..

于 2009-11-18T22:22:50.840 回答
0

它需要在完全相同的表中吗？您可以在所有这些记录所在的位置制作一组“快照”表，您只需要一个插入 + 选择，例如

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<---

为什么不直接进行实时备份并在目标克隆上进行数据操作（更改密钥）？

现在，总的来说，这个带有新主键想法的快照听起来很可疑。如果你想要一个副本，你有日志传送和集群服务，如果你想要一个数据的副本来生成一个“新的应用程序实例”，那么备份/恢复/操作过程就足够了。

您没有说您的数据库将占用多少，但您当然可以在大约 10 秒内备份 2000 万行（800MB？），具体取决于您的磁盘子系统的速度......

于 2009-11-18T22:26:16.507 回答