Mmigrate to fresh stores whilst keep latest edition

Hi all,

We are planning a house cleaning exercise in the form of a migration of our current content stores onto fresh new stores on a separate hard drive. This is for 3 reasons:

To deal with current corruptions on our backing stores,
To drastically reduce the size of the content stores.
We have been told by support not to run the iwfsshrink command on TeamSite version 6.7.2.

The existing stores will then serve as historical stores.

We plan to migrate our branches whilst keeping the latest Edition only, except for when the latest is the INITIAL edition. The iwmigrate CLT has 2 parameters to do this -s (start edition) and -e (end edition) but I wondered if there was a way to migrate the latest edition for each branch without having to specify a specific Edition name? This way the command can be run recursively for all branches rather than having to run a separate iwmigrate clt for each specific branch like so:

iwmigrate -g -m [mount_location] -o [new_store] -b [branch_vpath] -s [start_edition] -e [end_edition] -w

Any advice would be greatly appreciated.

Thanks,

Adrian.

Find more posts tagged with

Comments

Adam Stoller

Actually - you only need to use the '-s' flag to specify the last edition for each branch, it will then migrate that edition plus anything that happened since then.

You can utilize the CLT iwlasted to dynamically determine the last named edition on each branch so that you can code something up in a loop (remember to use the '-g' flag too)

I'm curious why Support said you should not run iwfsshrink on 6.7.2 (which, I'm assuming, is the version you're currently using -- obviously you should consider upgrading in the not-too-distant future)? iwfsshrink should not cause issues and should almost always be run after doing an iwmigrate (on the target store) since the process used by iwmigrate causes lots of redundant data in the backing store that iwfsshrink then cleans up.

Can you perhaps get more details from them on why they say you should not use iwfsshrink?

nipper

Actually - you only need to use the '-s' flag to specify the last edition for each branch, it will then migrate that edition plus anything that happened since then.

You can utilize the CLT iwlasted to dynamically determine the last named edition on each branch so that you can code something up in a loop (remember to use the '-g' flag too)

I'm curious why Support said you should not run iwfsshrink on 6.7.2 (which, I'm assuming, is the version you're currently using -- obviously you should consider upgrading in the not-too-distant future)? iwfsshrink should not cause issues and should almost always be run after doing an iwmigrate (on the target store) since the process used by iwmigrate causes lots of redundant data in the backing store that iwfsshrink then cleans up.

Can you perhaps get more details from them on why they say you should not use iwfsshrink?

If he is only getting the last edition, then shrink is likely unneeded. Still cannot hurt to do....

Reji Varghese

I'm curious why Support said you should not run iwfsshrink on 6.7.2 (which, I'm assuming, is the version you're currently using -- obviously you should consider upgrading in the not-too-distant future)? iwfsshrink should not cause issues and should almost always be run after doing an iwmigrate (on the target store) since the process used by iwmigrate causes lots of redundant data in the backing store that iwfsshrink then cleans up.

Can you perhaps get more details from them on why they say you should not use iwfsshrink?

Adam,
I recollect reading this a while ago and even heard from some of my support contacts that iwfsshrink can cause issues. So, we had to comment off all our shrink cron jobs.

https://customers.autonomy.com/support/secure/docs/FAQ/Interwoven/64846.html

AdrianUK

Actually - you only need to use the '-s' flag to specify the last edition for each branch, it will then migrate that edition plus anything that happened since then.

You can utilize the CLT iwlasted to dynamically determine the last named edition on each branch so that you can code something up in a loop (remember to use the '-g' flag too)

I'm curious why Support said you should not run iwfsshrink on 6.7.2 (which, I'm assuming, is the version you're currently using -- obviously you should consider upgrading in the not-too-distant future)? iwfsshrink should not cause issues and should almost always be run after doing an iwmigrate (on the target store) since the process used by iwmigrate causes lots of redundant data in the backing store that iwfsshrink then cleans up.

Can you perhaps get more details from them on why they say you should not use iwfsshrink?

Thanks very much for your quick responses!

I had already actually coded a quick implementation in my Virtual Machine to test the process. At the moment there's one script that loops through all our branches and runs the iwlasted and iwattrib publishdate CLT against each one and then prints each branch plus it’s last edtion and publishdate. The idea being that the publish date would be used to identify and remove any branches that have not been used for a while.

I then have another script which runs the following command with each branch:

iwmigrate -g -m [mount_location] -o [new_store] -b [branch_vpath] -s [start_edition] -e [end_edition] -w

Now I know that I was heading in the right direction I will amalgamate the scripts into something more programmatic.

I had not realised that the -e flag is redundant in my case, thanks for that tip also!

The client that I am working at was told by Autonomy Support (before I joined) that they should no longer run the iwfsshrink CLT on TeamSite 6.7.2. It had been causing issues on the backing store I believe. We are planning on upgrading TeamSite to 7.3.2 or 7.4 but this will not happen for a few months, thus we are going ahead with some house cleaning in the meantime.

Thanks again.

Adrian.

Adam Stoller

Adam,
I recollect reading this a while ago and even heard from some of my support contacts that iwfsshrink can cause issues. So, we had to comment off all our shrink cron jobs.

https://customers.autonomy.com/support/secure/docs/FAQ/Interwoven/64846.html

Hmm - maybe it was a bug in 6.7.2 - I've used iwfsshrink on every project I've ever done a migration for, and never heard about any problems resulting from it....

Garth McMillan

Regarding the iwfsshrink, there was an entry in the 7.3.2 Release notes as a resolved issue: TS-15966 Use of iwfsshrink can lead to data loss in certain scenarios.

However, it obviously may only have been related to the 7.x releases.