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; } } }

Deleting editions

prof_brazen_guff

TS 7.3.1

We have tens of thousands of old editions across multiple branches that I need to remove in order to free disk space. It would obviously be quickest to simply delete these on the server rather than running iwrmed multiple times via a script or by selecting them and deleting in TS, but I'm concerned that this may cause issues. Can anyone give me any advice?

Thanks in advance.

Paul

Find more posts tagged with

Comments

Migrateduser

TS 7.3.1

We have tens of thousands of old editions across multiple branches that I need to remove in order to free disk space. It would obviously be quickest to simply delete these on the server rather than running iwrmed multiple times via a script or by selecting them and deleting in TS, but I'm concerned that this may cause issues. Can anyone give me any advice?

Thanks in advance.

Paul

What do you mean by the part in red? How do you think you'd go about deleting the editions without using the tools that IW provides? I have been told by IW that you must delete editions using the provided methods, and you have to be careful not to bulk delete too many at a time or else it will consume too much of the CPU and likely crash your server. I was advised to delete no more than 100 editions at a time and wait until they are all gone before deleting another 100. This obviously will take some time if you have tens of thousands of editions, but better that then to corrupt your whole backing store by circumventing the process.

nipper

Smitty is correct in that the only way to remove an edition is using the CLT or UI. Even as root, using rm -rf won't help

A perl script running iwrmed will be fast, but you have to give the system time to clean itself up.

You can also look into a couple of other options. Have you ever run iwfsshrink ? If you have not, that is a good way to recover space. I run it once a month or so. Another option would be to use iwmigrate and move to a different store. If you have that much history, then your backingstore is quite old and migrating it, while a long process, will be a good idea.

In the end, nothing will be fast.

Migrateduser

Smitty is correct

I am saving this forever. It's in writing. I am in utter shock.

Another option would be to use iwmigrate and move to a different store. If you have that much history, then your backingstore is quite old and migrating it, while a long process, will be a good idea.

In the end, nothing will be fast.

I was also given the iwmigrate option from IW to archive old editions off the branch and make processing quicker - we have over 12000 editions and creating a new one takes a lot longer than if we only had 100 editions. Keep in mind that iwmigrate is a copy, though, not a move so you still have to clean up the editions on the source. That's what I was told anyway. We never followed through with that plan.

prof_brazen_guff

Thanks for the responses everyone - you've confirmed what I suspected, i.e. that this is going to be a time-consuming manual process ...

nipper

I am saving this forever. It's in writing. I am in utter shock.

Hey, even a blind squirrel finds a nut once in a while.

I was also given the iwmigrate option from IW to archive old editions off the branch and make processing quicker - we have over 12000 editions and creating a new one takes a lot longer than if we only had 100 editions. Keep in mind that iwmigrate is a copy, though, not a move so you still have to clean up the editions on the source. That's what I was told anyway. We never followed through with that plan.

So the idea of iwmigrate is you take a certain number of editions, not all 12K. It does need to migrate to a new store, but that is the whole idea. If you have a 10 year old store, it may have corruption or went through multiple upgrades (and store modifications). This allows the new store to be created from scratch. You would then archive the old store and replace with the new one.

Topic_38902__Total from Two Different DataSet Aggregrate.rptdesign

Migrateduser

Yes that's correct regarding iwmigrate. We were given two options to archive old Editions (we have to keep 5 years worth of content). One was to just migrate the old Editions to another store and keep the N number of recent Editions on the current store. The other was to migrate the N recent Editions we want to keep to a new store and use the current store as the archive. The second option would eliminate the need to delete a ton of old Editions.

nipper

........ The second option would eliminate the need to delete a ton of old Editions.

You do have a third option, hire someone competent. Doubt that is going to happen..... Smiley Very Happy

Adam Stoller

Smitty - didn't you, in the past, have some sort of script that kept track of the number of editions on a given branch and if a publish (create edition) event occurred, it would delete the oldest [named] edition to try to keep the number of [named] editions at a "reasonable" level?

If one has (or creates) something like that, then they may still have the issue of reducing the number of pre-existing editions down to the level they want to maintain - I seem to recall running into this sometime back and writing a script that would delete an edition and then periodically run iwstat (or iwstat -c) to make sure all the cleanup routines were done before running the next iwrmed command.

A little bit of coding / testing should make it fairly easy to write something that would accomplish the end-goal without completely bring the server to its knees.

Migrateduser

Smitty - didn't you, in the past, have some sort of script that kept track of the number of editions on a given branch and if a publish (create edition) event occurred, it would delete the oldest [named] edition to try to keep the number of [named] editions at a "reasonable" level?

Yes I did and still have that script laying around somewhere. It worked great as long as you cleaned up initially first, and kept editions saved at a reasonable level.

When I moved to this job, the initial design was to create a new edition anytime any content is published out. This created more than 10,000 Editions in 3 years. We also noted that whenever the workflow got to the step where a new edition was created, it took longer and longer to create a new edition - we're talking minutes. Ultimately we decided that we could cut one edition per day and still be able to find any old content without too much trouble. If only that had been the original design, we would have thousands fewer editions. There's a legal requirement to retain 5 years worth of content, so at the moment we're stuck with 12,000+ editions.

Adam Stoller

There's a legal requirement to retain 5 years worth of content, so at the moment we're stuck with 12,000+ editions.

Well, you could do something on a periodic basis like this:

I think that should work.

Migrateduser

You do have a third option, hire someone competent. Doubt that is going to happen.....

How does one become competent without asking questions?

Migrateduser

[QUOTE=ghoti]Well, you could do something on a periodic basis like this:

Would the version of TeamSite we are running 5 years from now support content from much older version?

nipper

How does one become competent without asking questions?

That comment was geared towards Smitty, no one else

Topic_38886__TOC and second page start at 1.rptdesign

nipper

Would the version of TeamSite we are running 5 years from now support content from much older version?

Unknown. You could be on the same version as today. I can name a number of companies that have not upgraded in 5 years.

If/when A/I changes the backingstore, it may require a migration, but TYPICALLY it will load up without requiring changes.

Migrateduser

That comment was geared towards Smitty, no one else

I think I read that in a fortune cookie once....what a crappy fortune.

Migrateduser

If/when A/I changes the backingstore, it may require a migration, but TYPICALLY it will load up without requiring changes.

Right, if you had to migrate, you'd need to maintain a release of the old TeamSite in order to mount it ?

Files.zip

Migrateduser

That comment was geared towards Smitty, no one else

My bad, in that context it's completely different than how I took it.

I'm an old guy, but new (and not so competent) to TeamSite.
Hoping to find help in this forum for this challenging product.

nipper

Right, if you had to migrate, you'd need to maintain a release of the old TeamSite in order to mount it ?

No, you would typically copy the backingstore to the new server and run iwmigrate there. There have been cases (5.5 being the latest that I remember) when you had to upgrade to a certain level before you can copy the store to a higher level. I do not remember this in 6.7.X

Adam Stoller

Right, if you had to migrate, you'd need to maintain a release of the old TeamSite in order to mount it ?

Unless they break something (and that's always a possibility) - all newer versions of TeamSite are able to read older versions of the backing store (contrary to what Nipper indicated, I think it was when they moved from 4.x to 5.5x that this might not have worked).

Basically it goes like this:

The reason for using iwmigrate is that the automatic / in-place upgrade to the backing store content does not take care of restructuring the backing store to take full advantage of any improvements that were made - iwmigrate, run on the new server, will take care of that restructuring. Unfortunately iwmigrate will also generate a lot of redundant data in the backing store, so you'll want to run iwfsshrink afterwards.