Steps to move from SQL 2008 to SQL 2012 on RTC 4.0.6
We're getting ready to move the databases and I want to make sure I am not missing any steps. One big question is do I need to go through the "server rename process" when only changing the DB server and not the App server?
run server.shutdown on app server
Copy databases to the new server
All databases will be renamed - does this cause any issues?
Backup and edit the following files - update with new DB server and new DB names (plus new passwords if different):
conf/jts/teamserver.properties
conf/jazz/teamserver.properties
Rebuild indexes:
repotools-jts.sh -rebuildTextIndices
repotools-jts.sh -reindex
repotools-jazz.sh -rebuildTextIndices
repotools-jazz.sh -reindex
Remove temp files from:
server/tomcat/temp/*
server/tomcat/work
run server.startup
Am I missing anything? Is there a repotools command I should run to test the new DB setup? Unfortunately, since I can't actually test this on a different app server without running the Server Rename Process due to the change of the Production app server to the Test app server, I will be doing this in Production without a full test. Rollback plan is to restore backups of the teamserver.properties files and reindex.
run server.shutdown on app server
Copy databases to the new server
All databases will be renamed - does this cause any issues?
Backup and edit the following files - update with new DB server and new DB names (plus new passwords if different):
conf/jts/teamserver.properties
conf/jazz/teamserver.properties
Rebuild indexes:
repotools-jts.sh -rebuildTextIndices
repotools-jts.sh -reindex
repotools-jazz.sh -rebuildTextIndices
repotools-jazz.sh -reindex
Remove temp files from:
server/tomcat/temp/*
server/tomcat/work
run server.startup
Am I missing anything? Is there a repotools command I should run to test the new DB setup? Unfortunately, since I can't actually test this on a different app server without running the Server Rename Process due to the change of the Production app server to the Test app server, I will be doing this in Production without a full test. Rollback plan is to restore backups of the teamserver.properties files and reindex.
One answer
Mike, if SQL server does the upgrade of the DB for you, you don't need any repotools commands. You would otherwise use repotools export and import to migrate the database (e.g. if changing vendor or if there is no way to upgrade the data otherwise such as different architectures).
If you change the database server and/or name you have to make sure the database connection properties in the teamserver.properties files get fixed.
And I would suggest a full backup before you do all this.
If you change the database server and/or name you have to make sure the database connection properties in the teamserver.properties files get fixed.
And I would suggest a full backup before you do all this.
