Re: Oracle Migration Workbench

From: Harvey <harvey_b_at_comcast.net>
Date: Thu, 11 Oct 2007 18:26:47 -0400
Message-ID: <HPadnaUXuvG1PpPanZ2dnUVZ_gSdnZ2d@comcast.com>

Frank van Bortel wrote:

> Brenda wrote:

>> Hi everybody
>>
>> I am learning how to use this tool from Oracle, to migrate from a
>> Sybase database to an Oracle 10g.
>> I have worked with DTS from SQL and with that tool I could map the
>> fields from the source schema to any fields from the destination
>> schema. Also I could add validations and transformations during the
>> migration.
>> As far as I can see, with OMW I cannot select the destintation table
>> or map the fields from the source with the destination. Maybe I am not
>> using it correctly.
>> Is there a way to add validations in the migration of data from source
>> to destination? Or change the destination tables?
>> Please, any help would be very appreciated.
>> Thanks a lot.
>> Brenda.-
>>

> No you cannot - it is designed as a migration tool,
> not as a cross platform ETL tool.
> 
> The one thing you can do, is change datatypes, though limited.
> 
> Tne table(s) will be created, and bcp is used to extract data,
> which is then imported, using SQL*Loader. Controlfiles for
> SQL*Loader are generated, but for LOBs, these have limited use.
> Maybe the latest version have changed.
> 
> There is/was/used to be a very responsive development team.
> 

Just some comments - I've worked with the prior version of OMWB and the new SqlDeveloper version (most recently this past weekend when I had to convert a couple of databases from SqlServer to Oracle). In both cases you're able to set the datatype translations on a global basis, but not on a table-by-table basis. If you want to control the target structure you need to create the tables before you start the migration process. If you're migrating and you want the level of control where you map fields then you'll have to rely on DTS.

They both work - but differently. I preferred the older version and used that primarily during this conversion, however, part of that is learning curve and getting a good grasp on the SqlDeveloper based version. I have a couple of good baseline databases to work with now so there will be the chance to better wring out the new tool.

What I would like to see as a rather nice 'whistle/bell' with it is a process that will query the source and target databases and compare row counts for the tables. I do that manually but a built-in capability would be nice.

Harvey Received on Thu Oct 11 2007 - 17:26:47 CDT