Speed of TSM database to DB2

[rketterer]

I will be converting a production TSM database to DB2,  as part of the upgrade to CMOD 9.5 on AIX .  in test it took 2 hours and 19 minutes for 850 MB.  In production the estimate is 60 Hours, because the database is 20.57 GB.  Does anyone know if there is a way to speed it up?  More threads or more processors or both?   Thanks Rob

[Justin Derrick]

Just make sure you're on the fastest disks available.  The import process is extremely I/O heavy.

You can talk to your DB2 team and get advice about tuning, but the process is fairly straightforward, as the migration from 5.5.x to 6.x or 7.x has been around for years now.

I've done TSM migrations that took 12 to 16 hours, each with particularly large databases -- so hopefully the duration you're predicting won't match reality because it probably doesn't scale linearly.

Good luck, and report back with any news/results! 

[rketterer]

JBNC,     Have you done the conversion from the TSM B-Tree Database to DB2 or just migrated from DB2 to DB2 ?   Thanks Rob

[Justin Derrick]

There's really only one database migration -- the old TSM 5.x database to the new TSM 6+ DB2 database.  Everything else is just an upgrade.

-JD.

[Anand]

We just completed TSM 5.5 to 6.3 migration, and the TSM database export & import to new 6.3 DB2 process took around 1 hr to complete for ~5 GB database size.

[rketterer]

Thanks for your help so far.  One more question.

In one of my logs I received the following warning message:

SQL3039W  The memory available to LOAD for DATA BUFFER prohibits full LOAD
parallelism.  Load parallelism of "1" will be used

I have 16GB of memory on the test LPAR where I did the migration and got only 850 MB done in 2.25 hours and 64 GB on the Production where I will do the next migration.  I would like to try and get better throughput.  Can the parallelism be over be overwritten, and is that a wise thing to do?

[Justin Derrick]

You're treading into an topic that's best answered by your local DB2 DBA's.  While the DB2 database inside TSM performs quite well out-of-the-box, there's always opportunities for tweaking.

If you're still doing this in a test environment, try tuning DB2 database configuration parameters like  UTIL_HEAP_SZ.  My rule of thumb is to double the current value, then test, then double it again.  If performance goes down, reduce the value by half of the increase, then test again.

Don't forget to change the values back to the original after the import is done.