There is a new feature added to the R2 Cumulative Update 4 hotfix, which I recently wrote about HERE.
This new feature enables the OpsMgr Management Server to tolerate a SQL outage hosting the OperationsManager database better in specific cases. This feature is NOT enabled by default, by design. In order to enable this feature you MUST have previously applied R2-CU4 or later to your RMS role. You should only enable this feature, if you feel you have been impacted by this issue, and you find you have to restart your RMS services frequently to get things flowing again after a SQL connectivity outage.
Under typical situations, the Root Management Server reconnects to SQL pretty well, if the SQL server is unavailable for a short time. This might happen if your SQL cluster is failed over (there is a short period where the SQL instance is unavailable during a failover) or when patching/rebooting a stand-alone (non-clustered) SQL server.
However – in larger environments, or when the SQL outage is extended beyond a short reboot/failover, we have seen where the RMS does not reconnect/recover successfully. Subsequently, the RMS might start logging errors in the event log from the Health Service – including 2115 (bind) events, and 4506 (Data dropped) events. Previously – this situation did not recover until the RMS OpsMgr services were restarted (and in some cases the HealthService on the Management server).
To enable this feature - On the RMS – create two new registry entries:
Under the “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\DAL” key, create two new DWORD values, as below:
DALInitiateClearPool should be set to Decimal value “1” to enable it.
DALInitiateClearPoolSeconds should be set to Decimal value “60” to represent 60 second retry interval.
Here is a screenshot:
This change will take effect after you restart the RMS HealthService (System Center Management Service).
Thanks Kevin, after reading the KB article it wasn't clear what type of registry values needed to be created. Especially as the KB describes one of the values as 'DALInitiateClearPool = true' - which I though it was a bit ambiguous. You have cleared it up though :)
Thanks for the info, as pointed out already - the kb article doesn't tell you that you have to use dword entries and that true is actually 1.
thanks for the great post
Does anyone know if this also works in SCOM 2012?