A Pre Call gives a performance-tuning engagement a clear starting point. I want to understand the symptom and what the customer needs.
When I started consulting independently, the basics of engaging with customers stayed familiar. I received requests every day and needed to prioritize them. A short conversation helped me set expectations and prepare for the work.
The opening request is usually, “My server is slow, and I want you to solve it.” I enjoy that challenge. But those words don’t tell me which task is slow or when the problem started.
What I ask before the engagement
- What is slow? Which application, database, user group, or business task is affected?
- When did it first happen, and when did it last work normally?
- How was the problem discovered? What errors or measurements were recorded?
- Is it happening now? Does it follow a time, workload, or month-end pattern?
- What changed in the application, data, maintenance jobs, configuration, network, or hardware?
- Which SQL Server and operating-system versions are involved? Is the server physical or virtual?
- What are the database size, file layout, availability and recovery arrangements, and monitoring tools?
- What fixes have already been tried? Did they help, and for how long?
- Has another consultant or Microsoft Support investigated the issue?
- What outcome does the customer need? Which service requirement defines success?
I also ask who can provide access and who approves changes. Existing query text, plans, error messages, and timestamps help me prepare. Collect only the evidence needed for the agreed investigation.
Agree on the next step
These answers define the scope and identify homework before tuning begins. The customer should understand what I’ll investigate. Thirty minutes describes this pre-call format. It doesn’t promise that every investigation fits that time.
What do you ask before working on a performance problem? Share your questions in the comments. I still learn from the ways other consultants prepare.
Related reading
A pre-call is not the tuning session, it is how we agree on the problem and prepare for it.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
Discover more from SQL Authority with Pinal Dave
Subscribe to get the latest posts sent to your email.
3 Comments. Leave new
Another question I ask to myself is whether the development environment also experiences the same issue?
In the spirit of sharing…
I enjoy reading your post because I am not an SQL-Server expert. The company I work for does have several good DBAs. So I tend to look at the server itself when asked to assist with a database related issue. My questions tend to be about the server configuration and the OS metrics:
• Is this a physical or virtual server;
If physical, how may cores; Intel or AMD;
If virtual, how many logical processors
• What memory is available/defined.
• The SQL-Server makeup:
How many database are hosted
Are activity profiles available.
Have there been new databases added recently.
Which database is/are having a problem.
Has the SQL-Server been recently migrated to a new host server.
• The connecting application(s):
Recent changes;
Is connection pooling used
Etc.
• What is the IO mix: read / write
• What is the storage: local disk, or SAN
• Is the normal database use high IO or high CPU, or both.
I doubt any of this is new to you or of much help, but in the interest of sharing/caring…
Gordon L. Galloway
Consulting Capacity & Performance Eng.
Thank you Gordon,
This is an amazing list of topics. They are very well grouped and thank you for putting them together and sharing it over.