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…
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 Live Class Season Pass, Live Class Season Pass PLUS Lab VM or Mastering Server Tuning with Wait Stats, or log in if you already shelled out the cash.
- 0.1 Prerequisites Before the Class (59 min)
- 0.2 How to Set Up Your Own Lab Server
- 1.2 How to Measure Your SQL Server
- 1.3 How to Fix PAGEIOLATCH Waits
- 1.4 Lab 1: Fixing PAGEIOLATCH Waits
- 1.5 CPU Waits: SOS_SCHEDULER_YIELD
- 1.6 CXPACKET, CXCONSUMER, and LATCH_EX Waits
- 1.7 Lab 2: CPU-Intensive Workload
- 2.1 Abnormal Parallelism
- 2.3 Lab 3: Planning the Work
- 2.4 Solving Waits with Readable Replicas and RCSI
- 2.5 Lab 4: Mixed Workload
- 3.1 Poison Wait: THREADPOOL
- 3.2 Poison Wait: RESOURCE_SEMAPHORE
- 3.3 Hardware Waits: WRITELOG, HADR_SYNC_COMMIT, ASYNC_NETWORK_IO
- 3.4 Lab 5: Architecture Changes
- 3.5 How to Triage Performance Emergencies
- 3.6 Lab 6: Emergency Triage
- Bonus: Server Hardware Sizing
- Bonus: Storytelling Time