随时根据可用性收缩数据库

Question

嗨，我正在使用这个查询来缩小数据库日志文件。

USE Tfs_CoE;
GO
ALTER DATABASE Tfs_CoE
SET RECOVERY SIMPLE;
GO
DBCC SHRINKFILE (Tfs_CoE_Log, 1);
GO
ALTER DATABASE Tfs_CoE
SET RECOVERY FULL;
GO

在我将数据库添加到“始终可用”组之前，它一直工作正常，现在我得到了这个错误。

MSG1468，级别16，状态2，第4行无法对数据库"Tfs_CoE“执行操作，因为它涉及数据库镜像会话或可用性组。在参与数据库镜像会话或可用性组的数据库上，不允许进行某些操作。Msg 5069，级别16，状态1，第4行ALTER语句失败。数据库“Tfs_CoE”的日志不能缩小，直到所有的次要程序都移动到添加日志的点之后。(1行(S)受影响) DBCC执行完毕。如果DBCC打印错误消息，请与系统管理员联系。

有人能帮我缩小数据库的日志文件吗?数据库的日志文件已经增长到650 of，它被配置为总是在可用性组上配置，数据库的实际大小只有39 of？

我甚至已经检查了事务日志的备份，但这对我不起作用，日志文件大小保持不变，650 me。

Answer 1

对于处于可用性组的数据库，它需要处于完全恢复模式。部分脚本试图将其设置为简单模式。

当然，更大的问题是，你为什么要缩小你的日志呢？

编辑:好的，看到你的编辑-错误表明(一个)你的第二个数据库(S)不是最新的，我会调查为什么可能是.在所有的第二阶段更新之前，您将无法截断日志。

Answer 2

确保首先对主DB进行完整备份或日志备份，然后从主DB执行收缩操作。

由于巨大的事务，它可能会再次增长，所以您可能想知道，在完全备份发生之前，添加几个日志备份是否有助于减少增长，或者确定是什么原因导致日志比数据文件大得多--通常是由于编写不当的查询或庞大的事务，或者可能没有做足够的备份来释放空间，因为您处于完全恢复模式。

1. 因此，对主DB执行完全备份。
2. 在没有ALTERing的镜像的主DB上运行SHRINKFILE到简单恢复模式

Answer 3

解决办法很简单。

问题是次要节点被设置为“可读”。这会锁定日志文件，而任何收缩它的操作都会出错。数据库数据库名的日志不能缩小，直到所有的次要文件都移到添加日志的点上。

更改对AG的信任，使二级不可读。然后执行主日志和辅助日志备份以清除日志文件。完成此操作后，通过运行以下查询执行收缩文件操作：

 Use [DatabaseName]
 GO
 DBCC SHRINKFILE (N'DatabaseName_log' , 1024, TRUNCATEONLY)
 GO