SQLServer Always On FCI 集群节点同时占用资源及可疑状态修复

Troubleshooting Error 3313, 3314, 3414, or 3456 (SQL Server)

How to troubleshoot Error 9004 in SQL Server

由于msdb日志备份引起的（发现msdb数据文件有 60+GB！）

现在集群有问题了，相互占用资源，心跳没起作用。连接数据库内部查看节点能正常连接到其中一个。

select * from sys.dm_os_cluster_nodes
SELECT * FROM fn_virtualservernodes();

更重要的是：因为存储是共享的，系统数据库和用户数据库都共享！

两个节点用共享存储，按理说数据是一致的。为了使集群能恢复正常状态，打算转移集群。重启服务器比较好，不用逐个转移，使其自动所有资源转移。

重启之后！！

msdb 正常了！！

但是有 3 个用户数据库出现了 “可疑”！！

没办法，出现了就只能修复吧！！设置 “紧急” 模式修复，设置“单用户”，结果设置都产生死锁，无法执行！

设置单用户模式后很难恢复多用户模式，似乎不断有进程来执行！

干脆把集群另一个节点服务器（虚拟机）关闭了！进来还是一样的错误。

再接着不用集群连接，到节点服务器执行，还是一样！！

再以专用管理员DAC 启动服务，看谁还能连接！进来后老提示另一个用户在运行，此时设置数据库为多用户模式也不行！

好！再更改端口，重启mssql服务，看谁还连接！结果没人抢了！可疑进行操作也不会死锁，也没其他人操作，此时可以进行修复了！

两个较小（60GB和1GB）的数据库没问题；DBCC checkdb 修复过程中，有一个170GB的数据库修复至tempdb空间不足！修复了部分，且停止了。

但很快，因有些数据库文件都在同一磁盘，磁盘空间不足了！！使mssql服务自动停止！

好吧！删除一些数据库dump/log文件，启动服务分离一些不重要的数据库，把它移走（可能不再用了），移出共享盘。

什么！权限不够，本地管理员都无法移动文件！再逐个将数据文件的权限添加给本地管理员！

空间够业务用了，但是还有一个数据库没有修复！！再把临时数据库移到本地磁盘，才进行DBCC checkdb修复！

修复完成后把 tempdb 改回共享存储位置，并设置小一些！

此集群节点上修复完成！！！

但是，数据可能有丢失，集群还未敢恢复。

ALTER DATABASE dbname SET EMERGENCY 
GO
ALTER DATABASE dbname SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
ALTER DATABASE dbname SET SINGLE_USER 
GO
DBCC CheckDB (dbname , REPAIR_ALLOW_DATA_LOSS) 
GO
--after then:
ALTER DATABASE dbname SET MULTI_USER 
GO

SQLServer Always On FCI 集群节点同时占用资源及可疑状态修复

标签：无法   日志记录   enter   data   nod   tac   监控   for   iat