请教always on 日志收缩问题

[xiaodai511]

公司启用always on后发现日志不断增长，网上也找了解决办法 日志备份收缩，定时在每天晚上执行，可是并不能每天都执行成功。。。
基本是这个错误-- 无法收缩日志文件 2 (ODBC_CONDB_log)，因为该文件结尾的逻辑日志文件正在使用。 字面理解应该是在向辅助副本传输数据 主副本在等待吧（我用的同步提交方式）
贴一下执行代码--

use [ODBC_CONDB]  
declare @bakfile nvarchar(100)--@bakfile备份文件名  
set @bakfile='E:\DBFilesBAK\DBBackup_Log\ODBC_CONDB_log_'+REPLACE(REPLACE(REPLACE(REPLACE(CONVERT(CHAR(16), GETDATE(), 120),
                                                      '-', ''), '', ''), ':',
                                      ''), ' ', '')+'.bak'  
BACKUP LOG [ODBC_CONDB] TO DISK= @bakfile WITH RETAINDAYS= 1,COMPRESSION 

  
DBCC SHRINKFILE (N'ODBC_CONDB_log' , 2048) --dbName_log为数据库文件逻辑名称，50000为希望日志收缩到的MB数  
go

请教大佬你们是如何解决的。。。难道只能增加收缩频率么？

[吉普赛的歌]

alwayson 同步模式对性能的影响相当大， 建议改为异步模式。即使你是同步模式， 也会有延迟。 备份后日志无法收缩成功是因为没有完全传过去， 你这时候收缩当然没用， 没有什么神仙能保证一次性搞定。 这个跟同步、异步没什么关系。 能做的是： 1. 不要收缩那么厉害， 如果库比较大（超过100GB）， 那至少保留 10GB， 不要那么吝啬留一点点， 即使你收缩到了 2GB， 最终还是经增长的， 你保留 10GB， 其实在备份日志之后， 10GB 是预留空间， 在日志没达到 10GB 之前不会再增长。 2. 如果一定要收缩， 可以 20GB, 10GB, 5GB, 2GB 这样逐步收缩， 这比一次性收缩成功率高得多。 3. 在做完大型的操作（比如：索引重建、数据迁移）之后， 不要马上收缩， 可以固定在基本无任何操作的时间段来备份和收缩， 比如 早晨 5 点， 收缩一次， 早里 6 点再收缩一次， 就差不多了。

[xiaodai511]

引用 1 楼 yenange 的回复:

alwayson 同步模式对性能的影响相当大， 建议改为异步模式。即使你是同步模式， 也会有延迟。 备份后日志无法收缩成功是因为没有完全传过去， 你这时候收缩当然没用， 没有什么神仙能保证一次性搞定。 这个跟同步、异步没什么关系。 能做的是： 1. 不要收缩那么厉害， 如果库比较大（超过100GB）， 那至少保留 10GB， 不要那么吝啬留一点点， 即使你收缩到了 2GB， 最终还是经增长的， 你保留 10GB， 其实在备份日志之后， 10GB 是预留空间， 在日志没达到 10GB 之前不会再增长。 2. 如果一定要收缩， 可以 20GB, 10GB, 5GB, 2GB 这样逐步收缩， 这比一次性收缩成功率高得多。 3. 在做完大型的操作（比如：索引重建、数据迁移）之后， 不要马上收缩， 可以固定在基本无任何操作的时间段来备份和收缩， 比如 早晨 5 点， 收缩一次， 早里 6 点再收缩一次， 就差不多了。

我把收缩后大小调大了 成功率确实变高了~~非常感谢，您说的异步模式，以前试过，会一直显示正在同步，异步模式会不会导致辅助副本的数据丢失呢？其实我这边目前的需求仅是想要辅助副本实时（有几分钟延迟也没关系）数据，然后数据仓库或者报表数据从辅助副本取

[吉普赛的歌]

引用 2 楼 xiaodai511 的回复:

[quote=引用 1 楼 yenange 的回复:] alwayson 同步模式对性能的影响相当大， 建议改为异步模式。即使你是同步模式， 也会有延迟。 备份后日志无法收缩成功是因为没有完全传过去， 你这时候收缩当然没用， 没有什么神仙能保证一次性搞定。 这个跟同步、异步没什么关系。 能做的是： 1. 不要收缩那么厉害， 如果库比较大（超过100GB）， 那至少保留 10GB， 不要那么吝啬留一点点， 即使你收缩到了 2GB， 最终还是经增长的， 你保留 10GB， 其实在备份日志之后， 10GB 是预留空间， 在日志没达到 10GB 之前不会再增长。 2. 如果一定要收缩， 可以 20GB, 10GB, 5GB, 2GB 这样逐步收缩， 这比一次性收缩成功率高得多。 3. 在做完大型的操作（比如：索引重建、数据迁移）之后， 不要马上收缩， 可以固定在基本无任何操作的时间段来备份和收缩， 比如 早晨 5 点， 收缩一次， 早里 6 点再收缩一次， 就差不多了。

