(Update from Monday morning, the workaround shown below works for me)
Another day, another set up problem (sigh) I was installing a second SQL 2008 R2 instance on a new cluster today. The first one had gone well without incident but the second one had a crucial change in that it used mount points. It was a fairly complex install with 8 mount points under the root volume and it took a while to complete all the setup configurations. When it got started it failed with the following selection of errors:
1. A dialog box with the error
Wait on database engine recovery handle failed. Check the SQL Server error log for potential causes.
2. The setup finished and pointed me to the usual error log files in the setup directories. In the summary log file I saw an equivalent error
Detailed results: Feature: Database Engine Services Status: Failed: see logs for details MSI status: Passed Configuration status: Failed: see details below Configuration error code: 0x4BDAF9BA@1306@24 Configuration error description: Wait on the Database Engine recovery handle failed. Check the SQL Server error log for potential causes. Configuration log: C:\Program Files\Microsoft SQL Server\100\Setup Bootstrap\Log\20120420_114647\Detail.txt
3. When opening the referred to detail.txt file I found pretty much the same again
2012-04-20 12:17:28 Slp: Configuration action failed for feature SQL_Engine_Core_Inst during timing ConfigRC and scenario ConfigRC. 2012-04-20 12:17:28 Slp: Wait on the Database Engine recovery handle failed. Check the SQL Server error log for potential causes. 2012-04-20 12:17:28 Slp: The configuration failure category of current exception is ConfigurationFailure 2012-04-20 12:17:28 Slp: Configuration action failed for feature SQL_Engine_Core_Inst during timing ConfigRC and scenario ConfigRC.
4. The text file pointed me to the SQL Server error log of the partially installed instance. When I opened this, I found the “real” cause
2012-04-20 16:00:51.51 spid8s Clearing tempdb database. 2012-04-20 16:00:51.52 spid8s Error: 5123, Severity: 16, State: 1. 2012-04-20 16:00:51.52 spid8s CREATE FILE encountered operating system error 5(failed to retrieve text for this error. Reason: 15100) while attempting to open or create the physical file 'O:\data\tempdb.mdf'. 2012-04-20 16:00:51.52 spid8s Error: 5123, Severity: 16, State: 1. 2012-04-20 16:00:51.52 spid8s CREATE FILE encountered operating system error 5(failed to retrieve text for this error. Reason: 15105) while attempting to open or create the physical file 'O:\data\tempdb.mdf'.
The SQL Server error code 5123 is why the instance couldn’t start, as it’s unable to create a tempdb database data file, and no SQL Server can start without tempdb being present. The “real” error though is the reason for this occurring which is error code 5 from the OS when SQL runs the createfile API. This is one that everyone probably recognises which is “access denied”. So the bottom line here was that I was getting access denied on the root of my mount point for tempdb (which is where I had placed the data files as part of setup configuration).
I checked through the other parts of setup and the rest of the system databases had managed to write to the root of other mount point drives (which seemed strange), and of more relevance, I noted that the SQL Server service accounts had been granted full access to the mount point root directories as part of the setup, so theoretically there ought not to be a permission error!
I spent a few hours digging around, tried the install again with new mount points and a clean position, but encountered the exact same problem. Eventually I figured that it was due to the fact that there are “issues” with the permissions on root mount points. This is distinctly not well documented within official MS sources (or not that I could find) and certainly not within the official pre-reqs.
http://msdn.microsoft.com/en-us/library/ms189910(v=sql.105).aspx
The best I could find was a connect item here
a blog post here
http://getyouriton.blogspot.co.uk/2009/08/serious-gotchas-with-mounted-drives-or.html
and a forum post here
However the accepted workaround is that you should create a sub directory under the root of the mount point and then you’ll be fine. I’ll be trying this method next week as its 8pm on a Friday now and time for the weekend. If it works I’ll probably post a bug requesting that the documentation gets changed to point this out, as it would have me a whole lot of time.
As always, good luck with your setup……
