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 Date:          Event ID:     26322 Task Category: None Level:         Error Keywords:      Classic User:          N/A Computer:      SV01.systemcenter.org Description: 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) ALTER DATABASE OperationsManager SET SINGLE_USER WITH ROLLBACK IMMEDIATE DBCC CheckDB (OperationsManager, REPAIR_ALLOW_DATA_LOSS) ALTER DATABASE OperationsManager SET MULTI_USER

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…