Monthly Archives: April 2015

Wait on the Database Engine recovery handle failed. Check the SQL server error log for potential causes

7 Replies

When installing Microsoft SQL Server 2014, you might come across a situation where the setup fails towards the end of the installation with the following error,

“Wait on the Database Engine recovery handle failed. Check the SQL server error log for potential causes.”

Error when installing SQL

If you ignore the error and continue with the installation the following will be displayed.complete with failures

After scouring the web for a fix I was able to resolve the problem with the below steps. Some answers asked me to both uninstall SQL Server and delete a specific set of SQL registry entries, I did not delete any registry entries. I fixed the error by only uninstalling SQL 2014 using add/remove programs.

After SQL 2014 was uninstalled, I restarted the server then started the installation by right clicking on “setup.exe” and selecting “start as administrator”. Proceed with the installation normally until you get to the Server Configuration section,

Before change

On the SQL Server Database Engine service, click the drop down option to select a new user.

click advance

Click “Advanced”

click find now and select network service

Click “Find Now” then browse to “Network Service”, select this user and click OK.

After change

It should now look like the above, now continue with the installation.
You should no longer have the issue.

Finished Succesfully

vSphere 6 vCenter Server Appliance – Scalability

Leave a Reply

vcenter server appliance

 

vSphere 6.0 vCenter Server Appliance now has the same scalability numbers as the windows vCenter Server. There really isn’t many reasons left why some organisations will not want the appliance over the windows vCenter. vCenter Update Manager requiring an additional windows server perhaps?

 

IBM Storwize IP replication

Leave a Reply

I was recently working on a VMware SRM solution utilising an IBM Storwize v3700 SAN at each site with remote mirror. I had configured a global mirror with change volume relationship over IP which works beautifully when both source and target SANs were in the same subnet/building. Once the target SAN was moved out of the building to the DR site, the IP SAN traffic went through the gateway across the WAN to the other site. The performance for the IP replication was pretty average, to say the least,  out of a 100Mbps link, I could only achieve 1MBps, even though windows file copy would easily saturate the link providing 10MBps consistently.

Windows File Copy

 

We ended up testing the link for packet loss and while it did show some packet loss, I had assumed that given that Windows file copy could achieve 10MBps then the Storwize SAN from IBM should be able to achieve similar results.
Well, it turns out that’s incorrect. As per the below snippet from the IBM System Storage SAN Volume Controller and Storwize V7000 Replication Family Services Redbook.

packet loss results in sever performance degradation well out of proportion to the number of packets actually lost. A link that is considered “high quality” for most TCP/IP applications might be completely unsuitable for the remote mirror.

IBM Storwize Packet Loss

 

Now, this helped explained why Veeam could perform Backup Copy to the DR site at a consistently fast 10MBps without any problems yet the remote mirror performed so badly.

After resolving the packet loss problem which was dodgy SFP+ fibre adapters and a couple cables, the remote mirror performance jumped straight to 10MBps and has stayed there consistently ever since.