cod*_*ape 5 sql-server sql-server-2005 log-shipping
我正在研究在SQL Server 2005环境中使用日志传送.这个想法是设置频繁的日志传送到辅助服务器.目的:使用辅助服务器提供报告查询,从而卸载主数据库服务器.
我在一个sqlservercentral论坛帖子中遇到过这个问题:
创建日志传送时,您有2个选择.您可以使用norecovery或备用选项配置还原日志操作.如果使用norecovery选项,则不能在其上发出select语句.如果您使用备用选项而不是norecovery,则可以在数据库上运行select查询.在日志文件恢复发生时请记住备用选项,用户将在没有警告的情况下被恢复进程.当您使用备用选项配置日志传送时,您也可以选择2个选项 - 在辅助数据库中终止所有进程并执行日志还原,或者在使用数据库时不执行日志还原.当然,如果选择第二个选项,如果有人打开与数据库的连接并且没有关闭它,则恢复操作可能永远不会运行,因此最好使用第一个选项.
所以我的问题是:
编辑:
第一个问题是此服务器故障问题的重复.但我还是想回答第二个问题:为什么在恢复事务日志时不能执行SELECT语句？
是的,没有.
您可以完全按照自己的意愿执行操作,因为您可以通过将日志传送配置为数据库的只读副本来将报告工作负载卸载到辅助服务器.我以前曾在很多场合设置过这种类型的架构,但确实非常有效.
需要注意的是,为了执行事务日志备份文件的还原,必须没有与该数据库的其他连接.因此,两个选择是,当恢复过程运行时,它将失败,从而优先考虑用户连接,或者通过断开所有用户连接以执行恢复来成功.
根据您的恢复频率,这不一定是个问题.您只需教育您的用户,即每小时10点钟,您的报告可能会失败.如果发生这种情况,只需重新运行报告即可.
编辑:您可能还想根据业务需求评估替代的architeciture解决方案.例如,使用数据库快照的事务复制或数据库镜像
有人可以解释为什么在恢复事务日志时不能对数据库执行SELECT语句？
简短的回答是RESTORE语句对正在恢复的数据库进行独占锁定.
对于写入,我希望我没有必要解释为什么它们与恢复不兼容.为什么它不允许读取？首先,无法知道锁定数据库的会话是进行读取还是写入.但即使可能,恢复(日志或备份)也是直接更新数据库中数据页的操作.由于这些更新直接进入物理位置(页面)并且不遵循逻辑层次结构(metadata-partition-page-row),因此它们不会尊重来自其他数据读取器的可能意图锁定,因此可以更改结构因为他们被阅读.页面next-prev指针后面的SELECT表扫描将被抛入混乱状态,导致读取损坏.