System Center Operations Manager by Jonathan Hambrook

May 10, 2007

SCOM Operations Database Sizing

Filed under: Architecture, Microsoft, SCOM 2007 — opsmgr @ 9:24 pm

Sizing for the Ops DB is highly variable depending on which Management Packs are installed and what grooming policy is configured.  Without knowing the details of the deployment I can give you some “worst case scenario” numbers derived from an MSIT Management Group that manages 3000 servers and has all of the out-of-the-box MPs deployed along with 18 custom MPs and a 4-day retention policy (with the exception of performance signature data which is retained for just 2 days).  In this case MSIT allocated 60 GB for the Ops DB, of which they actually use about 35 GB.  Performance data accounts for about 75% of the total storage requirement with about 55% being used to store sampled performance data (which is retained for 4 days) and another 20% being used for performance signature data (which is retained for 2 days).  After performance data, collected events and monitor state change events account for the next largest category of storage used in the Ops DB with each accounting for about 10% of the total storage requirements.  Alerts account for about 1% of the storage requirement.  The remainder of the storage used is divided among a large number of tables with no other individual tables or data type accounting for any significant percentage of storage.  With over 85% of total storage requirements being derived from the above operational data I wouldn’t spend much time doing detailed calculations of storage requirements for other data types.  Unless you have unusual data retention requirements I would recommend using something similar to the MSIT storage allocation which will give you plenty of room for growth and some flexibility in adjusting data retention.

With regards to SQL log file storage requirements, the operational requirements are fairly trivial but you will want to allocate quite a bit more storage than required for day-to-day operations in order to cover the occasional need to delete Management Packs.  MSIT uses 16 GB for transaction logs in their 3000-server MG.  Under normal operations they rarely use more than a few hundred MB of this space (even while using the full recovery model with 15-minute log dumps) but much more is required on the rare occasions when large MPs need to be deleted.  A significant amount of data can be deleted in a single SQL transaction when large MPs are deleted.  MSIT has used up to 12 GB of log space while deleting some MPs.  I would recommend that you allocate a similar amount of storage to avoid any problems with full transaction logs when deleting MPs.


Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Blog at

%d bloggers like this: