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

To shrink or not to shrink...

Bowker

We are about to migrate our TS installation from one box to another. We have two choices on moving our backing store
1) copy the whole backing store
2) iwmigrate just the last 30 (90?) days worth of editions

Our current backing story was originally created in November 2005 and we create editions every night on about 15 branches. Some branches are quite active while others are quite static, but still a new edition is created nightly.

It is very rare that we need anything older than 30 days. Our plan is to copy the whole backing store over but name it ..._archive to keep it separate and if necessary we can mount it to get to the old data.

Here's the question. Is it worth the hassle of doing that or should we just copy over the whole backing store and use it intact. Does the system run faster with a smaller backing store? Other than waiting minutes to get a list of editions are there any compelling reasons to scrape off just the last 30/90 days?

Find more posts tagged with

Comments

Jenni

Here are my thoughts...

Smaller the content, fast is the processing on few functions like search.
If you are not worried about the history then, why do you need to preserve the editions. You get some harddrive space benefit as well.

If you chunk of the editions, you will not have the version of the file that is related to the edition that is deleted.

Thanks!

sampleBirtReport.zip

Bowker

We have auditing reasons to "never" delete and/or be able to reproduce content back "forever".

Obviously there are some restrictions to "never" and "forever" but I need to be able to retrieve very old data at times. About once per year I'm asked to restore something from **** years ago.

Crsb

one approach is to create a smaller store from the existing store, something with one month of history. Move the entire existing default store to an archive store then deactivate the archive store.
This will give you the benefit of a smaller faster store such as less editions and history for the curious user to browse or search which degrades performance for all users not just the one executing the search, faster backups, faster maintenance (iwshrink). this also makes it easy for you to get old data by activating the archive store when needed.

Bowker

Is the system faster with a smaller backing store. The obvious answer is Yes, but has anyone experienced or have any numbers to back up "faster"?

My content managers will want a "it will run xx% faster" response.

Crsb

I understand your point and been there, I don't think you can get that kind of numbers from devnet, even Autonomy Sales teams won't give you that kind of numbers. It is just common sense that things need maintenance every now and then. I wont be surprised at all if you run into performance issues with the contentstore (especially coming from 6.5 to 7.x), even if it looks acceptable now, it is a completely different situation (performance wise) when it is BAU and you have all the users using the application.

Personally, I try to take proactive approach to things and implement good practices/recommendations from the experts whether there are symptoms or not. but of course, they are others who think if something is not broken then don't spend your time on it (sometimes there is good reason for this approach too). if the content manager is very happy with the performance now and no one complains, then I guess let them have it as is and just document that you did have a chance to do some clean up and you decided not to because there weren't numbers to justify it Smiley Happy