This was another interesting situation where client reported that their SQL Server Cluster resource, sometimes, fail to come online when they perform failover of SQL Server from one node to another. In this blog, we would learn how to fix ” SQL Server resource not coming to an online state ” issue.
You would agree with me that it is easy to fix something which is happening continuously. In this case, it was a random behavior. I have looked into ERRORLOG for “good” and “bad” scenario and found something interesting in the non-working situation.
2018-04-30 02:29:47.85 spid7s Error: 1807, Severity: 16, State: 3.
2018-04-30 02:29:47.85 spid7s Could not obtain exclusive lock on database ‘model’. Retry the operation later.
2018-04-30 02:29:47.86 spid7s Error: 1802, Severity: 16, State: 4.
2018-04-30 02:29:47.86 spid7s CREATE DATABASE failed. Some file names listed could not be created. Check related errors.
2018-04-30 02:29:47.86 spid7s Could not create tempdb. You may not have enough disk space available. Free additional disk space by deleting other files on the tempdb drive and then restart SQL Server. Check for additional errors in the event log that may indicate why the tempdb files could not be initialized.
2018-04-30 02:29:47.86 spid7s SQL Trace was stopped due to server shutdown. Trace ID = ‘1’. This is an informational message only; no user action is required.
From above it is clear that someone grabbed the connection to the model database before TempDB database could get created. If we have a connection to the model database, we can’t create a new database. Here are my few earlier blogs explaining the solution to the same error.
- SQL SERVER – FIX: Error: 1807 Could not obtain exclusive lock on database ‘model’. Retry the operation later.
- SQL SERVER – FIX: Error 1807 Could not obtain exclusive lock on database ‘model’. Retry the operation later – Part 2
But in this situation, we are not trying to create a database. Its SQL Server trying to create TempDB using the model database. My client said it is an intermittent issue. When I again bought SQL online, it was successful. I attempted failover/failback – successful. After around 20 tests, one of the tests failed again with the same behavior.
WORKAROUND/SOLUTION
After a lot of trial and errors, we concluded that most would be some application or automated service trying to connect to SQL continuously. But why would they go to the model database? I was checking sys.syslogins and I saw “model” in dbname column and that was the big hint. We found that few accounts had a model database as their default database.
We changed it to master and observed many failovers, the issue never resurfaced.
Have you seen such issue earlier? Hopefully, some of my blog readers would be benefited with this blog. Please comment and let me know.
Reference: Pinal Dave (https://blog.sqlauthority.com)
First appeared on SQL SERVER – SQL Server Cluster Resource Doesn’t Come Online Randomly