服务器在新硬件上使用数据库镜像来实现运行SQL Server标准的高可用性。
现有的计划是由DBA多年前设置的，并且正在使用UI中提供的内置维护工具。
每日：所有数据库的完全备份每15分钟对用户数据库执行事务日志备份检查包括索引在内的所有数据库的数据库完整性清理历史清理备份
每周：重组所有数据库上的索引 – 包括表和视图以及紧凑的大对象更新所有数据库的统计信息 – 包括表和视图，使用全面扫描更新所有现有的统计信息
在重组任务约1小时后的星期天早上，服务器变得没有响应，我必须停止SQL服务来启动故障转移到镜像服务器。 我认为重新组织或更新统计信息是导致问题。 想知道如果我应该做紧凑的例程和/或在每个表（系统和用户）上运行重组。
我如何修改我的任务来减轻服务器上的压力，但仍然执行适当的维护？
你没有提到你正在使用的维护，但是…
通常不需要重新组织所有数据库上的索引。 其中一些将需要它，有些则不需要。 你也许可以切换到Ola Hallengren的脚本 ，这些脚本会检查索引是否需要它。 我会推荐类似的东西。
你可能也想考虑在环境中改变了什么（如果有的话）。 你有更多的数据库比你几年前？ 有没有什么事情使索赔工作变得更加痛苦，还是总是这样，你只是在你接pipe时才注意到？