"The server was slow yesterday" gives support almost nothing to investigate. A useful support case starts with a timeline and the evidence captured while the problem is still happening.
Pin Down the Symptom Before the Support Case
Write the start and end time with time zone, affected databases or applications, user impact, and whether the issue is still active. Note the last known good period and recent deployments, failovers, patching, or configuration changes. I ask for one concrete failing request or error before collecting a mountain of logs. If the problem is intermittent, record each occurrence. A timeline lets support align traces and system events rather than guessing which Tuesday someone meant.
Avoid inventing an explanation at this stage. "CPU was high" is an observation if a captured metric supports it. "The storage caused it" is a hypothesis until file latency and workload reads are checked. Keep both in the case, but label them differently.
Capture the Exact Build
SERVERPROPERTY returns product version, level, edition, and other build details. Include the full version string and installed CU, not only a label such as SQL Server 2022. Check database compatibility level and relevant configuration when the symptom is query-specific. I run the query on the affected instance, not on the jump host's default connection. The wrong server name is a surprisingly effective way to spend a support call.
SELECT @@SERVERNAME AS server_name,
SERVERPROPERTY('ProductVersion') AS product_version,
SERVERPROPERTY('ProductLevel') AS product_level,
SERVERPROPERTY('Edition') AS edition,
SERVERPROPERTY('ProductUpdateLevel') AS update_level;
SELECT name, compatibility_level, state_desc
FROM sys.databases
ORDER BY name;Preserve Logs and Health Files
Copy SQL Server error logs covering the period, including archived files. Record corresponding Windows event logs when host or service behavior matters. The system_health Extended Events session can contain deadlocks and other useful events. Identify its event file location and preserve the relevant files before rollover. Do not attach every log on the server without review; give support a time-bounded package and say what is included. I keep original copies untouched and work from copies for analysis or redaction.
SELECT s.name AS session_name, f.name AS field_name, f.value
FROM sys.server_event_sessions AS s
JOIN sys.server_event_session_targets AS t
ON t.event_session_id = s.event_session_id
JOIN sys.server_event_session_fields AS f
ON f.event_session_id = s.event_session_id
AND f.object_id = t.target_id
WHERE s.name = N'system_health' AND t.name = N'event_file';
SELECT SERVERPROPERTY('ErrorLogFileName') AS error_log_file;On my default instance the filename field held only system_health.xel, with no folder. A bare name like that means the files sit in the same Log folder as the ERRORLOG path from the second query.
Handle Dumps as Sensitive Evidence
Memory dumps and diagnostic files can contain query text, literals, credentials, and application data. Record their paths, creation times, and size, but do not post them to a public forum. Use the approved secure upload process for a support case. I ask incident or privacy owners to review the transfer when the data classification requires it. Preserve a hash and the original file if chain of custody matters. Do not rename or edit a dump to make it look smaller; use support's guidance for collection and upload.
If there is no dump, say so. Support can then request targeted capture if needed. A blank attachment list is less useful than an explicit note that the evidence was checked and absent.
Capture the Problem While It Happens
SQL LogScout gathers a structured diagnostic package for SQL Server issues. Run its scenario that matches the symptom while the problem is active, following your organization's approved tool procedure. Review its collection settings and output before transfer. For query slowness, include the actual query, plan, waits, blocking context, and Query Store interval where available. A capture taken hours after recovery documents a healthy server, which is useful as a baseline but not as a substitute for the failing interval.
What would another DBA need to reproduce the issue? Include parameter values only after checking whether they contain private data. A sanitized reproduction with the same data shape is better than real customer text pasted into a case.
Build a Reproduction Package for the Support Case
If the issue can be reproduced, give support a minimal set of steps with expected and actual outcomes. Include database compatibility level, session SET options, parameter types, and a sanitized schema or query. A performance problem can disappear when the parameter type changes or statistics differ. I separate the production evidence package from a small reproduction script. The first shows what happened; the second gives support a safe way to investigate. Do not copy real customer rows into a sample database because they make a query easier to reproduce.
For a crash or hang, state whether a reproduction is safe. A command that regularly takes down a server belongs in a controlled lab, not in a support reply telling someone to "try this" on production. Record the exact conditions already observed and wait for an agreed test window.
Keep the Support Case Moving
Assign one technical owner to answer support questions and update the timeline. When a new diagnostic request arrives, check whether it overlaps evidence already collected. I log each upload with filename, time range, collection method, redaction status, and who approved sharing it. That prevents contradictory copies from circulating. If the symptom recurs, append the new timestamp and capture rather than replacing the original history.
What would count as resolution? Define a measurable user outcome, such as no recurrence under the same workload and a corrected error path, then verify it after the fix. A support suggestion is a hypothesis until tested. I keep the case notes focused on observed facts, commands run, and results. That makes a handoff possible if the original DBA is off duty when support responds.
Use a small attachment index in the case description. List each log or trace with its time range and the question it answers. That helps support request only missing evidence and prevents another upload of the same large file. I keep the raw copy internally and send the approved redacted copy, then verify the exact attachment opened on the case.
Redact Without Erasing the Clue
Review filenames, server names, login names, query literals, and plan XML before sending. Support sometimes needs a real object name or value to map evidence, so coordinate redaction rather than replacing everything blindly. Keep a mapping locally and explain each substitution. I make the exact attachment set explicit in the case notes. This prevents a second upload from quietly adding a raw file that undoes the first review.
Send a short case summary with the symptom, timeline, build, impact, reproduction, recent changes, and attachment index. Support can ask sharper questions when those facts arrive together. The first reply should move the investigation forward, not request the server version you already knew.
Related reading on this blog: Microsoft Official Support End Dates for Different Versions and Too Many SQLDump Files Consuming a Lot of Disk Space. What Should You Do?.
A support case is not a symptom sentence, it is a reproducible trail of evidence.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
