6

For several document libraries in our SharePoint environment end user enabled versions without setting a limit. Or were given a document library with unlimited versions(result of having no governance in the past) Now we want to limit the number of versions being used. Thus we set the limit for one document library to 10 (as a test).

Once this setting is in place and an user edits some metadata on a document with ~300 versions (a 5MB document) the whole environment grinds to a halt, making it unavailable for 10 minutes and the new metadata values are not saved for that document.

ULS log gives no hints, Eventlog records an AppPool recycle, CPU load is low (SharPoint and SQL)

What is going on here? And how do I 'gently' get rid of the superfluous versions? (Now we have serveral document that take an awfull lot of DB space: a 6MB document with 300 versions takes 1.8 GB of database space!)

(MOSS SP2)

Improve this question
6
  • 1
    Interesting. So what happens if you remove the 10 version limit? Does performance get restored?
    – Paul Lucas
    Nov 23, 2011 at 10:31
  • 1
    Yep, when I remove the limit (back to previous setting) there are no issues and just an extra version in generated. SharePoint seems to have a really hard time in deleting all the superfluous old versions.
    – Dribbel
    Nov 23, 2011 at 10:41
  • 4
    I don't have a real answer so I'm just leaving this comment as a "If anything else fails, use fire" last hope solution. You could try to use a batch procedure to programmatically delete all the version untill only 10 vers remains for each document and then leave it to execute during a night/weekend/other - not a real solution, I know, so please consider it only in extreme cases.
    – SPArcheon
    Nov 23, 2011 at 10:53
  • I was going to suggest the same thing to be honest
    – Paul Lucas
    Nov 23, 2011 at 11:18
  • Or try poking the docs when nobody is using the system?
    – Kit Menke
    Nov 23, 2011 at 15:20

2 Answers 2

Reset to default
1

Well, here is a work around that may be beneficial. In the affected site collection, click on the Storage Space Allocation link in Site Settings. From there, click on the Documents link. You'll then see a listing of files. You can click on the link to be taken to the version history (_layouts/Version.aspx) for the file. From there you can delete all versions of the file or particular ones.

The files could be copied down locally, all versions deleted and then reuploaded. It isn't really ideal since it's all manual, but it might let you delete things without having to physically touch the files.

If that works, you might be able to script something with the versions web service perhaps?

Improve this answer
1
  • I've haven't tried totally deleting the file. I'll have to consult with the end users to find a 'test-case' I can use. I'd rather see a solution which doesn't involve deleting loads of files and re-adding them.
    – Dribbel
    Dec 7, 2011 at 18:58
1

I would suggest that after the rule is changed and the document is re-opened, SharePoint goes "what are all these extra versions doing in my content database?!", and is probably going in and deleting versions 11-299. Does the same thing happen the second time you modify the same document?

Improve this answer
6
  • Editing it the first time results in a 'crash' and the superfluous versions still exists after the crash and new data isn't saved, so there isn't a second time.
    – Dribbel
    Dec 7, 2011 at 18:54
  • Maybe try reducing the limit to 300 versions, making a change, then 200 versions, making a change, then 100 versions, then making a change, etc? Not suggesting this as a solution, but as a means of testing my theory, so that we can find a solution if this is indeed the problem.
    – alirobe
    Dec 8, 2011 at 7:44
  • Yep I tried that, and it seems to work. In small steps I can bring down the number of versions stored. But if I do that 10 times, all the versions present in the end are my ten 'version-pruning'-edits, and not the 10 last edits of the end user. And it is quite a hassle with many documents in a doc-lib. It appears that SharePoint (maybe SQL?) is too busy deleting versions it forgets to mind other things (like servering regular content)
    – Dribbel
    Dec 8, 2011 at 17:56
  • Right, so we either need to solve the app-pool crashing issue, or we need to figure out a way to perform this pruning without actually making any versions. This PowerShell script: blogs.pointbridge.com/Blogs/johnson_bert/Pages/Post.aspx?_ID=26 appears to offer a solution which may not cause any new versions to be created. If you are comfortable with Powershell, I suggest you modify it for test purposes (don't run it as-is!), test it, and see if it affects the versioning.
    – alirobe
    Dec 9, 2011 at 2:10
  • If we try to solve the app-pool crashing issue, I would suggest going into IIS on the server that is serving the front-end, temporarily increasing the time-out theshholds and RAM useage thresholds for the application server, and then trying a change. If this fixes anything, it would seem to indicate that the SQL connection is timing out, and that may potentially indicate that you've got a problem with SQL performance. You may want to check your disk IOPS meet SharePoint system requirements.
    – alirobe
    Dec 9, 2011 at 2:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.