我把收缩后大小调大了 成功率确实变高了~~非常感谢，您说的异步模式，以前试过，会一直显示正在同步，异步模式会不会导致辅助副本的数据丢失呢？其实我这边目前的需求仅是想要辅助副本实时（有几分钟延迟也没关系）数据，然后数据仓库或者报表数据从辅助副本取[/quote] 异步模式， 永远显示正在同步中， 不要被表面迷惑。 再说了， 同步模式也避免不了延迟。 如果没有大操作（归档、索引重建、大量删除数据），一般也就是1秒内延迟。 对于你这种几分钟的， 完全够了。 数据丢失， 除非断电或其它非常大的意外， 基本不需要考虑的。

[xiaodai511]

引用 3 楼 yenange 的回复:

[quote=引用 2 楼 xiaodai511 的回复:] [quote=引用 1 楼 yenange 的回复:] alwayson 同步模式对性能的影响相当大， 建议改为异步模式。即使你是同步模式， 也会有延迟。 备份后日志无法收缩成功是因为没有完全传过去， 你这时候收缩当然没用， 没有什么神仙能保证一次性搞定。 这个跟同步、异步没什么关系。 能做的是： 1. 不要收缩那么厉害， 如果库比较大（超过100GB）， 那至少保留 10GB， 不要那么吝啬留一点点， 即使你收缩到了 2GB， 最终还是经增长的， 你保留 10GB， 其实在备份日志之后， 10GB 是预留空间， 在日志没达到 10GB 之前不会再增长。 2. 如果一定要收缩， 可以 20GB, 10GB, 5GB, 2GB 这样逐步收缩， 这比一次性收缩成功率高得多。 3. 在做完大型的操作（比如：索引重建、数据迁移）之后， 不要马上收缩， 可以固定在基本无任何操作的时间段来备份和收缩， 比如 早晨 5 点， 收缩一次， 早里 6 点再收缩一次， 就差不多了。

我把收缩后大小调大了 成功率确实变高了~~非常感谢，您说的异步模式，以前试过，会一直显示正在同步，异步模式会不会导致辅助副本的数据丢失呢？其实我这边目前的需求仅是想要辅助副本实时（有几分钟延迟也没关系）数据，然后数据仓库或者报表数据从辅助副本取[/quote] 异步模式， 永远显示正在同步中， 不要被表面迷惑。 再说了， 同步模式也避免不了延迟。 如果没有大操作（归档、索引重建、大量删除数据），一般也就是1秒内延迟。 对于你这种几分钟的， 完全够了。 数据丢失， 除非断电或其它非常大的意外， 基本不需要考虑的。[/quote] 明白了，谢谢版主的建议。

[Foliole]

楼主，你设置定时收缩不用设置数据库模式为简单模式吗？

[MYSylvanas]

引用 3 楼 吉普赛的歌 的回复:

[quote=引用 2 楼 xiaodai511 的回复:]
[quote=引用 1 楼 yenange 的回复:]
alwayson 同步模式对性能的影响相当大， 建议改为异步模式。即使你是同步模式， 也会有延迟。

备份后日志无法收缩成功是因为没有完全传过去， 你这时候收缩当然没用， 没有什么神仙能保证一次性搞定。
这个跟同步、异步没什么关系。

能做的是：
1. 不要收缩那么厉害， 如果库比较大（超过100GB）， 那至少保留 10GB， 不要那么吝啬留一点点， 即使你收缩到了 2GB， 最终还是经增长的， 你保留 10GB， 其实在备份日志之后， 10GB 是预留空间， 在日志没达到 10GB 之前不会再增长。
2. 如果一定要收缩， 可以 20GB, 10GB, 5GB, 2GB 这样逐步收缩， 这比一次性收缩成功率高得多。
3. 在做完大型的操作（比如：索引重建、数据迁移）之后， 不要马上收缩， 可以固定在基本无任何操作的时间段来备份和收缩， 比如 早晨 5 点， 收缩一次， 早里 6 点再收缩一次， 就差不多了。

我把收缩后大小调大了 成功率确实变高了~~非常感谢，您说的异步模式，以前试过，会一直显示正在同步，异步模式会不会导致辅助副本的数据丢失呢？其实我这边目前的需求仅是想要辅助副本实时（有几分钟延迟也没关系）数据，然后数据仓库或者报表数据从辅助副本取[/quote]

异步模式， 永远显示正在同步中， 不要被表面迷惑。
再说了， 同步模式也避免不了延迟。
如果没有大操作（归档、索引重建、大量删除数据），一般也就是1秒内延迟。
对于你这种几分钟的， 完全够了。

数据丢失， 除非断电或其它非常大的意外， 基本不需要考虑的。[/quote]
借地问一下，always on节点中的索引同步时什么原理？
如果我在辅助节点上执行重建索引，重建索引时会产生大量的日志文件占用磁盘空间，请问是只占用执行节点还是群集内的所有节点？
谢谢！

[吉普赛的歌]

引用 6 楼 MYSylvanas 的回复:

[quote=引用 3 楼 吉普赛的歌 的回复:] [quote=引用 2 楼 xiaodai511 的回复:] [quote=引用 1 楼 yenange 的回复:] alwayson 同步模式对性能的影响相当大， 建议改为异步模式。即使你是同步模式， 也会有延迟。 备份后日志无法收缩成功是因为没有完全传过去， 你这时候收缩当然没用， 没有什么神仙能保证一次性搞定。 这个跟同步、异步没什么关系。 能做的是： 1. 不要收缩那么厉害， 如果库比较大（超过100GB）， 那至少保留 10GB， 不要那么吝啬留一点点， 即使你收缩到了 2GB， 最终还是经增长的， 你保留 10GB， 其实在备份日志之后， 10GB 是预留空间， 在日志没达到 10GB 之前不会再增长。 2. 如果一定要收缩， 可以 20GB, 10GB, 5GB, 2GB 这样逐步收缩， 这比一次性收缩成功率高得多。 3. 在做完大型的操作（比如：索引重建、数据迁移）之后， 不要马上收缩， 可以固定在基本无任何操作的时间段来备份和收缩， 比如 早晨 5 点， 收缩一次， 早里 6 点再收缩一次， 就差不多了。

我把收缩后大小调大了 成功率确实变高了~~非常感谢，您说的异步模式，以前试过，会一直显示正在同步，异步模式会不会导致辅助副本的数据丢失呢？其实我这边目前的需求仅是想要辅助副本实时（有几分钟延迟也没关系）数据，然后数据仓库或者报表数据从辅助副本取[/quote] 异步模式， 永远显示正在同步中， 不要被表面迷惑。 再说了， 同步模式也避免不了延迟。 如果没有大操作（归档、索引重建、大量删除数据），一般也就是1秒内延迟。 对于你这种几分钟的， 完全够了。 数据丢失， 除非断电或其它非常大的意外， 基本不需要考虑的。[/quote] 借地问一下，always on节点中的索引同步时什么原理？ 如果我在辅助节点上执行重建索引，重建索引时会产生大量的日志文件占用磁盘空间，请问是只占用执行节点还是群集内的所有节点？ 谢谢！[/quote] 所有节点。

[MYSylvanas]

引用 7 楼 吉普赛的歌 的回复:

[quote=引用 6 楼 MYSylvanas 的回复:]
[quote=引用 3 楼 吉普赛的歌 的回复:]
[quote=引用 2 楼 xiaodai511 的回复:]
[quote=引用 1 楼 yenange 的回复:]
alwayson 同步模式对性能的影响相当大， 建议改为异步模式。即使你是同步模式， 也会有延迟。

备份后日志无法收缩成功是因为没有完全传过去， 你这时候收缩当然没用， 没有什么神仙能保证一次性搞定。
这个跟同步、异步没什么关系。

能做的是：
1. 不要收缩那么厉害， 如果库比较大（超过100GB）， 那至少保留 10GB， 不要那么吝啬留一点点， 即使你收缩到了 2GB， 最终还是经增长的， 你保留 10GB， 其实在备份日志之后， 10GB 是预留空间， 在日志没达到 10GB 之前不会再增长。
2. 如果一定要收缩， 可以 20GB, 10GB, 5GB, 2GB 这样逐步收缩， 这比一次性收缩成功率高得多。
3. 在做完大型的操作（比如：索引重建、数据迁移）之后， 不要马上收缩， 可以固定在基本无任何操作的时间段来备份和收缩， 比如 早晨 5 点， 收缩一次， 早里 6 点再收缩一次， 就差不多了。

