I was looking at a SQL Server which had generated ten(10) SQLDump####.txt files but only a single(1) SQLDump####.mdmp file. We introduced a new feature in SQL Server 2019 to save disk space for mini/crash dumps which can skip the suspension and capture for identical dump signatures, saving disk space and reducing the impact on the SQL Server instance.
- Each time the SQL Server instance is started a hash table is created to track crash dump signatures.
- The first time a crash dump signature is encountered a SQLDump####.mdmp is created and the signature is stored in the hash table.
- The decision to create a mini-dump performs a hash table lookup using the crash signature. When the signature is present the second, third, … mini-dumps are skipped.
The SQLDump####.txt file is generated with limited information and then an entry is logged in the SQL Server error log to indicate the mini-dump is being skipped.
The SQL Server error log will contain the basic crash information such as the following.
2019-11-02 04:35:08.05 spid105s ***Stack Dump being sent to /var/opt/mssql/log/SQLDump0010.txt
2019-11-02 04:35:08.05 spid105s *
2019-11-02 04:35:08.05 spid105s * BEGIN STACK DUMP:
2019-11-02 04:35:08.05 spid105s * 11/02/19 04:35:08 spid 105
2019-11-02 04:35:08.05 spid105s *
2019-11-02 04:35:08.05 spid105s * Location: cmedobj.cpp:7422
2019-11-02 04:35:08.06 spid105s * Expression: HKTIK_Primary !=
tableIdKind || PCXCtxtB()->PXLvlIntCtxt()->FInUpgrade()
2019-11-02 04:35:08.06 spid105s * SPID: 105
2019-11-02 04:35:08.06 spid105s * Process ID: 40
2019-11-02 04:35:08.06 spid105s *
2019-11-02 04:35:08.06 spid105s * MODULE BASE END SIZE
2019-11-02 04:35:08.06 spid105s * sqlservr 0000001080240000 00000010802DDFFF 0009e000
….
2019-11-02 04:35:08.17 spid105s *
2019-11-02 04:35:08.17 spid105s * P1Home: 0000000100000010: 2019-11-02 04:35:08.17 spid105s * P2Home: 000000006BF543C3:
…
2019-11-02 04:35:08.20 spid105s * Short Stack Dump
2019-11-02 04:35:08.22 spid105s 0000001082B202B8 Module(KERNELBASE+00000000000402B8)
2019-11-02 04:35:08.22 spid105s 00000010871ED93E Module(sqllang+0000000000F7D93E)
2019-11-02 04:35:08.22 spid105s 00000010871F18CA Module(sqllang+0000000000F818CA)
…
At the end of the crash information the dump signature is logged.
2019-11-02 04:35:08.31 spid105s Stack Signature for the dump is 0x0000000198EAD992
If the signature has already generated a mini-dump a message is logged indicating dismissal of the attempt.
2019-11-05 16:03:05.32 spid29s Dump request is dismissed (stack signature 0x0000000198EAD992).
Using the signature logged in the message you are able to locate the initial SQLDump####.mdmp for further troubleshooting.
For troubleshooting be sure to keep all the error logs and SQLDump* files generated from the time the SQL Server instance starts until it stops. The group of files represents the lifetime of the hash table and dump generation captures.
Skipping the mini-dump reduces the disk space as no SQLDump####.mdmp is saved. Skipping also has the benefit of avoiding the dbghelp thread suspension activities used to capture a dump. Without suspend activities the impact on the SQL Server process is reduced.
DISABLE BEHAVIOR
You can disable the behavior by enabling trace flag (2553) and force the dump to be captured for each occurrence.
Dynamically: dbcc traceon(2553,-1)
Server startup parameter: -T2553
– Bob Dorr
How It Works DumpsSQL Server 2019
