DB2 restore on another server crashes RTC on original server
Hi all,
I'm currently trying to set up a staging environment to test the RTC upgrade 6.0.6.1 -> 7.1.
I shut down RTC and did a DB2 BACKUP command to get database exported to files.
Then I copied these files to a new server and did DB2 RESTORE. When I did this the running RTC crashed on the original server saying in the log that JTS could not connect to the database due to authentication error.
Does anyone know if a DB2 RESTORE on a new server actually contacts the old server and does something?
I think I fixed it by setting SECADM and DBADM on my DB2ADMIN user on the original server. Then everything worked just fine again. Though I don't know if this is just a coincidence.
Cheers,
/Morten.
2 answers
1. There is a documentation about backup and restore
2. It mentions that there are multiple databases that require to be backed up, CCM and JTS are amongst them. Could be more.
3. You must make sure to run the restore and testing in an isolated environment to prevent the backup get entangled with the original.
I would suggest to carefully read the backup/upgrade documentation, perform the interactive guides and make sure you have a working backup.
Maybe get in contact with support to get guidance.
I think I found the answer. Both databases were hosted on the same SAN, and apparently the DB2 RESTORE function is so I/O heavy, that it hogged all the resources on the VM SAN. Therefore the database on our production system became unresponsive.
One thing to keep in mind if you are staging a test environment.