Friday, March 26, 2010

EventID 26322: A database exception was thrown in the Operations Manager SDK service.

This posting is provided "AS IS" with no warranties, and confers no rights. Use of the included sql query is at your own risk.

Got this error in one of mine SCOM R2 test environments. I tried to start the SCOM Console but all I got was an error message stating the SDK service wasn’t running. So I checked that first but all was OK. All RMS related services were up and running. Time to checkout the OpsMgr event log on the RMS.

That looks bad. Seems like some serious issues with the SCOM database:

Log Name:      Operations Manager
Source:        OpsMgr SDK Service
Event ID:     26322
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
A database exception was thrown in the Operations Manager SDK service. Exception Message: Cannot open database "OperationsManager" requested by the login. The login failed.
Login failed for user 'SYSTEMCENTER\srv-scom-sdk'.


Time to open SQL Server Management Studio. And yes, the OperationsManager database was in suspect mode. In normal worlds one creates BACKUPS of their systems and databases. But as already stated, this is one of mine test environments WITHOUT a backup plan…

Normally databases don’t die on you like that. But that test environment hadn’t been switched off neatly by me. So I had only myself to blame…

Now what?

But it is only a test environment which is already down the drain for 80%. So I had nothing to loose. Time for some heavy stuff which I normally never ever would do in a real life situation since their is a possibility to wreck it totally. But then again, in real life there are things like working and properly tested BACKUP & RESTORE PLANS in place and servers are switched off in a neatly manner…

So after stopping all SCOM related services on the RMS and MS, I run this query against the OperationsManager database:

EXEC sp_resetstatus OperationsManager;
DBCC checkdb(OperationsManager)
DBCC CheckDB (OperationsManager, REPAIR_ALLOW_DATA_LOSS)

It took a while to run but when finished the database was OK again. I started all SCOM related services on the RMS and MS and started the SCOM Console. It ran just fine without a glitch and the OpsMgr event log on the RMS was totally clean. No error messages what so ever.

But BEWARE. The fourth query line can really kill your database since data loss is allowed! It is a one-way street only with NO way back! Don’t run this SQL query in production environments since the changes are to end up with an unsupported configuration. Above mentioned approach is only meant for test environments and labs. But even when those environments are important, run a daily BACKUP of the databases…


jonponton said...

Thanks heaps for this one mate! I just had the same issue.

I'm not sure what caused my issue, but I think it all started around the same time as a bunch of windows updates were installed.

Marnix Wolf said...


thanks for your comments. But have you read the warnings as well? Since it is way much better to restore a valid backup then going the other way.