主页 / dba / 问题 / 87112
Accepted
itzik Paz
Asked: 2014-12-29 04:49:03 +0800 CST

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

  • 772

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

当我检查它时，我看到那个文件夹中有很多 SQLDumpxxxx.mdmp /SQLDumpxxxx.txt 文件。

  1. 怎么处理他们？
  2. 我可以删除它们吗？如果这样做是好事？

10X

sql-server

4 个回答

  1. 首先，香基在他的回答中所说的一切都是 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-yielding -resource-monitor-known-issues-and-fixes/

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

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

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

    • 5
  2. Best Answer

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

    希望这会对你有所帮助，谢谢。

    • 4

  3. 对我来说，它是 SQL Server 2019 开发版的 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 服务
    • 4

  4. 方案 1

    我问你关于SQL Server 的版本，你没有回答，我问这个的原因是因为如果你运行的是 RTM 版本的 SQL Server，或者你的 SQL Server 没有修补到最新的 Service Pack 和累积更新，那么打开案例是没有意义的与微软。如果您这样做，Microsoft 工程师或支持人员会首先要求您应用最新的 SP。

    其他情况是，如果您尚未将 SQL Server 更新到最新的 SP，例如，对于 SQL Server 2012，您已经发布了 SP3，但您仍在使用 SP1，并且您为此问题向 Microsoft 记录了一个案例，您将被收取费用，而且很可能支持人员会说这是已知问题，已在 Sp3 中修复。所以你最终会浪费钱。所以我强烈建议您检查 SQL Server 是否在最新的 SP 上。

    我还想检查您是否实际运行受支持的 SQL Server 版本。它创建转储的方式我有预感您正在运行未修补到最新 SP 的 SQL Server

    方案 2

    如果 SQL Server 已修补到最新的 SP，但它仍然在崩溃产生堆栈转储，我建议您向 Microsoft 打开案例，他们在分析堆栈转储文件方面是最好的，并且肯定会告诉您原因。除非你真的很擅长分析转储，否则我不建议你浪费时间这样做。

    我可以与你分享一些博客，它们会给你一些关于如何分析转储的提示

    方案 3

    并非所有故障转储都是由于 SQL Server 中的错误，许多故障是由于 SQL Server 配置不当或运行某些 rouge 查询而发生的。但是由于您没有共享详细的错误日志，因此目前很难说。确保您的 SQL Server 配置正确。如果是这种情况，MS 支持会再次指出这一点。

    道德：

    如果 SQL Server 没有使用最新的 SP 更新，请先更新它，查找 SP 之后发布的累积更新（您可以从我共享的第一个链接中获取）并确保您面临的错误仅在 CU 版本中未修复，然后打开与微软的案例。

    我可以删除它们吗？如果这样做是好事？

    如果您打算与 Microsoft 一起开箱，我建议您将它们移到其他位置以防万一。如果您有这些转储，您可以提供更多信息以支持将查看您的案件的个人。另请注意，生成的转储很可能不会捕获与问题相关的所有信息，支持人员会要求您启用跟踪标志并等待下一次转储发生，该转储将捕获所有相关信息。

    如果您真的想删除它，请删除旧的并保留新的。

    • 3

相关问题