使用 AlwaysOn 可用性组时收缩事务日志

got*_*tqn 17 sql-server shrink sql-server-2012 transaction-log

我们正在使用AlwaysOn Availability GroupSQL Server 2012 的功能。每天都会在辅助数据库上进行定期的完整数据库备份和事务日志备份。

我在这里读到主副本或辅助副本上执行事务日志备份会将两个副本的事务日志标记为可重用。无论如何,事务日志备份大小很大,可以使用收缩文件来减少:

在此处输入图片说明

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

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


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


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

Rem*_*anu 21

在 AG 中,写入只能发生在主节点上。收缩操作是写操作。因此,您必须在主服务器上进行收缩。请注意,收缩可能不会像您预期的那样收缩,您对还原的数据库的测试可能利用了简单的恢复模型。阅读如何缩小 SQL Server 日志以获取更多信息。

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


Den*_* P. 7

你可以试试:

  1. 可用性组中所有服务器上的数据库应处于同步状态。
  2. 将使用过的页面移到事务日志的开头,然后再缩小它。
  3. 有时日志的可用可用空间为 99%,但 SQL Server 无法释放未使用的空间。尝试依次重新启动可用性组中的每个服务器。
  4. 有时您需要在 MS SQL Server 释放可用空间之前备份和收缩事务日志 2 次(无法收缩日志文件 (DB_Log),因为位于文件末尾的逻辑日志文件正在使用中。)。

试试这个脚本:

    --在作业步骤或脚本中设置当前数据库
    --检查只在主节点上执行
    如果(选择角色
        FROM sys.dm_hadr_availability_replica_states AS a
        加入 sys.availability_replicas AS b
            ON b.replica_id = a.replica_id
    WHERE b.replica_server_name = @@SERVERNAME) = 1
    开始
        -- 使用 [test_db] -- 不适用于 MS SQL 2014,只需注释此行并在作业步骤或脚本中设置当前数据库
        -- 1) Bakup Trn
        BACKUP LOG [test_db] TO DISK = N'D:\MSSQL\Backup\test_db.trn' WITH NOFORMAT, INIT, NAME = N' Trn Backup', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 10
        -- 2) 移动使用过的页面
        DBCC SHRINKFILE (N'test_db_log', 3000, NOTRUNCATE)
        -- 3) 收缩文件日志
        DBCC SHRINKFILE (N'test_db_log', 3000)
    结尾