DB2 migration v8.1 to v9.5 in SAP 6.40

[Former Member]

Hello Sirs,

I'm planning the migration of the databases of v8.1 to v9.5 in SAP 6.40.

I have a few questions regarding this issue... if anyone knows please tell me.

1. Is there any inconvenience of having DEV system under DB2 9.5 and the other systems Productive and Quality with DB2 8.1?

2. Does anyone found any tricky problem in this database migration 8.1 -> 9.5?

thanks.

regards,

Filipe Vasconcelos

[Former Member]

Perfect

[Former Member]

Thanks Sameer.

[Former Member]

Regarding Post-migration issue...

[Former Member]

Thanks Sameer.

I hope to get this upgrade without problems.

Thanks for your help

[Former Member]

Hello Sameer,

I made the upgrade of release 8 to 9.5 last Monday. It was like a charm.

Everything OK.

I left for next sunday the phase of reorg offline to Large Record Identifiers. For a dev system oif 100GB, how much time do you estimate that this phase will take?

thanks.

regards,

Filipe Vasconcelos

[Former Member]

Hi Filipe,

While the offline reorg (or any IO intensive activity) depends a lot on your IO subsystem bandwidth and available CPU and

memory resources, I would say approximately 4 hours would be a reasonable starting point. In our environment, I would estimate a 100 GB system to be reorged in about 2-4 hours. Note that you dont have to reorg all the tables in the system in one window. If you feel that you are nearing the end of the allotted time window, you can always cancel the reorg and resume from that point onwards in a subsequent window. This will allow you to fine tune your downtime requirements by the time you reach your production systems.

Hope this helps.

- Sameer

[Former Member]

Thanks Sameer.

I did understand the issue of the configuration.

But regarding the instance... isn't it enough to restore from backup?

How would I recreate the instance?

[Former Member]

Hi Filipe,

Once the instance is migrated to a higher release (V9.5 from V8.2) there is no way to "demigrate" it. You would need to do the following:

1. Uncatalog the database IF IT IS NOT MIGRATED (Drop if it is migrated).

2. From the new software directory (for eg: /opt/IBM/db2/V9.5/instance), drop the instance using the db2idrop command.

3. From the old software directory (for eg: /usr/opt/db2_08_01/instance), recreate the instance using the db2icrt command.

4. Recatalog the database IF IT WAS NOT MIGRATED (Restore if it was migrated).

5. Reimport the configuration that was backed up.

6. Reinstall db2 license files.

This is obviously at a high level but covers the basic idea. Procedurally, I would suggest that you perform and document this process in the sandbox environment before upgrading your Q and P environments.

Hope this helps,

Sameer

[Former Member]

Thank you for your answers.

Just another doubt.... imagine that I get any problem during the migration of the database.

The rollback is just to restore the backup taken before the migration or is there any other tasks regarding DB2 parameters (regristry variables, db and dbm configuration....)?

thank you.

regards,

Filipe

[Former Member]

If you have to rollback after the migration for any reason and the database itself has been migrated (by running the migrate database command), then you would need to drop and recreate the database instance using the older software copy AND restore the database from the backup taken prior to the upgrade. Also the database restore only brings back the db config and not the dbm config so dbm config will also need to be restored. Usually I take a backup of the entire configuration (registry, dbm, db) by using:

db2cfexp <backupfilename> backup

The backup file contains the entire configuration and can be used to restore the configuration at the time of a restore if needed by running:

db2cfimp <backupfilename>

Its always a good policy to backup whatever gets modified by the upgrade process.

Hope this helps.

- Sameer

[Former Member]

Hello Frank,

Thanks for your reply Frank. My SYSCATSPACE has 1GB.

So as I understand, I can migrate instance and database during the week. Get the system up and leave post-migrations tasks for weekend, right?

regards,

Filipe Vasconcelos

[Former Member]

Filipe,

You should be able to complete the database migration, run the basic post migration steps and be up and running within an hour or two (maximum!). The remaining post migration steps like large RID/SLOT conversion which requires offline reorgs can be done at a later time. This is how we managed to migrate our 6TB+ BW warehouse by splitting the large RID/SLOT conversion process over a period of several weeks.

Please note that this does not include offline backups and we almost ALWAYS took offline backups prior to a migration. This adds to your window unless you have a snapshot backup functionality like flash or BCV.

- Sameer

[Former Member]

Hello,

Thanks for your answer.

Could anyone tell me the time will last a 100GB database migration of the instance and the database?

thanks.

regards,

Filipe Vasconcelos

[Frank-Martin]

Hi Filipe,

the instance migration takes less than a minute.

The database migration step depends more on the size of SYSCATSPACE than on the total size of your database.

Depending on your hardware the database migration may take about 1 hour.

Post migration steps like reorganizing indexes to make use of large RIDS may take much longer.

However those steps can be shifted to a later point in time.

Regards

Frank

[Former Member]

Filipe,

The only problem we experienced in having our dev system at a higher release of DB2 as compared to Q and P is that during homogeneous system copies (from P->D) , we had to backout our database upgrade and "re-upgrade" the database. The only other challenging part was to convert tables and indexes to use large RIDS and large slots since it requires an offline reorg on the tables. Our BW system is close to 6 TB and so this was a pretty extensive offline reorg time window for us.

However, we did get a lot of benefits from the upgrade (STMM, Deep compression etc) and something that helped us save a lot of money in storage costs.

- Sameer