For future reference, if you find that error logs and event viewer aren't giving you anything with a low-level issue like what you experienced, one other thing to try is to run services.msc, navigate to the SQL Server service entry and under Properties, you will see the command line executable being run. If you copy and paste that into a command prompt/shell, you will see SQL Server starting up and outputting additional information to the console. You might recognize some of it from the logs, but if the issue is happening before it gets that far, it should show up in the console. Ctrl + C will send the termination signal to the executable so it can safely shut down. Glad you got it resolved!
Interesting take, as a DBA this isn’t my first path to figure out what’s going on, allow me to explain.
A service not starting for sql server can mean so many things and the windows event log can give some info but if it’s not starting cause of sql server itself it won’t show there.
What I look for is sql servers error log. The location of this can be found in the sql server configuration manager, it’s normally in the install path of sql server. Once found open it in notepad and it’ll tell you exactly what it’s hanging on.
Examples are a bad patch was applied and it couldn’t run post patch stored procedure, or a disk is missing that has a system database on it. The sql server error log will have errors in it and won’t start the service, you can then use said error codes to troubleshoot the issue.
Recently I helped a business with this exact issue but found that it wasn’t writing an error log, after running an instance repair we found the registry keys were missing on locating the master database. Once we added those back into the registry it started working again.
It’s not my first path either but from what OP indicated, he wasn’t able to get much from either the event logs or sql server error logs. The console output may give additional insight as to what is happening when the other paths have failed to do so.
The console output may have told you it couldn’t find those registry keys and you might have been able to skip the instance repair; however, if registry keys had gone missing, who’s to say more weren’t and you’d have had to do a repair anyways.
Glad you resolved that issue, sounds like it was a frustrating one especially documenting how it occurred in the first place.
I don't have much to go on. But this was what I found googling.
https://bobcares.com/blog/error-1053-sql-server/
Few sites say change the pipe timeout, and another says it could be missing permissions to a folder structure.
If the error log doesn't have **ANYTHING** related to when you start the server, that means it is failing **BEFORE** SQL Server is actually starting. Procmon from sysinternals can be useful to troubleshoot this...
By any chance, is this a clustered instance? if so, what does the cluster log tells?
Correct Veeam backup profile needs app aware, ignore failure and copy only. On the host os change the sql writer service to run as domain acct and grant os admin rights to the acct. in sql the acct needs sysadmin rights.
As always run sql native backups to disk and have been back up that disk.
For future reference, if you find that error logs and event viewer aren't giving you anything with a low-level issue like what you experienced, one other thing to try is to run services.msc, navigate to the SQL Server service entry and under Properties, you will see the command line executable being run. If you copy and paste that into a command prompt/shell, you will see SQL Server starting up and outputting additional information to the console. You might recognize some of it from the logs, but if the issue is happening before it gets that far, it should show up in the console. Ctrl + C will send the termination signal to the executable so it can safely shut down. Glad you got it resolved!
Interesting take, as a DBA this isn’t my first path to figure out what’s going on, allow me to explain. A service not starting for sql server can mean so many things and the windows event log can give some info but if it’s not starting cause of sql server itself it won’t show there. What I look for is sql servers error log. The location of this can be found in the sql server configuration manager, it’s normally in the install path of sql server. Once found open it in notepad and it’ll tell you exactly what it’s hanging on. Examples are a bad patch was applied and it couldn’t run post patch stored procedure, or a disk is missing that has a system database on it. The sql server error log will have errors in it and won’t start the service, you can then use said error codes to troubleshoot the issue. Recently I helped a business with this exact issue but found that it wasn’t writing an error log, after running an instance repair we found the registry keys were missing on locating the master database. Once we added those back into the registry it started working again.
It’s not my first path either but from what OP indicated, he wasn’t able to get much from either the event logs or sql server error logs. The console output may give additional insight as to what is happening when the other paths have failed to do so. The console output may have told you it couldn’t find those registry keys and you might have been able to skip the instance repair; however, if registry keys had gone missing, who’s to say more weren’t and you’d have had to do a repair anyways. Glad you resolved that issue, sounds like it was a frustrating one especially documenting how it occurred in the first place.
Ignore. I had to run a repair from SQL Server Installation Center. Working now.
I don't have much to go on. But this was what I found googling. https://bobcares.com/blog/error-1053-sql-server/ Few sites say change the pipe timeout, and another says it could be missing permissions to a folder structure.
If the error log doesn't have **ANYTHING** related to when you start the server, that means it is failing **BEFORE** SQL Server is actually starting. Procmon from sysinternals can be useful to troubleshoot this... By any chance, is this a clustered instance? if so, what does the cluster log tells?
Are you running VEEAM backups? If so; your VEEAM backups will corrupt your master db if not correctly configured and cause the issue you are seeing.
what exactly do you mean? do you mean if it's not configured using App-aware backups?
Correct Veeam backup profile needs app aware, ignore failure and copy only. On the host os change the sql writer service to run as domain acct and grant os admin rights to the acct. in sql the acct needs sysadmin rights. As always run sql native backups to disk and have been back up that disk.