Thoughts on using TDMS for Hetrogeneous OS/DB Migr...

Former Member · ‎2009 Jun 24

I was having a good thought on how to minimise downtime on a migration project I'm currently working on (informix to oracle with 7TB of data).

Obviously you can't do anything with log shipping, etc. Then I had a brainwave. Why not ship deltas at the application level using TDMS?

Now I'm not a TDMS expert and don't know what limitations there are but my thoughts were as follows.

Copy Prod to Temporary hardware (system down so no new data is created) - Date and time stamp Noted

Start Prod back up

Export/import temporary system to new DB

Then using TDMS extract all data from the above date and time stamp (trickle feed).

Then at a convienent point. Stop the production system use (i.e. lock all users, finish all batch jobs) and extract the final delta via TDMS.

Start New Prod!

This is something I'm quite willing to research and do a proof of concept with if there arn't any major hurdles.

Any comments would be greatly appriciated

markus_doehr2 · ‎2009 Jun 24

As first advise: TDMS is not designed for production migrations.

> I was having a good thought on how to minimise downtime on a migration project I'm currently working on (informix to oracle with 7TB of data).

It's possible to minimize downtime of such a migration by doing package and table splitting together and doing export/import in parallel. There was a blog (I actually can't find it) where SAP migrated their huge HR system to Unicode (which is technically also a export/import using R3load). With appropriate hardware resources this can certainly be done, you are able to migrate, with decent hardware, 1 TB/hour.

> This is something I'm quite willing to research and do a proof of concept with if there arn't any major hurdles.

TDMS is MUCH slower than a migration using R3load because it reads the data on a logical application base. On top, it's not possible to give a "to-date", just a from date. So if you would first migrate one year back and later two years back, the one year back data would be read (and tried to be written in the target database) again so finally you would though need to run all at once which would then take a lot of downtime since there is no delta handling.

I would more try to explore the possibilities you have with the migration tools.

And yes, technically it's possible to have a source system on database X, create a shell from it, migrate that shell to database Y and import the data to that system.

Markus

Thoughts on using TDMS for Hetrogeneous OS/DB Migrations

Know the answer?

Need more details?

Accepted Solutions (0)

Answers (1)

Answers (1)