是否可以在日志传送方案中以只读方式提供辅助服务器?

有人能解释一下为什么你不能 执行select语句到 当事务日志为 正在恢复?

简短的回答是restore语句对要还原的数据库采用独占锁。

对于写,我希望没有必要解释为什么它们与还原不兼容。为什么它也不允许读取?首先,无法知道在数据库上具有锁的会话是否要执行读或写操作。但即使可能,恢复(日志或备份)也是一种直接更新数据库中数据页的操作。由于这些更新直接指向物理位置(页面),并且不遵循逻辑层次结构(元数据分区页面行),因此它们不会接受来自其他数据读取器的可能意向锁,因此有可能更改结构。 当他们被阅读时 .在下一个prev指针后面的页面后面的select表扫描将导致混乱,导致读取损坏。

是的,也不是。

您可以做您希望做的事情,通过配置日志传送到数据库的只读副本,您可以将报告工作负载卸载到辅助服务器。我以前曾多次设置过这种类型的体系结构,它确实工作得很好。

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

取决于恢复频率,这不一定是个问题。你只需教育你的用户,比如说每过一小时10点,你的报告就有可能失败。如果发生这种情况,只需重新运行报告。

编辑:您可能还想根据您的业务需要评估替代的architecture解决方案。例如,事务复制或带有数据库快照的数据库镜像

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

是的,这是真的。

我认为会发生以下情况:
在还原事务日志时,数据库会被锁定,因为其中大部分都在更新中。
这主要是出于性能方面的原因。

我可以看到两种选择:

1. 使用数据库镜像。
2. 将日志传送计划为仅在报告系统不使用时发生。

稍微有点混乱,恢复时的norecovery标志意味着数据库不会从恢复状态变为联机状态—这就是为什么select语句不起作用—数据库处于脱机状态。无恢复标志允许您在一行中(在DR类型方案中)恢复多个日志文件,而不必使数据库重新联机。

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

对等复制是否有效?然后,您可以在一个实例上运行查询,从而在原始实例上保存负载。