我们有一个在wondows 2008R2 O/S 上运行的 sql server 2008 active/active 集群。14GB RAM，4xCPU。我们为 sql server 设置了 12GB 的上限。我们正在运行一个代理作业，该作业将 300 万条记录加载到数据库中。在此加载期间，作业失败，集群似乎尝试故障转移到另一个节点，但没有成功，即集群地址不再可访问。我们必须手动将集群节点故障恢复。
在查看任务管理器的加载过程中，我们可以看到内存使用量最大达到 12.5GB，并且 CPU 有时在所有 4 个 CPU 上都达到 100%，但大多数情况下平均波动在 60% 左右。
我想我的问题是，如果内存或 CPU 受到严重影响，集群是否会尝试故障转移？还是我选错了方向？还有，为什么它不能完全故障转移？我们浏览了大量日志，但找不到任何有用的信息。我们还尝试重新创建该问题，但稍后成功运行。此外，300 万行似乎并不多，但就资源而言，14GB RAM 和 4xCPU 是否不够用？
关于此事的更多信息，我们今天再次运行了负载并破坏了数据库！
我们收到错误消息：LogWriter：操作系统错误 170。看起来，在高负载下，sql 集群尝试故障转移，并迁移了一个 lun（或驱动器），这意味着磁盘不再可访问。（这只是我们的理论）。数据库现在“可疑”并需要恢复。
上面的 170 错误还表明，在故障转移到另一个节点时，sql 服务无法启动，因为它已经在使用中，因此无法完全故障转移？但是我想知道为什么它首先需要故障转移？
我的假设可能完全错误，因此任何想法都将受到赞赏。
答案1
如果 CPU 锁定（即全部达到 100%），请考虑检查 SQL Server 中的 Maxdop 设置作为临时稳定措施 - 可从服务器级别的 GUI 或 sp_configure 高级选项中获得。默认情况下，它应该设置为 0 - 这样就可以了。
您可能需要考虑将 maxdop 更改为 3 或 2 或 1 - 作为使情况更好的稳定尝试。它是动态的，但请记住，跨多个核心（并行！）运行的任何进程都可能需要更长时间。
如果它产生了积极的变化，你就为自己赢得了一些时间来寻找真正的根本原因——这将通过更详细地查看工作量来实现。