sql-server – 使用AlwaysOn可用性组时收缩事务日志

前端之家收集整理的这篇文章主要介绍了sql-server – 使用AlwaysOn可用性组时收缩事务日志前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我们正在使用sql Server 2012的AlwaysOn可用性组功能.常规完整数据库备份和事务日志备份每天在辅助数据库上完成.

我已阅读here在主副本上执行事务日志备份,或者副本副本将两个副本的事务日志标记为可重用.无论如何,事务日志备份大小很大,可以使用shrink文件减少:

我已在本地恢复数据库并执行收缩操作.日志文件大小减少到160 MB.

我的问题是我应该在哪个数据库上对事务日志文件(主要,次要或两者)执行收缩操作?

我想在过去的几年里没有备份日志文件,所以它变得如此巨大.执行DBCC sqlPERF(LOGSPACE)我可以看到只使用了0.06%的文件 – 我没有必要保留这么大的日志文件.在[sys].[database_files]中,我检查它的max_size是否设置为-1,增长到65536所以我想当它需要更多空间时它会得到.无论如何,我可以将它缩小到5%,例如为了防止未来的增长.我试图找到一些确认,我这样做是不错的主意.

实际上,备份(在数据库和日志文件上)仅在辅助数据库上执行,因此在它们上执行收缩文件会更容易,但是主日志文件的大小也会减少吗?

解决方法

在AG中,写入只能在主数据库上发生.收缩操作是写入.因此,您必须对主数据库进行缩减.请注意,收缩可能不会像您预期的那样缩小,您对已恢复数据库的测试可能会利用简单的恢复模型.阅读 How to shrink the SQL Server log了解更多信息.

不要缩小到160MB.确定原因为什么日志增长到121Gb所以它不会重复(你有一个怀疑,如果可能的话会很好确认).将日志大小调整为适合您的操作需求的大小.日志增长是一个严重的问题,它无法使用即时文件初始化,并且所有数据库活动将在日志增长并被初始化为0时冻结.用户和应用程序在发生时就讨厌它.如果您了解影响并且您的用户没问题,那么您可以缩小一次(160MB可能太小)并让它一直增长直到它稳定下来.

猜你在找的MsSQL相关文章