Sql 数据库复制是保持生产和开发数据库同步的方法吗？

我不是DBA；然而，我的小公司正在使用SQL Server进行我们正在进行的一个项目。在同一个SQL Server实例上，有一个MS Great Plains（Dynamics GP）数据库—我们在两个数据库之间来回传递数据（主要是一个获取数据并将其传输到GP的抄写过程）

我们正在使用数据库复制（快照）作为同步生产和开发（以及很快的灾难恢复）环境的一种手段。现在，它将在核心业务时间内每三个小时进行一次复制，主要是为了在我们工作时使生产和开发保持最新

1） 这样做对吗？有更好的办法吗？ 2） 这会给服务器或SQL server带来压力吗？这是否是GP数据库问题的可能原因，因为它们位于同一服务器和实例上？ 3） 复制只发生在非GP数据库上-这应该不会影响GP数据库，对吗

---

我们的数据库应该保持相当小。在执行快照时，据我所知，表在复制过程中会被锁定。在整个复制完成之前，表是否一直处于锁定状态？或者在复制过程继续进行时，表是否在复制完成后卸载？

有许多方法可以将SQL Server与另一个SQL Server同步。您当前正在使用的复制、日志传送、备份/恢复、镜像，以及“始终打开”等方法

“最佳”方法取决于您的需求。如果您关心灾难恢复，快照复制不是一个很好的选择，我将研究AlwaysOn可用性组

如果生产系统的负载是一个问题，我会考虑每晚恢复生产系统的备份

回答您的具体问题：
这是做这种事的正确方法吗？有更好的方法吗？
这个答案取决于你的确切要求

2）这会给服务器或SQL server带来压力吗？
做点什么总比什么都不做更重要。这可能会影响生产服务器，具体取决于许多因素

3）复制只发生在非GP数据库上-这应该不会影响GP数据库，好吗？

---

您的服务器只有有限的硬件资源。它可能会影响针对GP数据库的查询性能

我们发现，在升级和模式更改时，复制也会增加复杂性。如果您必须使开发和产品同步（我会争论这一点），那么始终打开或日志传送将是我首选的技术

---

DR是另一个问题。您必须确定恢复点目标（RPO）和恢复时间目标（RTO），并采用适当的技术来满足您的要求。

听起来您可能想研究事务性复制。它的设置方式与snapshot相同，不同的是它保持管道打开，并在事务发生时推送或拉取事务。事务不是一天三次进行大推拉，而是不断地进行批处理。只有在创建初始快照时，您才会受到惩罚。它可以在生产服务器上创建负载，这是我过去使用称为CDC（更改数据捕获）的功能和SSIS（Sql server集成服务）实现的一种方式。这需要Sql 2008或新版本。您有Sql server Enterprise或Standard edition吗？你可以在企业中玩更多的玩具。真正的问题是为什么你需要开发数据库来匹配prod数据库？事实上，我公司的政策是在开发人员数据库中只有虚假数据。。。我的意思是，我忽略了这个政策，但仍然看不到有必要几乎实时同步到dev@DeanOC。我相信我们有企业版。我完全同意这一点。我一直不明白为什么复制在对文章和/或模式的更改方面没有更大的灵活性。我想这和检查站之类的东西有关。我会一直看下去的