Share via

SQL and DB Sizing for SMS 2003

  • Article

The sizing of SQL DBs for SMS has always be a much debated topic for many years. In SMS1.2 and 2.0 days we generally recommended 1-200kb per client plus 50 Mb for a database size.

 

DB Sizing changes for SMS 2003.

Considerations:

1. One problem with these recommendations is that today with the new feature sets of SMS 2003 we have to consider no only SMS but also its feature packs such as Patch Management and the upcoming OS Deployment and Device Management. Device management has the potential to double the number of “managed” machines in some organizations.

2. New features such as file path reporting for software inventory, a more useable Software Metering feature and the use of the DB to store client software distribution have changed the landscape considerably.

3. Customer extensions to hardware def.mofs greatly exceeded our expectations.

 

During the SMS2003 development cycle we closing monitored Microsoft’s own deployment as well as that of our beta enterprise customers.

 

The conclusion of which is that most customers can utilize a sizing estimate of 1 Mb per client for the SMS DB for most standard deployments of SMS 2003. For customers who feel they will really push one of the features above, a conservative estimate would be to use 2Mb per client.

 

Detailed Analysis of DB Usage.

In the databases I have examined, software inventory and statue messages are the biggest DB users. For SMS 2003 we introduced the tracking for file path for each executable we report. This is fine for most environments. However when there is more than one location of a client for a particular file, instead of reporting this as two instances counts for the same row in the software inventory table, we now report it as 2 separate rows. This is clearly going to make a big difference from SMS2.0.

 

In theory status messages for SMS2003 should be more performant from SMS2.0 as we eliminated a number of “less than useful” (PC statement) status messages. However on the flip side, software distribution and client reliability percentages have greatly increased, result in more status messages being delivered.

 

In SMS2003, as in SMS2.0, customer expansion of the hardware inventory definition file (def.mof) can also play a defining role in DB sizing. Many customers of SMS2.0 extended the def.mof to gather any number of company specific and non-company specific items.

 

However the mistake many made was in not considering the storage needs of these new items and designing the extensions to utilize multiple tables and indexes. By failing to do this, the performance of hardware inventory processing suffered at the hands of trying to update the same single DB table for multiple classes/categories. The larger the table the slower adds/deletes and especially inserts can be.

 

Tempdb and SMS Log DBs.

The tempdb is used by SMS on a regular basis. The area that normally causes problems are when a Query or Collection (using a query) is badly formed, resulting in the need to create a very large temp table to produce the results. In some cases I have seen these temp tables/DBs group to over 100% of the associated SMS DB (sometimes over 36Gb). Be very careful with queries.

 

The tempdb is also critical during upgrades. Temporarily increasing the size of the temp DB to over 50% of the SMS DB is sometimes necessary under these conditions. Please ensure you run setup.exe with the /testdbupgrade switch at least once before any upgrades take place.

 

The SMS transaction log is used to record all transactions that are written to the SMS DB. By default SMS’s backup regime is set to “simple” (see SLQ documentation for further information). Essentially what this means is that the SMS log DB is not going to be used for restores. If the machine crashes you will be able to restore the site server to the last SMS backup (you will lose all processing since then). This means that SQL will clear parts of the SMS log DB as required.

 

Generally, the common recommendation configuring the SMS log DB and Tempdb to be 20% of the SMS DB size is probably a very good place to start.

 

The exception to this is when SQL replication is used for MPs. With SQL Replication being configured on the SMS site server the SMS Log DB will not be cleared until replication is successful. Careful monitoring of replication is therefore required (through SQL Enterprise mgr) to ensure you don’t cause the SMS log DB to run out of space. If this occurs, data loss is possible.

 

Suggestions

For both SMS DBs I generally like to have “autogrow” enabled and set to grow by a percentage instead of a fixed amount of MB.

 

Your own experiences and careful monitoring (mainly using SQL Enterprise Manager and SQL Profiler) will allow you to determine what the best configuration is for your environment. During deployment watch the size of the DBs grow as the number of clients installed increases.

 

Disk Configurations

As far as disk configurations the greater the separate of these DBs from each other the better. Three separate disk arrays is obviously the best, but not always possible. If you expect large volumes of processing to occur, separation of the SMS DB and the SMS log DB will yield good results. However if a large amount of reporting is likely to occur, then separation of the tempdb from other DBs might be important. Once again it all depends. My preference would be to maximize the separation of the SMS DBs, especially is SQL replication is enabled.

 

With disk hardware being as cheap as it is these days, there really is no excuse not to over spec the size of the drives. As far as which RAID configuration to use, well that depends so much on the environment, in most cases RAID 10 is preferred, then RAID 1 (assuming using 2 channels) or RAID 5. But this also depends on SCSI channels available and card memory, as well as the enterprise environment (size etc) and requirements. I am not going to recommend any solutions here, as the range of options are numerous and always hotly debated.

For example separate RAID 10 array’s for each DB is very, very expensive and probably overkill. I would however consider it a very good solution for the SMS DB and possibly use RAID 1 for the SMS log db and tempdb.

Comments

  • Anonymous
    June 10, 2004
    Craig, under the heading "Detailed Analysis of DB Usage" you said "...the mistake many made was in not considering the storage needs of these new items and designing the extensions to utilize multiple tables and indexes."

    As one who implemented many SMS2 MOF additions, I'd like to better understand the specifics of your comment. What are the considerations I should keep in mind in light of this comment as I tweak the SMS2003 MOF so I can avoid the problem referred to.

    Thanks for an EXCELLENT overview of an often-misunderstood topic!

  • Anonymous
    June 15, 2004
    SO is there a tool coming or not???

  • Anonymous
    June 15, 2004
    For Hardware sizing and hierarchy capcity planning, yes.
    At present this doesn't include SQL server sizing calculations. A future version likely will.
    Using the "rules of thumb" in this article should steer you in the right direction thou.

    Cheers
    Craig

  • Anonymous
    July 14, 2004
    ddd

  • Anonymous
    August 08, 2006
    PingBack from http://netsaber.wordpress.com/2006/08/08/sql-and-db-sizing-for-sms-2003/

  • Anonymous
    December 17, 2006
    Sizing an SMS2003 database is an often misunderstood subject, which can cause a lot issues if not done...

  • Anonymous
    November 25, 2007
    PingBack from http://feeds.maxblog.eu/item_645064.html

  • Anonymous
    January 21, 2009
    PingBack from http://www.keyongtech.com/2060550-which-size-of-data-base

  • Anonymous
    June 18, 2009
    PingBack from http://homelightingconcept.info/story.php?id=2721

  • Anonymous
    June 18, 2009
    PingBack from http://gardenstatuesgalore.info/story.php?id=1535