Wait statistic are a fundamental concept of any RDBMS. Let’s review some basics of troubleshooting performance issues with wait statistics.Read More »
NOTE: this article is the summary of a 3 part series on optimizing SQL Server configurations along with Windows Server and VMware. Please read these first then return to read the rest.
- Part 1: SQL Server Environmental Diagnostics Guide
- Part 2: SQL Server Environmental Diagnostics Guide – Windows Server
- Part 3: SQL Server Environmental Diagnostics Guide – VMware
NOTE: this deals only with Windows Server. I know that Linux is now recently an option but this article will deal only with Windows Server.
This is part 2 of a 3 part series about SQL Server Environmental Diagnostics. Part 1 can be read here.
Performance problems for a SQL Server based application are likely to be caused by environmental factors and not buggy code.
Whether it is a configuration you can change in SQL Server, Windows Server, VMware, or the network it is likely the first course of action is to perform a quick assessment of the environment. This is where understanding the various configurations and best practices are key. Knowing what to look for can save tons of time.
A mistake I often see is a performance issue is passed off to someone else (more senior) and that engineer assumes a lot of things without checking. People are going to relay the problem as they see it – not as it actually is. This leads to skipping over some elementary checks which can save time and frustration from tracking down imaginary bugs.
Start troubleshooting with a quick environmental check.
Below are common environmental mishaps I see when troubleshooting SQL Server performance complaints. Consider these 1st line of action before getting into execution plans, statistics, indexing, and code refactoring.