数据库大小 - 145GB
目前我们的数据库 mdf 文件 tempdb 备份在 D 盘，日志文件在 C 盘。
我们可以进行以下配置：
或者
我们有 26 台具有完全恢复模式的服务器，可为我们的客户提供 24/7 全天候工作。以及 100 多个对于其他具有仅适用于 9 到 6 的简单恢复模型的客户端。
目前，我们只有 4 个硬盘驱动器可以分配这种配置 C、D：镜像 (RAID 1) 和 E。我们可以将我们的数据库所有文件都放在这种配置中还是避免 RAID 1？
由于数据库完整性、重建/重组、备份和删除旧文件等维护任务的运行，前端应用程序在白天经常崩溃，而在夜间则无法访问。
有人可以帮我找到最合适的方法吗？
我们有一个合并复制环境，其中包括
Publisher：Server1，其中只有一个 125 GB 的复制数据库和 Distributor 也配置在 HyperV 环境中托管的同一服务器上。
订阅者：我们有大约 280 台带有 Distributor（推送订阅）配置的服务器。
注意：我们的环境每天都会发生大量 DML 更改，因此我们每天通过维护和备份作业对每台服务器执行许多检查，其中包括步骤 1：检查完整数据库的完整性步骤 2：重建/重组索引步骤 3：备份/验证step4：清理旧备份作业 step5：清理旧作业历史记录
此外，这项工作每天在 4-5 小时内完成，但有时会因服务器而异。
快照代理每天早上 00:05 运行
问题：
从周日晚上开始，我们遇到了这个问题，备份和维护工作一直运行到早上，并且大多数服务器工作都卡在 step1 dbcc checkdb ('my database') 上（并且客户也抱怨应用程序崩溃，不能登录，很慢）
检查后，我的备份 spid 正在等待 OLEDB 等待类型，我们没有在发布者和其他订阅者上配置链接服务器连接，除了少数是我们的总部服务器，我们从那里进行主要导入/小更新/如果我们需要推送出任何数据库更改。
在检查下面的查询时，我可以看到我的 dbcc spid id 的百分比正在移动，但并没有真正告诉我为什么它卡在这一步？
select session_id
, percent_complete
from sys.dm_exec_requests
where percent_complete > 0
我在什么时候运行这项工作或单步运行（即 dbcc checkdb）并不重要，它没有完成。
另请咨询我们的 Windows 团队，周末没有推出更新，也没有在应用程序方面进行任何更改。
关于可能是什么问题的任何建议？