• 1 reply
  • Latest Post - ‏2014-05-20T15:15:45Z by nivanov
1 Post

Pinned topic SQL Server to DB2 migration

‏2014-05-20T02:53:38Z |

I work on the L2 support team for ISIM (IBM Security Identity Manager).  ISIM has supported SQL Server for a rather long time, but due to the small customer base and other factors, it's being phased out.  So clients with SQL Server will need to migrate their data to DB2.

The first client to try this is using SQL Server 2008 and will be migrating the data to DB2 10.  They want to use the IBM Data Migration Tool ("DMT").

First of all, has anyone done this before with DMT?

One problem I'm running into is that when we configure a DB2 database for ISIM as it's repository, we create two table spaces (one for data - ENROLE_DATA and one for indexes - ENROLE-INDEXES).  Then when we create tables when installing ISIM, we add the following to all create table commands:


I need the tables that are migrated from SQL Server to DB2 to do the same thing, place the data in ENROLE_DATA and indexes in ENROLE_INDEXES.

I've looked for a way to set default tables spaces on the DB2 user account and also looked for a set command or something similar that will specify the default data and indexes table spaces, but have come up dry.

The only way this can be done, as best I can tell, is to have the "IN ENROLE_DATA INDEX IN ENROLE_INDEXES" added to the migrated tables.

Can DMT do this?

We're talking about a hundred or more tables that would need to be modified in the schema, before laying down the DB2 schema, so I'd like to avoid doing this by hand.

Any ideas how to overcome this issue?



  • nivanov
    19 Posts

    Re: SQL Server to DB2 migration


    Hi Clyde, 

    A few points:

    - IDMT has been out of support for a couple of years now. It used to be the only IBM tool for SQL Server migration, however, SQL Server support is coming in a future version of the DCW, the new migration platform.

    - Having said that, I don't believe the automatic addition of the INDEX IN clause will be included in that support.

    - Having said that, is there a particular reason you think you need to place all your indexes in a separate tablespace? If you are trying to mimic the SQL Server physical layout then it may not be the optimal approach with DB2. If you insist on doing that, you should be able to script the change relatively easily.