我把收缩后大小调大了 成功率确实变高了~~非常感谢，您说的异步模式，以前试过，会一直显示正在同步，异步模式会不会导致辅助副本的数据丢失呢？其实我这边目前的需求仅是想要辅助副本实时（有几分钟延迟也没关系）数据，然后数据仓库或者报表数据从辅助副本取[/quote]

异步模式， 永远显示正在同步中， 不要被表面迷惑。
再说了， 同步模式也避免不了延迟。
如果没有大操作（归档、索引重建、大量删除数据），一般也就是1秒内延迟。
对于你这种几分钟的， 完全够了。

数据丢失， 除非断电或其它非常大的意外， 基本不需要考虑的。[/quote]
借地问一下，always on节点中的索引同步时什么原理？
如果我在辅助节点上执行重建索引，重建索引时会产生大量的日志文件占用磁盘空间，请问是只占用执行节点还是群集内的所有节点？
谢谢！[/quote]

所有节点。[/quote]
那这样调整起来就比较麻烦了，可能要改变下策略，只做重整不做重建，谢谢！

[吉普赛的歌]

引用 8 楼 MYSylvanas 的回复:

[quote=引用 7 楼 吉普赛的歌 的回复:] [quote=引用 6 楼 MYSylvanas 的回复:] [quote=引用 3 楼 吉普赛的歌 的回复:] [quote=引用 2 楼 xiaodai511 的回复:] [quote=引用 1 楼 yenange 的回复:] alwayson 同步模式对性能的影响相当大， 建议改为异步模式。即使你是同步模式， 也会有延迟。 备份后日志无法收缩成功是因为没有完全传过去， 你这时候收缩当然没用， 没有什么神仙能保证一次性搞定。 这个跟同步、异步没什么关系。 能做的是： 1. 不要收缩那么厉害， 如果库比较大（超过100GB）， 那至少保留 10GB， 不要那么吝啬留一点点， 即使你收缩到了 2GB， 最终还是经增长的， 你保留 10GB， 其实在备份日志之后， 10GB 是预留空间， 在日志没达到 10GB 之前不会再增长。 2. 如果一定要收缩， 可以 20GB, 10GB, 5GB, 2GB 这样逐步收缩， 这比一次性收缩成功率高得多。 3. 在做完大型的操作（比如：索引重建、数据迁移）之后， 不要马上收缩， 可以固定在基本无任何操作的时间段来备份和收缩， 比如 早晨 5 点， 收缩一次， 早里 6 点再收缩一次， 就差不多了。

我把收缩后大小调大了 成功率确实变高了~~非常感谢，您说的异步模式，以前试过，会一直显示正在同步，异步模式会不会导致辅助副本的数据丢失呢？其实我这边目前的需求仅是想要辅助副本实时（有几分钟延迟也没关系）数据，然后数据仓库或者报表数据从辅助副本取[/quote] 异步模式， 永远显示正在同步中， 不要被表面迷惑。 再说了， 同步模式也避免不了延迟。 如果没有大操作（归档、索引重建、大量删除数据），一般也就是1秒内延迟。 对于你这种几分钟的， 完全够了。 数据丢失， 除非断电或其它非常大的意外， 基本不需要考虑的。[/quote] 借地问一下，always on节点中的索引同步时什么原理？ 如果我在辅助节点上执行重建索引，重建索引时会产生大量的日志文件占用磁盘空间，请问是只占用执行节点还是群集内的所有节点？ 谢谢！[/quote] 所有节点。[/quote] 那这样调整起来就比较麻烦了，可能要改变下策略，只做重整不做重建，谢谢！[/quote] 关系不大的， 如果空间紧张， 每重建一个表就立即备份一次日志并收缩日志即可。

[鱼小儿]

你好，我的Aways ON环境数据库日志文件已经快1个T了，通过网上很多方法都没收缩成功，通过DBCC LOGINFO 查看Status 状态全为2，请问有办法解决吗？

[xiaodai511]

引用 10 楼 鱼小儿 的回复:

你好，我的Aways ON环境数据库日志文件已经快1个T了，通过网上很多方法都没收缩成功，通过DBCC LOGINFO 查看Status 状态全为2，请问有办法解决吗？

我就是用的dbcc shrinkfile收缩的，收缩前先备份日志，有的时候会有失败所以一天两次。

[MYSylvanas]

我现在都是用BACKUP LOG DBNAME TO DISK='NUL:'
2小时执行一次，磁盘资源有限，省的日志增长过快导致爆满