Hello, I have an SCCM 2007 R2 server and it serves roughly 500 clients machines. The policy table (dbo.policy) is 28 gigs and growing about roughly a gig a week. The next largest table size is 3.5 gigs, so in comparison, the policy table is very large. I have been trying to find out what is causing this table to grow so quickly and haven't been able to find the culprit. Does anyone have any ideas of what I should do to see what is causing that table to grow so rapidly and fix the problem? Thank You.

Does this help? http://blogs.technet.com/b/configurationmgr/archive/2009/01/27/troubleshooting-database-growth-issues-in-configuration-manager-2007.aspx John Marcum | http://myitforum.com/cs2/blogs/jmarcum/|

Hey John, I saw that page when I was searching for a potential solution. The DBA and I looked at the size of our tables to see where the problem child was (the Policy table). For the columns in the Policy table, we could see the PolicyID, Version, DeviceVersion, Body, DeviceBody, PolicyFlags and DeviceBodySignature columns. The 97504 PolicyIDs in the table are all unique. The Versions and the DeviceVersions are not. 97466/97504 of the DeviceVersions are NULL. For the Versions column, 50149/97504 are 2.0 and 43351/97504 are 1.0 (the rest are other versions). That is sort of suspicious, but I don't know what that means. Is that bad? I can't sort the Body or DeviceBody because they are an image type and cannot be sorted. I also cannot see what is in those columns. Those two columns are where most of the data in the table lives. I just don't know why there is so much of it there and how to stop it. That page you linked sort of helps, but I still am lost. It seems like the Policy table isn't as obvious to see why it is growing vs the StatusMessages table, since I can't see my data when viewing it in Management Studio. Is there anything else I should look into? SCCMNooby

The best option would be to open a case with Microsoft. Regards, Madan

Hello - I agree with Madan. How about the performance of SCCM? Is it normal? Did you verify the log files and Inboxes? And did you find any abnormality? Anoop C Nair

Sorry I didn't reply. I thought this thread was e-mailing me updates... Anyways, I called Microsoft and opened a case. An00p - Performance was extremely slow. It normally wasn't this slow and SQL would use its maximum amount of memory very quickly after a reboot. After opening a case with Microsoft, I spoke with an engineer that was awesome. After running several queries, he determined that 95,000 / 98,000 rows of the Policy Table were related to Software Updates. Out of those rows, a significant portion of the rows were 22 megabytes per row. The row information contains instructions to SCCM on when and how to apply the update. They should be way less than a megabyte typically. He says that the only updates that he could possibly think of that would be remotely that size are Forefront updates, but we don't use Forefront, and did not configure it to download Forefront updates. The engineer wrote a script to delete those rows (95,000 rows) and re-index the database. We re-synced with WSUS and our database size is now around 4 gigabytes. It ended up being a bug with SCCM and SQL, as he was able to duplicate the issue in his lab. He told us to apply Cumulative Update 12 to our SQL 2005 SP3 server. He wasn't too sure if that would fix it or not. SP4 is not supported by SCCM. Everything regarding the size of the database is now all good. None of the rows are near 22 megabytes in size.