我们在 SQL Server 2000 上有一个数据库，该数据库应不时被截断。看起来最简单的解决方案是创建一个重复的数据库并在那里复制主数据库。然后主数据库可以被特别定制的存储过程安全地截断。
一种复制方式可以保证备份数据库包含来自主数据库的所有更新。
我们计划将备份数据库用于报告，将主要数据库用于操作数据。主数据库将在 2 天内在晚上截断一次。数据库是几千兆字节。只有几个表相当大（1-2 百万行）
有哪些可能的陷阱？这样的解决方案有多可靠？它会减慢主数据库的速度吗？
更新：用于复制的 DTS 变体听起来不错，但也有自己的缺点。它需要相当健壮的脚本，运行大约一个小时来复制更新的行。主数据库中的完整性约束也存在问题，这将使截断它成为非平凡的任务。由于这种复制，冷的东西大大地理顺了。
使用 union VIEW 也是可能的但不是很好的变体，因为系统主要在无人值守模式下工作，因此会占用专门的支持人员。这是相关的问题，但不是技术问题。
虽然复制通常很强大，但有时它可能会中断并需要刷新。管理和维护复制可能会变得复杂。一旦主数据库被截断，您必须确保该操作不会被复制。您可能还需要改进的行识别系统，因为在您多次截断主数据库表之后，您的辅助数据库中仍然会有完整的历史记录。
由于必须运行额外的线程来读取事务日志，因此发布者（主要）的性能受到影响。除非您此刻承受着沉重的负担，否则您可能不会注意到这种影响。事务日志管理也变得更加重要。
相反，我会为您的问题寻找不同的解决方案。例如，在截断之前，您可以对数据库进行备份，并将其还原为新的数据库名称。然后，您将拥有截断之前的数据库副本，并且您可以使用三部分名称同时查询两者。
您提到辅助数据的目的是保持报告关闭。在这种情况下，您可以创建一个类似于 SELECT * FROM Primary.dbo.Table UNION ALL SELECT * FROM SecondaryDBJune2008.dbo.Table UNION ALL SELECT * FROM SecondaryDBoctober2008.dbo.Table 的视图。然后，无论何时执行截断，您都需要使该视图保持最新。
另一种选择是在截断之前拍摄当前数据的快照并将其插入到单个报告数据库中。然后，您将拥有主数据库和历史数据库——创建视图后无需修改视图。
我们在 GB 中谈论多少数据？
由于您计划每两天执行一次截断，我推荐第二种选择，即在截断之前将数据快照到单个历史数据库中。这可以通过 SQL 代理作业轻松完成，而无需担心复制使两组数据保持同步。
我不会为此使用复制。我们有一个相当复杂的复制设置，运行着 80 多个分支，将一些表复制到一个中央数据库。当连接中断几天时，数据管理问题就会令人毛骨悚然。
如果要存档旧数据，请使用 DTS。然后，您可以将数据的复制和截断/删除构建到同一个 DTS 包中，将其设置为仅在复制成功时才会发生删除。