You’re the DBA, the guy in charge, the guy who gets pounced on first thing in the morning with complaints of “my report took FOREVER to run last night, why?”, or “customers are saying the web site was really slow at 3:00am this morning, why?”. You’re expected to be able to answer questions like that. Can you? Do you know what your servers are doing when you’re not looking?

1. What Are Your Servers Doing While
You’re Sleeping?

2. Tracy McKibben
Principal Data Architect
Pearson VUE
Blog: realsqlguy.com
Twitter: @RealSQLGuy
I’m not saying I’m Batman, I’m just saying that nobody has
ever seen me and Batman in the same room together...

3. Good Morning, DBA!

4. Why Is SQL Server Slow Right Now?
• sp_who2 – shows current connections and running
processes
• DMVs – active processes, cached query plans, wait
stats
• Management Studio standard reports – based on
current DMVs
• Profiler – shows SQL activity in real-time
• Perfmon – shows server load/stats in real-time

5. Why Was SQL Server Slow At 3:00am?
• sp_who2 – only shows current activity
• DMVs – may or may not include past activity, difficult
to look at a specific point in time
• Management Studio standard reports – no time-
specific “history” reports
• Profiler – only shows current activity, unless running
continuously
• Perfmon – only shows current activity, unless running
continuously

6. Collect and Save Wait Stats
• Save at recurring intervals
• Save deltas between each interval (reset wait stats
each time, or compute delta vs previous save)
• Persist saved data in permanent tables
• Purge old data (determine an appropriate time for
your needs)
• Use my scripts http://realsqlguy.com/tools/collectors

7. Collect and Save Active Processes
• Save at recurring intervals
• Use sp_whoisactive to save process info, including
query plan and query text
• Persist saved data in permanent tables
• Purge old data (determine an appropriate time for
your needs)
• Use my scripts http://realsqlguy.com/tools/collectors

8. Collectors In Action
• Identify long-running queries
• Identify TEMPDB abusers
• Identify blocking problems
• Identify missing indexes
• Identify poorly written applications
• What else can we see?

9. Identify Long-Running Queries
• Long-running queries are often the first sign
of a problem.
• What does “long-running” mean in your
environment?
• A long-running query can indicate blocking, a
missing index, I/O problems, network
problems, application problems, and more.
• Inspect the query plan, the waits collected,
blocking sessions, TEMPDB utilization, CPU,
reads, writes, etc.

10. Identify TEMPDB Abusers
• Multi-step “procedural” operations that
explicitly create temp tables or table
variables
• Poorly written queries that perform large
grouping, sort, or aggregate operations
• Large hash operations
• Look for tuning opportunities, missing
indexes

11. Identify Blocking Problems
• Blocking is one process holding a lock that
prevents another process from running
• Poorly written queries can lead to extensive
or excessive locking, preventing other
queries from running, affecting overall
performance
• Severe blocking can affect system stability
• Look for tuning opportunities, missing
indexes

12. Identify Missing Indexes
Missing or insufficient indexes can lead to a
variety of performance problems:
• Table or index scans (not always a bad thing)
• Expensive key/row/bookmark lookups
• Extended or extensive locking

13. Identify Poorly Written Applications
• Excessive ASYNC_NETWORK_IO waits often
point to poorly written applications
• Row-by-row processing or excessively large
resultsets
• Common with development frameworks like
nHibernate
• Consume data as sets, not row-by-row, keep
resultsets as small as possible.

14. Summary
• Wait stats tell you where SQL Server is
hurting
• Active processes tell you what is contributing
to the hurt
• Determine the appropriate collection
intervals for your system(s)
• Analyze the collected data to proactively look
for problems.

15. The End
Any questions?