The ‘under the covers’ mechanics of grooming has changed substantially in MOM 2005 compared to previous releases. I thought we could spend a few lines in this entry discussing those differences.
The grooming options in MOM 2005 GUI look very similar to those presented in MOM 2000 – but thats where the similarities stop. In MOM 2000 the actual grooming operation was carried out by a series of SQL statements that would go through the various tables to select and then remove event, performance and collected event data. While this process did work it was not uncommon for the SQL queries to run for several hours – if not more. A process that wasn’t the most efficient!
In MOM 2005 this has been redesigned. If you take a look at the various tables in the MOM 2005 database one thing that will catch your eye right away is that there are now 60 tables to store event data, 60 tables to store performance data and 60 tables to store collected event data. The idea then is that we can use 1 table to hold data for each day of operation. So, when the day starts at 12:00 am we begin storing event data – perhaps event table 8 as an example – and keep adding data to that table until the day ends at 11:59 pm. Then, we move to another table to start storing the next days data. The beauty of this design is that when it comes time for grooming we don’t have to worry about scanning these tables to find events that match a particular age – all we have to do is scan a definition table that describes which tables hold data of a particular age and then we truncate the appropriate tables. The truncation process finishes in a fraction of a second – even for very large tables – which is a HUGE improvement over the several hours it used to take.
It should be pointed out that the data storage in the various tables may not be as you would expect and it is important to always allow the MOM processes to perform the grooming operation as several tables are involved and things could get out of control if attempting to do this manually. In some cases a manual operation is required but in those situations you should involve Microsoft PSS.
A further discussion point regarding grooming is of interest – namely, if reporting is installed and the DTS package isn’t working (DTS package internals are referenced in another blog entry on this site) then grooming won’t work either. When the grooming operation starts we check to verify that the data we are about to remove has been transferred to the data warehouse (if one is configured – if not we just groom the data without checking). If we haven’t transferred the data successfully we won’t remove it because doing so could cause missing data in the data warehouse. The end result of this is that the database can (and has) grow to a very large size which can cause MOM performance and ability to operate to stop in it’s tracks. Special remediation is sometimes necessary in those cases.