Content Database Keeps Growing - AllDocVersions Table to blame
Our productionSharepoint Services 3.0content database keeps growing daily. Its over 11GB now. But our test environment is only around 700 MB and that wasrestored from a stsadm backup from the productionenvironment.We do have a document library that has versioning turned on and its set to keep 24 versions. This library contains about 60 PDFs which are updated every night from a Reporting Services subscription. This shouldnt cause the database to keep growing though since only 24 versions are kept right? Besides, there is not 10 GB worth of documents in our environment.I did some research and the table that is taking up all the space is is the AllDocVersions table. This table is taking up10580040 KB of space. Any ideas what could be causing this or what I could do to fix it?Matt
October 29th, 2008 10:19pm

Hello, Some space size problems on sharepoint are caused by the increasing of database log size, which can be solved by truncate log. But, your problems seems not same as it. After estimating your special case, the size of your database seems reasonable according to your volume and type of document. Every time you check out and then check in a document, a new entry of alldocversions will be populated. This not only include your items of pdf type files, but also all items in all lists. You should notice some pages modification which are reside on lists, because they are sometimes the most frequent updating ones and so it may be the factor to cause your data increasing in alldocversions table. What you should do is as follows: 1. Go to every site collection, and go to any list which restore pages and those big lists which has version enabled such as your pdf file library. 2. View version history for those items, delete those outdated or useless versions. 3. Go to recycled bin under site collection, first empty recycle bin under end user recycle bin items view. Then delete all items under deleted from end user recycle bin After that, you will see the data in alldocversions table decreased. Hope it can help you, JerryXing-Bing Yu
Free Windows Admin Tool Kit Click here and download it now
October 31st, 2008 9:02am

Hello, I have the same problem as Matt. We have developed a little code to delete the versions of the documents in all libraries in the site collection, we've already empty the two recycle bin and there is still no change in the size of the allDocVersions table which has about 30GB of data. I'm kind of running out of ideas here, any suggestions ?Please, help !!!!Thank you in advance.FlaviaFlavia Brotto MCITP EPM e MCTS Sharepoint Portal/Services
May 15th, 2009 12:34pm

Hello, Have you tried shrinking the database? That usually helps refresh the database size. Goodluck! Philip
Free Windows Admin Tool Kit Click here and download it now
March 23rd, 2010 8:17pm

Hello We have the same problem. have you already an solution for this ? Shrinking the databse is not the solution, the table allDocVersions is really 200 Gb in size Thank you Rogier Duurkoop
June 25th, 2010 11:46am

Rogier, Did you find a solution? We have the same issue. A workflow made some runaway versions and ran that table up, I was able to the delete the items, emptied all the recycle bins, but the items are stock in the alldocversions table. I can look at the table, see them in there with a deleted tranaction ID, but they never get deleted.
Free Windows Admin Tool Kit Click here and download it now
July 29th, 2010 11:07pm

Rogier, Did you find a solution? We have the same issue. A workflow made some runaway versions and ran that table up, I was able to the delete the items, emptied all the recycle bins, but the items are stock in the alldocversions table. I can look at the table, see them in there with a deleted tranaction ID, but they never get deleted.
July 29th, 2010 11:07pm

Rogier, Did you find a solution? We have the same issue. A workflow made some runaway versions and ran that table up, I was able to the delete the items, emptied all the recycle bins, but the items are stock in the alldocversions table. I can look at the table, see them in there with a deleted tranaction ID, but they never get deleted.
Free Windows Admin Tool Kit Click here and download it now
July 29th, 2010 11:07pm

Yeah, this is a really curly problem. I assumed i had done everything in the correct manner. I had written a PowerShell script to programmatically traverse every item in every list in every site and perform an Item.DeleteVersions() method against each item. I then wrote another script to turn off versioning for every list. My alldocversions table has reduced its rowcount from 33000 down to 266 as i would have expected. I then emptied the site collection recycle bin and then purged them from the secondary recycle bin in Site Collection Settings. I have also changed the database backup plan to "simple" and performed the database shrink action. No size reduction came. But, alas, I am in the same situation as everyone else: my alldocversions table is consuming 85gb, whereas a sql query reports that it is only using 17mb. None of the defragging options i've seen in other posts work, my table index is only using 16mb. So the title of this forum entry is correct: the AllDocVersions table is to blame for the bloat, but i am stuck as to why and how to rectify it. Xing-Bing Yu: Why is there a green tick for your post, as your suggestion does not solve the problem? Grrrr, Ben
August 18th, 2010 6:34pm

Yeah, this is a really curly problem. I assumed i had done everything in the correct manner. I had written a PowerShell script to programmatically traverse every item in every list in every site and perform an Item.DeleteVersions() method against each item. I then wrote another script to turn off versioning for every list. My alldocversions table has reduced its rowcount from 33000 down to 266 as i would have expected. I then emptied the site collection recycle bin and then purged them from the secondary recycle bin in Site Collection Settings. I have also changed the database backup plan to "simple" and performed the database shrink action. No size reduction came. But, alas, I am in the same situation as everyone else: my alldocversions table is consuming 85gb, whereas a sql query reports that it is only using 17mb. None of the defragging options i've seen in other posts work, my table index is only using 16mb. So the title of this forum entry is correct: the AllDocVersions table is to blame for the bloat, but i am stuck as to why and how to rectify it. Ben
Free Windows Admin Tool Kit Click here and download it now
August 18th, 2010 6:34pm

To clear out the stuck versions of deleted items I ended up going into the table itself in the content database and deleting the rows with some simple SQL statements using the "ID" field to identify which rows could be deleted, and which rows needed to remain in tact. Moderator Note: Never propose your own posts as answers. The "Propose as Answer" function is to propose the good answers of other people. Not for self-proposals.
February 17th, 2011 2:03pm

To clear out the stuck versions of deleted items I ended up going into the table itself in the content database and deleting the rows with some simple SQL statements using the "ID" field to identify which rows could be deleted, and which rows needed to remain in tact.
Free Windows Admin Tool Kit Click here and download it now
February 17th, 2011 2:04pm

To clear out the stuck versions of deleted items I ended up going into the table itself in the content database and deleting the rows with some simple SQL statements using the "ID" field to identify which rows could be deleted, and which rows needed to remain in tact.
February 17th, 2011 2:04pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics