An upgrade plan ...need some tips

[CMOD_CSSAP]

Here is one of my upgrade plan.
Existing server details, serverA
0. Server is at Windows 2000, SP4
1. DB2 81 FP8
2. CMOD server 7.1.2.0
3. CMOD admin clinet 7.1.2.0
4. CMOD client 7.1.2.0
5. WAS 5.1.1.11
6. ODWEK 7.1.2.0
5. CSSAP 8.3 with an IFIX

The planned upgrade is on serverB
0. Windows 2008 server
1. DB2 9.7 FP3a
2. CMOD server 8.5 FP
3. CMOD admin client 85.
4. CMOD client 8.5
5. WAS 7.0 FP 15
6. ODWEK 8.5
7. ICC4SAP 2 (or CSSAP8.4)

Now the details
0. perform DB2 pre-req checks for upgrade to 9.7 from DB2 8.1 on serverA (there are tons of steps involved to check).
1. Install DB2 9.7 on serverA
2. Backup DB2 8.1 database offline
3. Upgrade instance, database and follow post processing.(on serverA)
4. Take an offline backup of database DB297 on serverA.
5. Install DB2 9.7 on new server serverB.
6. Install CMOD 8.5 (server, Admin client, windows client and configure DB, place the same path structure and userid/group). Verify CMOD install by logging on to both clients.(on serverB)
7. Install WAS 7.0, WAS updater, Apply fixpacks (on serverB)
8. Deploy ODWEK 8.5 (on serverB), verify.
9. Move DB2 9.7 backup database from serverA to serverB.
10. Restore DB from step 9 on serverB , verify, post process.
11. Apply DB Fixpacks on serverB.
12. Install configure CSSAP or ICC4SAP.(on serverB)
13. Start services of all and verify.
Am I missing anything? (There is no TSM, its kept local, customer wants to keep it that way).

[sandeepveldi]

I think there are some DB columns that are dropped from System Log tables for the CMOD versions 8.4 & above. I think you may have to do a manual drop on all the extra columns in the existing System Log tables.
I would suggest that you raise a PMR with IBM to get the exact details on this since you are planning to move from CMOD v8.3 to v8.5

Regards,
SV

[CMOD_CSSAP]

Are you saying the following?
https://www-304.ibm.com/support/docview.wss?rs=0&uid=swg21446135#830X

Alter the OnDemand database for use with V8.4.1 and later by running the following commands on your library server. These commands must be run as the OnDemand instance owner specified in the OnDemand Configurator on Windows or the ars.ini on all other platforms.
1. Mandatory. Alter the OnDemand database for V8.4.1 and later:
      arsdb -I instance_name -uv
      arsdb -I instance_name -mv   
2. Mandatory if you have Report Distribution installed. Run the following commands:
      arsdb -I instance_name -uRv
      arsdb -I instance_name -mRv
3. Optional, but recommended. Update the System Log application group for the longer 2000 character Message Text. If not performed SQL truncation warnings may be issued for certain System Log messages.
      arssyscr -I instance_name -l
      arstblsp -I instance_name -a 1 -g "System Log"
4. Optional. Create the System Load Application Group. Creating this application group will impact loading performance because a new row is inserted for every load.
      arssyscr -I instance_name -a

The other thing I found is 32bit/64bit issue(as 2008 OS is 64bit)
Migrating DB2 32-bit servers to 64-bit systems (Windows)

On the Windows operating systems, there are two ways to migrate your DB2® UDB Version 8 or DB2 Version 9.1 32-bit server to a DB2 Version 9.5 64-bit server.
0. Migrate your existing DB2 32-bit server to DB2 Version 9.5 32-bit server, and then upgrade to DB2 Version 9.5 64-bit server.
1. Migrate to a new computer where DB2 Version 9.5 64-bit database product is installed.

Chosen the second option(where OS is 200864 bit, and DB2 9.7  is installed).
In this case, maybe DB2 9.7 install work is not needed on serverA. Since DB2 8.1 FP8 is upgradable to DB2 9.7 version. So, taking an offline backup on serverA DB2 8.1 FP8 version database should be OK to restore in DB2 9.7 version.

What do you think now?

0. perform DB2 pre-req checks for upgrade to 9.7 from DB2 8.1 on serverA (there are tons of steps involved to check).
1. Install DB2 9.7 on serverB.
2. Backup DB2 8.1 database offline on serverA.
3. Install CMOD 8.5 (server, Admin client, windows client and configure DB, place the same path structure and userid/group). Verify CMOD install by logging on to both clients.(on serverB)
4. Run the two manadator and two optional commands
   arsdb -I instance_name -uv
   arsdb -I instance_name -mv   

         arsdb -I instance_name -uRv
         arsdb -I instance_name -mRv
Optional, but recommended.
         arssyscr -I instance_name -l
         arstblsp -I instance_name -a 1 -g "System Log"

         arssyscr -I instance_name -a
5. Move DB2 8.1 backup database from serverA to serverB.
6. Restore DB 8.1 FP8 from step 5 on serverB , verify, post process.
From this IBM document link for DB migration
http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.qb.migration.doc/doc/t0011000.html

Migrating to a new DB2 server

If you want to migrate to a new DB2® Version 9.5 server, you need to recreate your instances and then restore your DB2 Version 9.1 or DB2 UDB Version 8 databases from a database backup. After restoring the database backup, the RESTORE DATABASE command automatically runs the MIGRATE DATABASE command.
I am not worrying for 32 bit/64 bit(do I need to?)

7. Install WAS 7.0, WAS updater, Apply fixpacks (on serverB)
8. Deploy ODWEK 8.5 (on serverB), verify.
11. Apply DB Fixpacks on serverB.
12. Install configure CSSAP or ICC4SAP.(on serverB)
13. Start services of all and verify.

[Alessandro Perucchi]

Hello,

Your steps are good, except that as Sandeep said, you need to do the migration steps for CMOD.

So if I take your list, it should look like the following:


0. perform DB2 pre-req checks for upgrade to 9.7 from DB2 8.1 on serverA (there are tons of steps involved to check).
1. Install DB2 9.7 on serverB.
2. Backup DB2 8.1 database offline on serverA.
3. Install CMOD 8.5 (server, Admin client, windows client and configure DB, place the same path structure and userid/group).
4. Move DB2 8.1 backup database from serverA to serverB.
5. Restore DB 8.1 FP8 from step 5 on serverB , verify, post process.
From this IBM document link for DB migration
http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.jsp?topic=/com.ibm.db2.luw.qb.migration.doc/doc/t0011000.html

Migrating to a new DB2 server

If you want to migrate to a new DB2? Version 9.5 server, you need to recreate your instances and then restore your DB2 Version 9.1 or DB2 UDB Version 8 databases from a database backup. After restoring the database backup, the RESTORE DATABASE command automatically runs the MIGRATE DATABASE command.
I am not worrying for 32 bit/64 bit(do I need to?)

7. Install WAS 7.0, WAS updater, Apply fixpacks (on serverB)
8. Deploy ODWEK 8.5 (on serverB), verify.
11. Apply DB Fixpacks on serverB.
12. Run the two manadator and two optional commands
   arsdb -I instance_name -uv
   arsdb -I instance_name -mv   

         arsdb -I instance_name -uRv
         arsdb -I instance_name -mRv
Optional, but recommended.
         arssyscr -I instance_name -l
         arstblsp -I instance_name -a 1 -g "System Log"

         arssyscr -I instance_name -a
13. Install configure CSSAP or ICC4SAP.(on serverB)
14. Start services of all and verify.


Cheers,
Alessandro

[sandeepveldi]

Even though the technote says that the "System Log" table step is an optional one, we were not able to access the system log data created before the upgrade. So, I would recommend that you do all the optional steps as well and also make sure that you are using the 64 bit versions of OS, database, TSM when you doing an upgrade to CMOD v8.5

Regards,
SV

[CMOD_CSSAP]

It's all taken care.

Once database is restored. the following was my reality.
0. Login to admin client fails with sql 206N , ARSAG.SM_CACHE_DELTA is not valid on context where it is used. SQLSTATE 42S22.
1. Ran the following successful. arsdb -I instance_name ?uv    It alters many tables.
2. Ran arsdb -I instance_name -mv     This ran with error sql 2216
3. Ran db2 reorg table arsag successfully.
4, Now ran arsdb -I instance_name ?uRv, all went successful, except one table ARSRDREPDT  Which is OK as we dont have the reporting tool installed.
5. Now ran this arsdb -I instance_name ?mRv  and failed with sql 2201 on table ARSRDBUNDT
6. Ran the reorg for ARSRDBUNDDT, successful
7. Ran arssyscr -I instance_name ?l and failed to reorg a table ARSGFLD, ran the reorg for the table ARSGFLD, reran, successful.
8.Ran this arstblsp -I instance_name -a 1 -g "System Log"   successfully.
9. Able to start services, log into admin client, see all details successful. Logged in with various otehr users, went fine.
10. Successfully logged in to use windows client as well.


Thanks all.