I just went through that over the weekend and yesterday.

First, the over the weekend thing was because a card in a network switch started to go bad. They replaced that. It fixed most of the systems that were experiencing the slowdown but one. It took our good folks in NetOps a bit to figure it out but they found that a cable was "broken". It appears to have had a bad connector that was just waiting for someone to touch it. They had to pull the cable (and all the others) to remove the switch to replace the card. There was no external sign that the connector failed internally but the transfer rates plummeted to 0.043MB per second.

In the past, we also had folks that thought it would be a good idea to do multi-file backups. Doesn't work well unless you can control which spindles each file is going to use. With today's SAN setups, that's nearly impossible and the headthrashing between two files causes things to run much slower.

We also had folks that messed with backup buffer and packet sizes. We found the "sweet spot" for that for our particular system but they originally used "rote settings" from some article and never checked to see what the impact was.

I've also seen switch settings changes really mess things up. Having a switch change from FULL DUPLEX to single will cause things to run twice as slow in a lot of cases. Setting NICs and switches/routers to AUTO NEGOTIATE can cause similar problems.

Some of the tools already mentioned can help you track these things down but, just because such a tool doesn't find something like I've mentioned, doesn't mean that such a problem doesn't exist... especially the slowly-going-bad card that acts up only when it gets heated up or the intermittent cable that will handle single requests just fine but not a stream of data.

And then there's the addition of jobs or someone running something new. It doesn't even have to be on the SQL Server itself. We had a Web Server go bonkers and start sending a bazillion requests that flooded the proverbial pipe. It was almost like a denial of service attack. It was just some bad code that someone promoted.

I've also seen things like Windows updates mess things up and need to be rolled back or someone do an update to virus protection and the exclusions for SQL Server files were overridden.

Last but not least, I've also seen well-meaning people set the clock frequency on the server to be automatic to "save energy". That doesn't work so well with SQL Server.

"Fun" stuff. I wish you luck.