I haven’t changed anything, but my SQL Server’s response time has slowed considerably…
I’ve recently dealt with a number of cases/queries from DBAs making the same claim (above). What gives? All of these professionals were certain there was an internal issue plaguing their SQL Server when in fact physical file fragmentation was to blame.
Diagnosing and dealing with fragmented files shouldn’t be a last attempt at resovling a performance bottleneck. Rather, file configuration, growth and maintenance procedures should be an integral part of every DBAs planning and maintenance process. Why is fragmentation a problem? Check out this article from sql-server-performance.com to see how fragmentation occurs and how it affects your SQL Server (if you’ve got Quest’s Performance Analysis for SQL Server 6 this information will be presented to you in context-sensitive performance advisory topics). There are a number of tools in the marketplace (like Diskeeper) that can help, but good old-fashioned T-SQL can help overcome the problem just as well.
Quest offers a number of products that can help identify and deal with fragmentation (and a slew of other Disk I/O related slowdowns). For more information as your sales / support engineers about Spotlight, Performance Analysis and Foglight for SQL Server. This triple-threat of database analysis and tuning products interface with a number of Quest tools and dovetail nicely to take the guesswork out of even the toughest performance problems.