sql-server - 在日志传送场景中是否可以使辅助服务器只读？

Question

我正在研究在 SQL Server 2005 环境中使用日志传送。这个想法是设置频繁的日志传送到辅助服务器。目的:使用辅助服务器提供报表查询服务，从而减轻主数据库服务器的负担。

我在sqlservercentral forum thread上发现了这个:

When you create the log shipping you have 2 choices. You can configure restore log operation to be done with norecovery or with standby option. If you use the norecovery option, you can not issue select statements on it. If instead of norecovery you use the standby option, you can run select queries on the database.Bear in mind with the standby option when log file restores occur users will be kicked out without warning by the restore process. Acutely when you configure the log shipping with standby option, you can also select between 2 choices – kill all processes in the secondary database and perform log restore or don’t perform log restore if the database is being used. Of course if you select the second option, the restore operation might never run if someone opens a connection to the database and doesn’t close it, so it is better to use the first option.

所以我的问题是:

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

编辑:

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

Answer 1

could someone explain why you cannot execute SELECT statements to a database while the transaction log is being restored?

简短的回答是，RESTORE 语句对正在恢复的数据库采用独占锁。

对于写入，我希望不需要我解释为什么它们与恢复不兼容。为什么它也不允许读取？首先，无法知道锁定数据库的 session 是否将执行读取或写入操作。但即使可能，恢复(日志或备份)也是直接更新数据库中的数据页的操作。由于这些更新直接进入物理位置(页面)并且不遵循逻辑层次结构(元数据-分区-页面-行)，因此它们不会接受来自其他数据读取器的可能的意向锁，因此有可能更改结构按照阅读方式。跟随页下一页指针的 SELECT 表扫描将陷入困惑，导致读取损坏。