由于 SQL 转储文件，SQL 服务器日志文件夹正在扩展（如何处理？）

Question

SQL 服务器根目录 (X:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Log) 中的“日志”文件夹 SIZE 变得太大，约 80 GB。

当我查看时，我看到该文件夹​​中有很多 SQLDumpxxxx.mdmp /SQLDumpxxxx.txt 文件。

1. 怎么办？
2. 我可以删除它们吗？如果这样做有好处吗？

10倍

Answer 1

首先，Shanky 在他的回答中所说的一切都是 100% 正确的。我想补充：

1. 文件的年龄 - 如果您的日志文件夹有几个两年前的转储，然后几个月没有转储，然后是最近的几个转储，您可以安全地删除两年前的转储。

2. 重复转储 - 发生转储时会创建三个文件：.txt、.log 和 .mdmp。打开多个转储的 .txt 文件。如果它们不同，请保留转储。如果它们相同，请删除旧的。

3. 您的可用磁盘空间 - 如果您的转储所在的磁盘也是您的数据库文件或事务日志文件所在的磁盘，并且如果您不做任何事情，您将耗尽磁盘空间，并且您有没有将转储文件移动到的位置，然后一定要删除它们。

4. 转储类型 - 如果 .log 文件指示“Non-yielding Scheduler”、“Non-yielding IOCP Listener”或“Non-yielding Resource Monitor”，则这些是特定于 CPU 的性能。您可以按照此博客中的步骤进行故障排除：https : //blogs.msdn.microsoft.com/karthick_pk/2012/08/21/non-yielding-iocp-listener-non-yielding-scheduler-and-non-yelding -resource-monitor-known-issues-and-fixes/

如果 .log 文件指示“Deadlocked Schedulers”，这也是特定于 CPU 的性能。您可以按照此博客中的步骤进行故障排除：https : //blogs.msdn.microsoft.com/karthick_pk/2010/06/22/how-to-analyze-deadlocked-schedulers-dumps/

5. Corruption Dumps - 正如第一个答案所述，运行 DBCC CHECKDB。如果 DBCC CHECKDB 的输出表明您的索引损坏，请重建它们。如果它表明修复数据库所需的“修复允许数据丢失最少”，则从上次已知的良好备份恢复。

6. AV Dumps - 您可以尝试自己解决这个问题：https : //blogs.msdn.microsoft.com/sqlcat/2009/09/11/looking-deeper-into-sql-server-using-minidumps/
   如果遇到困难，向 Microsoft 开一个案例，但正如 Shanky 所说，确保您使用的是受支持的版本并且您拥有最新的更新。

Answer 2

对我来说，它是 SQL Server 2019 Developer Edition 的 Polybase 服务，该服务无法启动，因为 TCP/IP 协议被禁用（默认情况下），并且每天多次创建大型内存转储。

这是一篇非常好的文章，其中包含解决此问题的分步说明。

https://nielsberglund.com/2019/11/20/fix-polybase-in-sql-server-2019-developers-edition/

上述文章的主要摘录是

1. 启用 TCP/IP 作为 SQL Server 的网络协议。可以使用 SQL Server 配置管理器启用网络协议。通过 Windows 开始菜单或计算机管理器打开 SQL Server 配置管理器
2. 重新启动 SQL Server 服务
3. 如果无法重新启动 SQL Server 服务，请从命令提示符（以管理员身份）使用进程 ID 使用“taskkill”命令终止服务进程。例如taskkill /PID {process id} /F
4. 启动 SQL Server 服务

Answer 3

您应该分析并确定堆栈转储的原因，如果您有微软的支持，您可以咨询它们，当然您可以随时删除它们，它们只不过是内存转储，可能是由于内存问题、访问冲突而生成的， DB损坏等。您还可以检查SQL Server错误日志以获取在生成转储时同时记录的信息或错误。有时由于数据库损坏也会生成转储，因此我还会建议运行 DBCC CHECKDB。

希望这对您有帮助，谢谢。