GilaMonster (10/7/2013)
Jeff Moden (10/7/2013)
GilaMonster (10/7/2013)
Jeff Moden (10/5/2013)
I have a similar problem that turns out to be some rather inefficient code that truncates several very large tables and reloads ALL of the data from an AS 400 every bloody night. Folks are in the process of repairing the code for performance and I'm in the process of moving the tables to a dedicated database in the SIMPLE recovery mode and to a separate set of disks not on the SAN.Why would that affect the cluster's quorum drive?
Because everything that changes int these tables ends up going to the quorum drive.
If it does someone has badly configured that cluster. There should be nothing from SQL Server on the quorum drive. I don't even know if the quorum drive can be marked as a dependency of SQL, it should be off limits to everything but the cluster management itself.
All that should be on the quorum drive are logs and a few files put down by the cluster installation, it should never be used for anything else.
Sorry... I hit post before I finished. I didn't have anything to do with this setup so I don't have a sufficient understanding of the details but our NetOps guys are apparently using the quorum drive to transfer data to our warm DR site. If the pipe between here and the DR site can't keep up, then the data on the quorum drive just gets larger and larger. From what I've been told, it's not actually SQL Server that's feeding the quorum drive. The quorum drive is only responding to what is changing on the SAN drives. What's changing on the SAN drives is an absolute shedload of data during the nightly runs. There was some tipping point where if it got too far behind, it would go into a rather dedicated transfer mode and that just crushed the server when it happened. I use past tense because they supposedly fixed the problem but I'm not sure what they did to fix it other than getting a better pipe between us and the DR site.
--Jeff Moden
Change is inevitable... Change for the better is not.