Migrating from Teradata to DB2...

[Thierry]

We wish to migrate from an old Teradata DBC/1012 to DB2 (MVS).
About 30 Gbytes of data are concerned.

Teradata's SQL seems more or less standard, so conversion of
programs and JCLs should be easy. Our concern
is to insure the same level of performance...

Did you have some experience of that sort of migration ?
I should be glad to hear from you about this matter.
@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@
@/// Thierry FALISSARD - 10147...@compuserve.com @
@ - Computer freak and nerd - @
@ @
@ Visit my home page "Is there a life after MVS ?" at : @
@ @
@ http://ourworld.compuserve.com/homepages/TFALISSARD @
@\\\ @
@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@

[Kent Milligan]

I think DB2/MVS performance won't be a problem, I helped a customer
with a similar TeraData 1012 migration to to DB2/400.

We probably ran into more problems with peculiaraties with the Teradata
SQL than performance. It is standard looking, but they suggest doing
wierd things like a 2-way join & an update instead of a 3-way join.
The customer said the 2-way join solution actually ran faster in their
environment.

In article <573g29$c...@news.sct.fr>, 10147...@compuserve.com (Thierry) writes:
|> We wish to migrate from an old Teradata DBC/1012 to DB2 (MVS).
|> About 30 Gbytes of data are concerned.
|>
|> Teradata's SQL seems more or less standard, so conversion of
|> programs and JCLs should be easy. Our concern
|> is to insure the same level of performance...
|>

--
Kenton Milligan
DB2/400 Development
IBM Rochester-AS/400 Division
km...@vnet.ibm.com
GO HAWKEYES!!
(opinions stated are not necessarily those of my employer)

[D Preble]

Thierry wrote:
>
> We wish to migrate from an old Teradata DBC/1012 to DB2 (MVS).
> About 30 Gbytes of data are concerned.
>
> Teradata's SQL seems more or less standard, so conversion of
> programs and JCLs should be easy. Our concern
> is to insure the same level of performance...
>

> Did you have some experience of that sort of migration ?
> I should be glad to hear from you about this matter.
> @-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@
> @/// Thierry FALISSARD - 10147...@compuserve.com @
> @ - Computer freak and nerd - @
> @ @
> @ Visit my home page "Is there a life after MVS ?" at : @
> @ @
> @ http://ourworld.compuserve.com/homepages/TFALISSARD @
> @\\\ @
> @-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@-@

Your level of performance, of course, depends upon why kind of queries
you were hitting teradata with. If you had alot of table space scans
where it was necessary to look at most rows (as oppose to the index) you
will get worse performance. In other words, did my access on teradata
take advantange of parallel features ? If you did tablespace scans
because you had only partial keys, then db2 will be better. This all
assumes that the box that db2 is on has cpu available to service you. At
30GB you want to consider creating some partitioned tables to break up
the physical data location. This makes smallier chunks for utilities to
process, ... etc.