“It’s SQL Server” can mean several things. A query may be taking too long, sessions may be waiting, or the application may be slow for reasons the database evidence has not yet explained. Before your team changes anything, ask the vendor to turn the claim into a specific, testable question.
You do not need to settle the disagreement in the first conversation. You need enough information for the next investigation to be useful.
Start with the operation your team is waiting for
Name the screen, report or transaction. Record how long it takes, how long your team expects it to take and what the delay stops people doing. “The system is slow” leaves too much room for different people to investigate different problems.
An example brief might be: “The daily order report usually finishes before the team starts work. Since last week, it sometimes times out during the morning run.” That is an example of a useful description, not a finding about your environment.
Ask these questions together:
- Which operation is affected, and which SQL Server instance and database does it use?
- When did it happen? Include the date, time and timezone.
- Does it happen every time, at certain times or only for particular inputs?
- What changed around the time it started—application release, workload, data volume, configuration or infrastructure?
- Can your team reproduce it safely in an agreed collection window?
A reproduction must not accidentally duplicate an order, payment or other business transaction. Agree a safe approach with the people who own the application.
Ask for SQL evidence from the same period
The evidence should connect the user-visible delay to relevant database activity. An unrelated busy query or a server screenshot taken hours later is a lead to investigate, not a conclusion.
Ask the vendor which SQL statements, timings and observations support the claim. Ask what was happening when the operation was slow and whether there is a comparable normal period. Microsoft’s troubleshooting method starts with measured query duration and an established baseline, then examines whether time is being spent executing or waiting. Read Microsoft’s slow-query troubleshooting guidance.
Useful questions include:
- How much of the application’s elapsed time is accounted for by the SQL activity you observed?
- Was the query executing, blocked by another session or waiting on a resource?
- Which plan or performance observation relates to this operation?
- Is this evidence a current sample, cached information or retained history?
- What could the collection window or missing history have failed to capture?
Do not treat one counter or wait name as a complete explanation. Ask for the connection between the observation, the affected operation and the proposed next test.
Keep the comparison fair
“It runs quickly in Management Studio” is useful information, but it does not by itself settle why the application is slow. The comparison needs to account for the inputs, connection settings, network path and how the application handles results. Microsoft documents these differences in its application-versus-SSMS troubleshooting guidance.
Ask what was held constant between the two tests and what changed. A different parameter value or a quieter workload can make a comparison answer a different question from the one your team is asking.
Historical evidence can help with an intermittent problem. Query Store can retain query, plan and runtime history where it is supported and appropriately configured, but do not assume it is available or has captured the event you need. Ask your administrator what history exists and which gaps matter. Enabling or changing collection is a separate operational decision. See Microsoft’s Query Store overview.
Ask what the proposed change will test
Before approving more memory, a new index or a configuration change, ask the vendor to explain the expected effect and the evidence behind it. A clear proposal should answer:
- Which observation is the change intended to address?
- What outcome would support the explanation, and what outcome would challenge it?
- How will the team compare results under representative conditions?
- Who will approve, test, implement and reverse the change if needed?
- What remains uncertain even if the test succeeds?
The right next step may be a focused capture, an application investigation or a controlled test. It does not have to be an immediate production change.
Build a brief that both teams can use
Bring the operation, impact, timestamps, recent changes, vendor statement and evidence references into one short brief. Separate observations from interpretations. For example, “the report timed out” is an observation; “storage caused the timeout” needs supporting evidence.
Keep passwords, diagnostic packages, query output and sensitive business records out of a general enquiry. Query text and plans can contain sensitive values. Share a brief description first, then agree what evidence is needed and how it can be handled.
Choose the next investigation
If you need an independent review of one specific vendor claim, Vendor SQL Server Second Opinion is the relevant starting point. If one screen, report or transaction is slow and you need to work out what to investigate next, Slow Application Triage focuses on that operation.
Neither assessment assumes the vendor is wrong or promises a particular diagnosis. The useful outcome is a written conclusion supported by the available evidence, with uncertainty and the next step made clear. Production changes need a separate agreement.
If you are still deciding which question to start with, use the service finder or get a second opinion. Tell us what is happening; you do not need to attach diagnostic evidence to begin the conversation.
This guide is published by BriteThought. Technical references are linked where relevant. Service details and terms govern any engagement; this guide does not change them.
