nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Script to Delete Editions in TeamSite 6.1

pacer11

I know that there was a peformance issue to take into consideration when deleting editions in previous TeamSite versions but I was wondering if it would be wise to have a script deleting 90+ editions from about 20 or so branches based upon date creation.

Is there anything that I would need to consider in doing this?

Find more posts tagged with

Comments

Adam Stoller

Prior to 5.5.2, deleting editions was a MAJOR load on the system.
Since 5.5.2, deleting editions should be a relatively minor load on the system, but a load nonetheless.
I believe that the actual backing store cleanup of the edition removal takes place in the background asynchronously so as to not totally disrupt usage of the server - but the load will still be there (use iwstat -c to see what happens with regard to cleaning up 'dirty points')

I would suggest trying to spread out the process of deleting the editions so as to provide for an even load on the system over a length of time rather than trying to do it all at once.

Another possibility, though I'm not sure if it presents any less (or more) of a load - is to use a temporary secondary store and run an iwmigrate of just the editions you wish to keep into the secondary store; remove the branches from the default store and then migrate the contents of the temporary secondary store back to the default store (and then blow away the temporary store).

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

pacer11

Actually the idea of running the deleting edition scripts was a part of doing the migration from one backing store to another.
The whole idea was that we have a primary backing store that the end users had to contribute content, then every so often (3 months) we do the iwmigrate that migrates the contents of the primary store into the secondary store and then de-activate the secondary store.

This works fine but ideally we want to limit the amount of versions on the primary store to the latest 3 months and then have the rest of the versions archived in the secondary backing store.

So where the deleting of editions comes into place is when I am done with the iwmigrate from the primary backing store to the secondary backing store, I would also run this script so that I have the content from the 3 most recent months in the primary store, and I kinda wanted this all automated.

Now, the good thing (I am guessing) is that this will all be during a scheduled down time so there will be no end user activity, but I am wondering if like you said, if there may be a significant load on the server trying to delete too many editions at the same time. (Maybe I can put some kind of sleep command in between deletions??)

The idea of migrating everything to one store then deleting from the primary store and then migrating to the secondary store would really not work in our case because it's on the basis that we would want to keep both stores in sync when in actuallity the second store is more like an archive versus a backup store.

Adam Stoller

At this point you might be best off with trial-and-error - see what happens when you try deleting 5 editions at once on one branch; see what happens when you try deleting 5 editions at once from 5 branches at the same time; see what happens when you increase the number to 10; 25; 50; etc.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Migrateduser

A couple of thoughts on deleting editions:

The iwstat (or iwstatus? I've got it aliased as status..) command (at least on TeamSite 6.1 on Solaris) will only show you the 50 most current batch jobs that TeamSite is running. Each edition deletion is a batch job. So, it's hard to tell how big the batch job queue is if you do more than 50 at once. Edition deletion is fairly painless these days, but with the structure of some sites, some may take significantly longer than others. There is a command to halt batch processing if it is presenting a performance issue (a variation on iwfreeze) and I think there's now a way to clear out all pending batch jobs.

Also, you might consider writing a triggered process on a publish. This way, you can level out the disk usage within a particular site or store by deleting or moving an old edition when you publish a new one. We've been doing that for a few years now.

Wally Box
Nike, Inc.

jed

I would recommend testing this on a dev server by coping the backing store. We tried deleting editions on a 552 box once and it just about killed the server after deleting 1 edition!!! (I think we ran into a "parent-map" problem or something). Eventually we ended up using iwmigrate to just take what was in staging and start from scratch. Hopefully edition deletion is better in 6.1.

--
Jed Michnowicz
jedm@sun.com
Content Management Engineer
Sun Microsystems

Adam Stoller

Jed - are you sure that was 5.5.2 and not an earlier 5.x release?
Pre 5.5.2 systems had a lot of problems deleting editions, 5.5.2 and later shouldn't have that much trouble.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

jed

100% positive it was 552.

Looking at the support notes on the case, the problem we ran into was fixed in 552 sp6 and ts 6.1, so in theory a delete in 6.1 should be fine. But then again a delete in 552 was supposed to be server friendly. (That is why I suggest a test on a dev server.)

--
Jed Michnowicz
jedm@sun.com
Content Management Engineer
Sun Microsystems