5

我正在研究在 SQL Server 2005 环境中使用日志传送。这个想法是设置频繁的日志传送到辅助服务器。意图：使用辅助服务器来提供报告查询，从而卸载主数据库服务器。

我在sqlservercentral 论坛线程上遇到了这个问题：

创建日志传送时，您有 2 个选择。您可以将还原日志操作配置为使用 norecovery 或使用备用选项来完成。如果使用 norecovery 选项，则不能对其发出 select 语句。如果您使用备用选项而不是 norecovery，则可以在数据库上运行选择查询。请记住，当日志文件还原发生时，用户将被踢出，而不会被还原过程发出警告。当您配置带有备用选项的日志传送时，您还可以在 2 个选项之间进行选择——杀死辅助数据库中的所有进程并执行日志恢复，或者如果正在使用数据库则不执行日志恢复。当然，如果您选择第二个选项，如果有人打开与数据库的连接并且没有关闭它，则还原操作可能永远不会运行，

所以我的问题是：

  • 以上是真的吗？你真的不能按照我想要的方式使用日志传送吗？
  • 如果这是真的，有人可以解释为什么在恢复事务日志时不能对数据库执行 SELECT 语句吗？

编辑：

第一个问题与此 serverfault question重复。但我仍然希望回答第二个问题：为什么在恢复事务日志时不能执行 SELECT 语句？

4

6 回答 6

7

好吧，是的，不是的。

您可以做您想做的事，通过将日志传送配置到数据库的只读副本，您可以将报告工作负载转移到辅助服务器。我之前已经在很多场合设置过这种类型的架构，它确实工作得很好。

需要注意的是，为了执行事务日志备份文件的还原，必须没有其他与相关数据库的连接。因此，两种选择是，当恢复过程运行时，它要么失败，从而优先考虑用户连接，要么通过断开所有用户连接来成功执行恢复。

根据您的还原频率，这不一定是问题。您只需教育您的用户一个事实，例如每小时 10 点，您的报告可能会失败。如果发生这种情况，只需重新运行报告。

编辑：您可能还想根据您的业务需求评估替代架构解决方案。例如，事务复制或使用数据库快照的数据库镜像

于 2009-12-02T13:24:48.960 回答
7

有人可以解释为什么在恢复事务日志时不能对数据库执行 SELECT 语句吗？

简短的回答是 RESTORE 语句对正在恢复的数据库进行排他锁。

对于写入，我希望不需要我解释为什么它们与还原不兼容。为什么它也不允许读取？首先，没有办法知道一个对数据库有锁的会话是要进行读还是写。但即使有可能，恢复（日志或备份）也是一种直接更新数据库中数据页的操作。由于这些更新直接进入物理位置（页面）并且不遵循逻辑层次结构（元数据分区页面行），因此它们不会遵守来自其他数据读取器的可能意图锁定，因此有可能更改结构因为他们被阅读。跟随页面 next-prev 指针的 SELECT 表扫描将被打乱，导致读取损坏。

于 2009-12-02T16:43:55.577 回答
3

如果您有企业版，则可以使用数据库镜像+快照来创建数据库的只读副本，可用于报告等。镜像使用“幕后”“连续”日志传送。它经常用于您描述的场景中。

于 2009-12-02T14:06:04.513 回答
2

对，是真的。

我认为会发生以下情况：
在恢复事务日志时，数据库被锁定，因为它的大部分正在更新。
这是出于性能原因，而不是其他任何原因。

我可以看到两个选项：

  1. 使用数据库镜像。
  2. 安排日志传送仅在报告系统未使用时发生。
于 2009-12-02T13:24:04.037 回答
0

稍微有点混乱，还原上的 norecovery 标志意味着您的数据库不会脱离恢复状态并进入联机状态 - 这就是选择语句不起作用的原因 - 数据库处于脱机状态。no-recovery 标志允许您连续恢复多个日志文件（在 DR 类型场景中），而无需使数据库重新联机。

如果您不想记录发货/有缺点，您可以换成单向事务复制，但总体上开销/设置会更复杂。

于 2009-12-02T13:27:23.423 回答
0

对等复制是否有效。然后，您可以在一个实例上运行查询，从而节省原始实例的负载。

于 2009-12-02T14:08:20.463 回答