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

delta migration with minimum downtime to production

Ramy1

After we migrate and upgrade production repository from 6.5SP3 to 6.7SP2 (intermediate version) then to 7.1 (target version), during the testing of the new environment, the live production repository is still on 6.5SP3, receives more documents. When we finish the test on 7.1 we need to copy the new documents created on 6.5SP3 before go live of the new environment. Copying this delta cannot be done by dump & load as both repositories has same repository owner and repository id (if either one of them is different then only we can do dump and load between repositories).

Can you please suggest ideas about doing this delta migration with minimum downtime to production ?

Thanks

Ramy

Find more posts tagged with

Note:

If there are Accepted Answers, those will be shown by default. You can switch to 'All Replies' by selecting the tab below.

Button

Accepted answers

bacham2


The steps that i made to upgrade the repository that took time "t", should be fully repeated again on the delta objects created during time "t+d" ?

Then it will turn out to be repeating the upgrade and migration two times ?!!

As far as the filestores are concerned, you will only need to copy the delta. As far as the database schema is concerned, you will need to go through two consecutive upgrades. There's no way to do this incrementally. But at least, you should go faster the second time since you are already completed the migration to your target system and solved all issues.

All comments

Alvaro_de_Andres

Use (or code) a 3rd party migration application. If you don't have too many types/attributes it should be faster to code it.

bacham2

Use the procedure described in the Content Server 6.7 installation manual: Creating a Repository Copy to Test an Upgrade.

The idea is to perform a first migration at time t, including copying over all content files to the new machine. Then you repeat the procedure for the delta at time t + d, only this time, you only need to copy the content files created since the time t. However, you still need to go through the upgrade process with a fresh Oracle database dump. Important: do not run dmclean or dmfilescan after time t.

Ramy1

Thanks Alvaro

But what level does that code will manipulate and what language to use ?

Does this code will work on db level _s and _r tables ?

Thanks

Ramy

prasan_13

As long as you don't have any workflows or lifecycle's and the only content are documents and folders , then you should be able to write a simple dfc program to do the delta migration. You could get a list of all modified documents and copy them over. If you do have other moving pieces other than just documents it could get tricky.

Alvaro_de_Andres

Stick to DFC/DFS/REST and Documentum object model. Dump every object info to a XML file, then load the info using DFC.

Ramy1

Thanks


Then you repeat the procedure for the delta at time t + d, only this time, you only need to copy the content files created since the time t.

The steps that i made to upgrade the repository that took time "t", should be fully repeated again on the delta objects created during time "t+d" ?

Then it will turn out to be repeating the upgrade and migration two times ?!!

Ramy1

Thanks , but is it simple ? Do you have any sample code to do so "exporting objects created in timeframe to XML files then importing the same to the upgraded repository". and what about those objects are still not upgraded and on the old object model of 6.5sp3 while i need to import them to the new upgraded/migrated repository 7.1 ?

bacham2

Not sure why a Documentum upgrade suddenly turns into a project where you write DFC code. Just stick to the standard upgrade procedure.

bacham2


The steps that i made to upgrade the repository that took time "t", should be fully repeated again on the delta objects created during time "t+d" ?

Then it will turn out to be repeating the upgrade and migration two times ?!!

lastnitescurry

Agree with Bacham. Filestore deltas are easy. Do full database refresh and upgrade.