Building execution plans is hard: picking the right indexes, seeks vs sorts, row estimations, memory grant requirements, it’s all a lot of work. SQL Server tries to cache execution plans for reuse later, which should result in lower CPU, more memory, and easier troubleshooting. Unfortunately, sometimes it goes wrong. Let’s talk about how it goes...
To access this incredible, amazing content, you gotta get Mastering Server Tuning with Wait Stats or Recorded Class Season Pass, or log in if you already shelled out the cash.
- 0.1 Prerequisites Before the Class
- 0.2 Download the Slides and Scripts
- 1.1 How to Measure Your SQL Server
- 1.2 How to Fix PAGEIOLATCH Waits
- 1.3 Lab 1: Fixing PAGEIOLATCH Waits
- 1.4 How to Fix CPU Waits (SOS_SCHEDULER_YIELD)
- 1.5 Lab 2: CPU-Intensive Workload
- 2.1 How to Fix Parallelism Waits (CXPACKET, CXCONSUMER, and LATCH_EX)
- 2.3 Lab 3: Mixed Workload
- 2.4 How to Fix Blocking Waits (LCK%)
- 2.5 Lab 4 Setup: Planning the Work
- 3.1 How to Fix Worker Thread Waits (THREADPOOL)
- 3.2 How to Fix Query Memory Waits (RESOURCE_SEMAPHORE)
- 3.3 How to Fix Hardware-Sounding Waits (WRITELOG, HADR_SYNC_COMMIT, ASYNC_NETWORK_IO)
- 3.4 Lab 5 Setup: Architecture Changes
- 3.5 How to Triage Performance Emergencies
- 3.6 Lab 6 Setup: Emergency Triage
- Bonus: Abnormal Parallelism
- Bonus: Storytelling Time