我在一家拥有 20 个全职网站的小公司工作。以及另外 20-30 个微型站点。在 SQL Server 代理备份运行后，我们每天都遇到站点冻结的问题。当备份服务停止时，我们看不到任何问题。这是常见的吗？
我们使用的是 SQL Server 2005，并且备份在星期日和星期三运行。我还将研究数据库本身中的其他内容，但这是突出的内容。
- 编辑 - 我在 5/27 到 5/31 的机器上运行了 3 天的性能：
SQLServer:SQL Statistics\Batch Requests/sec Average 355.412275 Median 306.610812 Min 108.9369962 Max 916.6332837 Std Deviation 141.7791552
SQLServer:General Statistics\User Connections Average 83.14025501 Median 77 Min 52 Max 147 Std Deviation 19.27016231
SQLServer:Buffer Manager\Page life expectancy Average 33.72386157 Median 21 Min 0 Max 246 Std Deviation 36.53737617
看起来运行的维护备份在运行时不会引起问题。它在凌晨 3 点以及周日和周三运行，并在大约 2 小时内成功完成。我运行了 SQL Server 配置文件：
我发现其中一个定期运行的 sp 需要很长时间才能执行。
大多数情况下 Duration 为 976（微秒），但有时差异很大：13922851 …
我们有一台 SQL Server 2005 服务器，它为 20 个网站提供服务，其中一个是我们的自定义 CMS，还有一些其他微型网站。我是新手，刚开始在这里查看数据库。
问题是我们遇到了 SQL Server 在几天后变慢的问题，这导致我们重新启动服务。我用 SQL Profiler 做了一些统计，但经过审查后，我没有看到任何突出的东西。这就是我现在在这里的原因。我在网上环顾四周，发现了 ASYNC_NETWORK_IO。所以，我现在正在尝试遵循这条轨道。
这就是我所做的：
我清除了等待统计表。
DBCC SQLPERF ('sys.dm_os_wait_stats', 'CLEAR')
最后 15 分钟的结果：
ASYNC_NETWORK_IO 46798 34953 812 1953
CMEMTHREAD 28300 42328 1187 6437
CXPACKET 361571 7048515 38984 48859
从我所读到的 ASYNC_NETWORK_IO 与等待客户端应用程序的 SQL 有关。
2个问题：
1）我的假设是否正确，这些数字在 15 分钟的监控中似乎很高？
2）我从这里去哪里？我的下一步应该是什么？
我正在努力学习这些东西是如何工作的，我明白这是我将不得不继续深入研究的东西。
朝着正确的方向推动会很棒。