Manipulate SBSMonitoring Database

sql-server-2008windows-sbs-2011

Our SBSMonitoring database has reached its limit (10GB). I've worked with databases in a previous job and I'm familiar writing SQL queries.

Is it safe to delete entries from tables in that database? I would keep entries from the last 3 months and delete anything older.

Is there anything I should keep in mind?

I'm looking into this because of following event:

CREATE DATABASE or ALTER DATABASE failed because the resulting
cumulative database size would exceed your licensed limit of 10240 MB
per database.

Info: SQL Server 2008 SB Server 2011 standaard

Best Answer

I wouldn't recommend trying to trim the DB manually, you should simply follow the well-publicised instructions for recreating a new, blank SBS monitoring DB: http://blogs.technet.com/b/sbs/archive/2011/08/22/how-to-recreate-the-sbsmonitoring-database.aspx

EDIT to add information: The monitoring DB in SBS is just the datastore for the console display functionality, which shows various informations about the state of the SBS clients (updates, AV, OS level etc). As such it's not important unless you (or more often your client) finds the SBS console particularly enamoring and useful. Recreating it, manually trimming it, bundling it up in a sack and throwing it off a cliff, none of these things are going to ruin your day very much. At worst the console will stop displaying the client informations.

Specifically addressing pitfalls or side-effects, I know of none for the recreat method, and have done this many times. Feel free to try trimming yourself if you prefer.

Since all the information collected is dynamic, by creating a new database you would lose only any custom reports you may have created in the SBS Console, report customizations, and all the archived reports. Furthermore, upon recreating the database, it will need some time to contact all clients and report on their status, this time may vary, since clients may be offline, it is recommended to wait 48hrs before trying to validate the data.

Related Topic