What Are Your Servers Doing While You’re

Sleeping?

Tracy McKibbenPrincipal Data Architect

Pearson VUE

Blog: realsqlguy.comTwitter: @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...

Good Morning, DBA!

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

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

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

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

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?

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.

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

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

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

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.

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.

The End

Any questions?