【问题标题】:Sociable SQL Server instance replication - Best practice社交 SQL Server 实例复制 - 最佳实践
【发布时间】:2016-12-11 07:47:46
【问题描述】:

我想知道在可能具有其他应用程序数据库的 SQL Server 实例上使用 SQL Server 复制的最佳实践也可能使用复制。也就是说,我们的产品需要与实例的其他用户很好地配合使用。

该产品当前使用 SQL Server 复制来创建用于报告的副本数据库。它始终是 SQL Server 实例的唯一用户。但我们现在需要记录和测试(法规要求)产品如何共享实例。

我在这里假设我们仍然需要复制,因为我们没有看到另一种将报告负载与应用程序数据库隔离的方法。

有人成功过吗?

如果我们使用实例级复制:

  • 有没有一种方法可以停止/启动/修改我们的应用程序的复制而不影响其他应用程序?

  • 设置差别很大吗?也就是说,跨应用共享实例级复制设置是否现实?

非实例复制只是看起来很难,我这里是不是看错了?

我们的客户使用 SQL Server 2008 R2 或 SQL Server 2012。

【问题讨论】:

  • 出于好奇,有什么法规要求您不能在您的环境中使用多主机数据库?也就是说,如果您担心复制(或任何其他流量)会对其他数据库产生太大影响,为什么您不能选择将这些其他数据库放在其他地方呢?对我来说似乎是任意的。
  • 监管要求是记录和测试,而不是技术。

标签: sql-server sql-server-2012 sql-server-2008-r2 database-replication


【解决方案1】:

在实例级别,复制只配置一个分发器。也就是说,无论您为实例上的复制配置了多少数据库,它们都将共享一个分发服务器。您确实可以选择将该分发器设为本地(即在同一实例上)或远程。因此,如果您发现分发占用了大量资源(或预计会出现这种情况),请配置远程分发。

保存数据库日志文件的任何驱动器都需要在其吞吐量中有足够的空间来处理 logreader 代理。如果您担心您的数据库的活动会影响其他数据库,请隔离。

至于其他问题,复制很像您的业务线应用程序。也就是说,它需要读取数据(来自发布者和分发者,具体取决于您所谈论的复制阶段)和写入数据(再次来自分发者和订阅者,具体取决于您所谈论的复制阶段)。相应地提供资源,你应该没问题。

【讨论】:

  • 谢谢 Ben,但问题不在于资源。它是关于与其他应用程序数据库共享实例级复制的最佳实践/实用性。
  • 如果我在评估这个,以上就是我会考虑的。我假设通过讨论是否首先对这些数据库进行多托管解决了任何安全问题。
猜你喜欢
  • 2015-11-07
  • 1970-01-01
  • 2010-11-17
  • 2011-04-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2018-01-30
  • 1970-01-01
相关资源
最近更新 更多