我们有一个在wondows 2008R2操作系统上运行的sql server 2008主动/主动集群。 14GB内存，4个CPU。 我们已经为sql server设置了12GB的上限。 我们正在运行代理作业，将300万条logging加载到数据库。 在此加载期间，作业失败，群集似乎尝试故障转移到另一个节点，但未成功，即群集地址不再可访问。 我们必须手动使群集节点失效。
在查看任务pipe理器的负载过程中，我们可以看到，内存使用量达到了最大12.5GB，并且CPU在所有4个CPU上都达到了100％，但是大部分时间平均大约为60％。
我想我的问题是，如果内存或CPU受到重创，群集会尝试故障转移吗？ 还是我吠叫错了树？ 还有什么想法，为什么它不会完全失败？ 我们已经爬过了日志，其中有很多，并找不到有用的东西。 我们也尝试重新创build这个问题，但是稍后它会成功运行。 另外300万行似乎不是很多，但在资源方面，14GB内存和4xCPU不够？
进一步的信息，我们今天再次运行负载，并损坏数据库！
我们收到了错误消息：LogWriter：Operating system error 170.它看起来像在负载繁重的情况下，sql群集试图故障转移，并且因此迁移了LUN（或驱动器），这意味着该磁盘不再可访问。 （这只是我们的理论）。 数据库现在是“可疑”，需要恢复。
上面的170错误也表明，在故障转移到另一个节点，SQL服务无法启动，因为它已经在使用，因此它不能完全故障切换？ 但是我想知道为什么它需要首先故障转移？
我的假设可能是完全错误的，所以任何想法，将不胜感激。
如果CPUlocking（即全部达到100％），请考虑检查SQL Server中的Maxdop设置作为临时稳定措施 – 可从服务器级别的GUI或sp_configure高级选项中获得。 默认情况下，它应该设置为0 – 这很好。
您可能需要考虑将maxdop更改为3或2或1，这是为了使事情变得更好。 它是dynamic的，但是请记住，跨多个核心（并行）运行的任何进程可能需要更长的时间。
如果它有积极的影响，那么你已经花费了一些时间来find实际的根本原因 – 这将来自更详细地查看工作负载。