Oracle to Teradata migration
Moderators: chulett, rschirm, roy
-
- Premium Member
- Posts: 83
- Joined: Tue Oct 28, 2008 1:55 am
- Location: Chennai
Oracle to Teradata migration
We have nearly 600 datastage jobs in which the target table & target lookup tables are Oracle EE stages.
Now we need to fork lift the Oracle database to teradata.
Is there any other way we have other than opening each & individual job and changing the oracle stage to teradata stage?
Before some time when we need to change a parameter in 40 jobs we have exported the dsx and made changes in the dsx code and re-imported it. After compilation it worked. Will it be be possible in this case?
can any one please guide us with your ideas.
Thanks
MSR
Now we need to fork lift the Oracle database to teradata.
Is there any other way we have other than opening each & individual job and changing the oracle stage to teradata stage?
Before some time when we need to change a parameter in 40 jobs we have exported the dsx and made changes in the dsx code and re-imported it. After compilation it worked. Will it be be possible in this case?
can any one please guide us with your ideas.
Thanks
MSR
The minute you start talking about what you're going to do if you lose, you have lost
It won't be that simple, I'm afraid. You could test that process out by exporting one job as a control, then manually changing the stage to Teradata and exporting it again, comparing the two exports. You'd need to quantify the exact differences between the two and see if you could come up with some way to automate that change. And I don't mean via an editor search/replace but perhaps a Server job to effect the change?
"Fork lift", eh? If you mean what I think you mean - you create an "exact" image of the Oracle database design in Teradata - then I wouldn't want to be in your shoes. I worked somewhere where another team attempted to do this and it was a complete and utter failure. Sure, to management it sounds like the quickest way to get you there, but you really need someone proficient in Teradata to work on redesigning it properly for that database to take alleged advantage of all the reasons you all went with it and then migrating your data to it. Dropping an Oracle design unchanged onto Teradata is a recipe for disaster, IMHO. Good luck with that.
ps. That place? They "went back" to Oracle.
"Fork lift", eh? If you mean what I think you mean - you create an "exact" image of the Oracle database design in Teradata - then I wouldn't want to be in your shoes. I worked somewhere where another team attempted to do this and it was a complete and utter failure. Sure, to management it sounds like the quickest way to get you there, but you really need someone proficient in Teradata to work on redesigning it properly for that database to take alleged advantage of all the reasons you all went with it and then migrating your data to it. Dropping an Oracle design unchanged onto Teradata is a recipe for disaster, IMHO. Good luck with that.
ps. That place? They "went back" to Oracle.
-craig
"You can never have too many knives" -- Logan Nine Fingers
"You can never have too many knives" -- Logan Nine Fingers
-
- Premium Member
- Posts: 83
- Joined: Tue Oct 28, 2008 1:55 am
- Location: Chennai
Thanks chulett. We are on the way. But it is really tough to map the Oracle attributes to Teradata attributes for the tables. Some tables are target and some are look up and some are intermediate temp tables.The code logic should map all input, output & look up stages if the table involved is present in Data warehousechulett wrote:It won't be that simple, I'm afraid. You could test that process out by exporting one job as a control, then manually changing the stage to Teradata and exporting it again, comparing the two exports. You'd need to quantify the exact differences between the two and see if you could come up with some way to automate that change. And I don't mean via an editor search/replace but perhaps a Server job to effect the change?
![Crying or Very sad :cry:](./images/smilies/icon_cry.gif)
For the forklift approach I can't really help myself. The architects are at my commanding position and I left with no option as they think their EDM will do wonders after this lift
![Exclamation :!:](./images/smilies/icon_exclaim.gif)
The minute you start talking about what you're going to do if you lose, you have lost
-
- Participant
- Posts: 3593
- Joined: Thu Jan 23, 2003 5:25 pm
- Location: Australia, Melbourne
- Contact:
There may be a very big shortcut. Version 8.1 comes with a new set of Connector stages for Teradata and Oracle and it comes with a Connector converter - an application/wizard that turns Enterprise Stages into Connector stages. There may be a way to use it to turn Oracle Enterprise stages into Teradata Connector stages.
I would hate to see an Oracle data model dumped straight into Teradata - there are some significant differences as to how Teradata handles primary keys. You could end up with a slow and expensive Teradata configuration. I think unless you go through a data model validation and redesign exercise using a Teradata guru you are headed for a complete disaster.
You will need to consider how to configure each Teradata target stage as to which load option is the most efficient as Teradata has several ways to load data.
I would hate to see an Oracle data model dumped straight into Teradata - there are some significant differences as to how Teradata handles primary keys. You could end up with a slow and expensive Teradata configuration. I think unless you go through a data model validation and redesign exercise using a Teradata guru you are headed for a complete disaster.
- http://teradata.uark.edu/research/wang/indexes.htmlPrimary index determines the distribution of table rows on the disks controlled by AMPs. In Teradata RDBMS, a primary index is required for row distribution and storage. When a new row is inserted, its hash code is derived by applying a hashing algorithm to the value in the column(s) of the primary code (as show in the following figure). Rows having the same primary index value are stored on the same AMP.
You will need to consider how to configure each Teradata target stage as to which load option is the most efficient as Teradata has several ways to load data.
Certus Solutions
Blog: Tooling Around in the InfoSphere
Twitter: @vmcburney
LinkedIn:Vincent McBurney LinkedIn
Blog: Tooling Around in the InfoSphere
Twitter: @vmcburney
LinkedIn:Vincent McBurney LinkedIn
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
Gosh, that's how UniVerse table storage (and Unidata table storage) is handled too! Both of these, however, were invented in the 1980s. They were also Y2K compliant from day one.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Re: Oracle to Teradata migration
Hey, As per my understanding it isnt a good approach to go for any shortcuts for Oracle to teradata migration .Reason is as follows: In Oracle we have DateTime fields but in Teradata there is split to date and time .I.e. Say in Oracle we have a field Current_Date which is Datetime,we have to split that to Current_Date (Date) and Current_Date_Time(TimeStamp).So we have to go for job level modifications,as there would be so many such fileds in every job.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact: