日志传送或镜像是灾难恢复的更好解决方案吗？
日志传送或镜像是灾难恢复的更好解决方案吗？
提问于 2012-08-29 19:00:24
我正计划重建一个索引，但是我的日志很容易出现过大的大小。
事实上，我倾向于做一个智能的重新索引，但由于碎片级别大于30%，我认为我应该做一个重建。
我的数据库使用完整的恢复模型。当发生的事务较少时，在本周末晚些时候进行重建之前，是否应该将恢复模型更改为大容量日志。
日志传送在这些数据库中作为DR解决方案启用。
如果我的潜伏期很高，你有什么建议？有什么更好的解决方案需要我去研究吗？
回答 2
Database Administration用户
回答已采纳
发布于 2012-08-29 19:08:39
我想这和你刚刚发布的另一个问题是一样的。你有几个新的观点：
大容量日志模式不会使通过线路发送的日志变得更小。它只会减少对本地日志文件的写入IO强度。一旦日志必须备份，alle更改的页面就必须包含在备份中。最终的结果是您的trans备份将是同样大的。
如果您已经具有较高的延迟时间，则更改为镜像不会改变这一点。分散负载的唯一方法是:停止重新构建并更改扩展重组策略(正如我在另一个问题中提到的)。
或者，正如其他人所提到的，开始进行更频繁的日志备份，并以更高的频率发送较小的日志备份。
只是基于你现在告诉我们的。(高延迟)我个人不建议改为镜像。但是在镜像和日志传送之间的选择应该基于更多的项目，而不仅仅是延迟。
Database Administration用户
发布于 2012-08-29 20:28:44
您正在压缩日志备份吗？我建议你这样做。它是2008年R2标准版和2008年R1 EE标准版中的一个可用选项。我同意，在决定DR解决方案时，您应该考虑的不仅仅是延迟。
页面原文内容由Database Administration提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://dba.stackexchange.com/questions/23381
复制相关文章
相似问题
腾讯云开发者
