我在生产服务器上有几个数百 GB 的数据库，每天都有成千上万的事务通过它们运行。
几乎所有这些数据库都使用 SQL Server 镜像进行镜像。
尽管我们已经仔细规划了物理日志文件大小以匹配预期的日志文件活动；偶尔会出现问题，日志需要增长到超出我们预测的最大值。我们已将所有日志文件设置为增长 8192MB，但是当数据库面临增长日志文件的压力时，它有时只会以非常小的块增长日志，从而在某些情况下创建数十万个虚拟日志文件 (VLF) .
当我们的一个生产数据库意外恢复超过 200,000 个 VLF 时，我开始理解保持低 VLF 数量的重要性。恢复需要 20 多个小时；在此期间，我们的部分业务无法运营。
我需要一个可以监控服务器上所有数据库的虚拟日志文件数量的解决方案，如果任何特定日志文件的 VLF 数量超过给定数量，则发送警报电子邮件。
我知道DBCC LOGINFO;返回 VLF 列表，但是，我不想手动运行它。
我创建了以下 SQL 语句，该语句创建了一个列出数据库以及 VLF 数量的漂亮表，但是，我不知道如何将其放入 SQL 代理作业中，以便在任何数据库的数量超过“x”时向我们的团队发送电子邮件的 VLF。
DECLARE @cmd_per_database_prefix nvarchar(max);
DECLARE @cmd_per_database nvarchar(max);
DECLARE @database_name nvarchar(255);
SET @cmd_per_database = '';
SET @cmd_per_database_prefix =
'
SET NOCOUNT ON;
DECLARE @vlf_count_table TABLE (database_name nvarchar(255), vlf_count int);
DECLARE @params nvarchar(max);
DECLARE @db_name nvarchar(255);
DECLARE @vlf_count int;
SET @params = ''@db_name nvarchar(255) OUTPUT, @vlf_count …我是一个偶然的 DBA，需要帮助确定有关多个数据库上的事务日志文件的操作过程。我运行 Brent Ozar 的 sp_blitz 以查看 SQL Server 2012 实例上可能存在哪些问题，我看到的其中一件事是比数据文件大的事务日志文件。在一个数据库上，数据文件为 3.33 GB，日志为 5.19 GB。其他人的比例大致相同。
此方案的说明表明可能需要收缩日志文件，但前提是数据库处于完全恢复模式。此数据库设置为简单恢复。
我应该缩小日志文件还是只留下它们？
谢谢你的时间。
这是在 SSC 交叉发布的，但现在恢复需要 6 个小时。
你好，
一夜之间，我使用 NORECOVERY 对 5tb 数据库以及其他几个 250GB - 1.3tb 数据库进行了恢复。我这样做是因为有时我们的 3rd 方备份软件会在认为某些内容超时而实际上没有超时时抛出古怪的 LSN 错误。无论如何，恢复完成没有错误。今天早上，我开始运行 RESTORE WITH RECOVERY 命令，使它们联机以进行 DBCC 检查。
在第一个数据库上运行良好，在 5tb 数据库上卡住了大约一个小时，然后我在其余六个数据库上与 5tb 并行运行命令。他们都恢复得很快。5tb 的数据库现在已经恢复了大约 3 个小时。
任何想法：
为什么这会比两者都花费更长的时间：
a) 恢复通常需要多长时间，以及 b) 比其他数据库恢复所需的时间长得多？
如果我应该取消/终止交易并尝试重新开始
我可以看到它在 sp_WhoIsActive 中做了一些事情，即信息列正在增加，等待信息发生变化（尽管它似乎总是处于等待状态是 IO_COMPLETION），但状态似乎总是被挂起。
在研究时，我发现一篇文章表明高 VLF 计数可能导致此问题，并且日志文件中大约有 5k VLF，但我使用的是 2012 版本，已针对该问题进行了修补：
Microsoft SQL Server 2012 - 11.0.5532.0 (X64) 2014 年 7 月 14 日 15:00:27 版权所有 (c) Microsoft Corporation Developer Edition（64 位）在 Windows NT 6.3（Build 9600：）（Hypervisor）上
谢谢
编辑：
这是在我用于卸载 DBCC …