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.