(NON-SERIOUS) The Not So Pro Guide to SQL Server Wait Statistics
The following guide to SQL Server wait statistics (as seen in the sys.dm_os_wait_stats DMV) is complete jibberish. It should not be taken seriously under any circumstances and if followed on a production environment don't mention my name. In fact blame Derek.
Please!! DO NOT DO any of this, it's a joke (it's barely that to be fair).
Asynchronously blame the network and storage teams for not upping their game.
Attempt to pronounce parallellellellellism correctly then set MAXDOP to 1.
Mention TempDB and contention in the same sentence. Delete TempDB
Delete any long running backup jobs. If wait persists then delete all backup jobs.
Point menacingly at storage team, shout IO and YOUR FAULT a lot. Double server RAM when nobody is looking and set SQL Server Max Memory to 2147483647.
Well documented issue that is only truly resolved by adding NOLOCK to all queries. Often a less seasoned SQL Server professional will try to advise that this is bad practice. Smile politely, tell them they're too pessimistic and ignore them. Send an email welcoming all stakeholders to the turbo times.
Upgrade all currently implemented HADR solutions to use merge replication instead.
Databases are way too big, shrink them. Occasionally databases won't shrink, this is a known issue that can be resolved by removing all indexes.
See HADR_ wait
It's not a wait type, it's a movement.
Someone has set the OLE database to single user mode or in business critical conditions the OLE database does not exist and urgently requires adding to the instance.
Very common wait type indicating that available CPU resource is laughable. Immediately quadruple the current amount of CPU's. If using enterprise edition then double again to maximise gains.
Non valid wait. Your stored procedures are so awesome they've been awarded XP points.
Install Welsh language pack.
Clearly it's the QDS host, innit.
Widely considered as the too much hassle wait. Tell anyone that asks that you recently read online that memory grants are particularly slow at this time of year and it should pick up in the summer when you migrate to the cloud.
Well documented bug in SQL Server 2017; install SP1.
Check max worker threads for default value of 0 (no wonder they're running out), set to 1.
Locate whoever is testing in production and tell them to stop, unless it's cursors.
Set all databases to simple recovery. Stop SQL Server and delete all transaction log files as you don't them anymore.
AKA the wakey wakey wait, schedule a restart of SQL Server during the next team meeting.