Looking for a way to address SQL Server database performance in a production, virtualized environment? There are many sources of expert advice from very smart people in the SQL Server world. But often the most well-thought, well-intentioned advice is not easily or quickly implemented in a complex organization. The reasons could be technical, political or simply availability of time and people.
This diagram is my current approach to "rough" tuning a SQL Server: The idea that a server administrator or database administrator (DBA) can turn various knobs and flip switches to assigned scarce resources to a database server, but as a practical matter, the inner workings of a given application and database may not be changed… or at least not changed quickly.
Example situations:
- A third party vendor application with a proprietary schema, the application might have updates, but there are dependencies or license costs that take time.
- An internal application has received an influx of new activity, but the development team is fully off on another high-priority project
- A legacy application with original developers long gone; no known test environment to experiment
Method
Took some best practices, including some selections from the guidance on the SQL Server perfmon counters of interest poster available from Dell/Quest, and added some of the basic steps available to Server administrators and Database Administrators.
Document available as a PDF
