appears unworkable to those of us using hosted solutions. There have been sufficient incidents in the 6 months since transitioning to a well-known hosting Company (also used by RG I am told) to have bred a low level of confidence that our 24x7 App can be correctly suspended and reactivated for simple monthly Windows/SQL patches without introducing further risk-points of specifically taking databases offline...if you know a shutdown or restart is imminent (such as when Windows Updates are to be applied), you can take each of the compressed databases offline (using ALTER DATABASE or SSMS) prior to the shutdown. This will typically close down the files in a controlled manner, then recovery upon restart will be much faster.
Good news to those of us hesitant to purchase due to this issue...This is a known issue which is being addressed, the fix is going through our QA system now to be released as a patch. The issue is that the SQL Server service starts and the HyperBac service is not completely ready, therefore SQL reads what it thinks is invalid data when it tries to bring the databases online, as it is not reading the files through the HyperBac filter. It is a timing issue, but the files themselves are not corrupt, you can take the databases offline and bring them back online after SQL has started and the HB service is running, failing this you can take the databases offline and run the hyperutil program with the –R switch on each compressed data file, then bring them back online.
There are a few workarounds for this until the patch is available:
1) Take all compressed databases offline before a scheduled restart -> bring them back online 60 seconds or so after the SQL Server service and HyperBac service are back up, this will work every time
2) After an unscheduled restart, take the databases offline and then manually bring them back online (as stated above)
Users browsing this forum: No registered users and 2 guests