Reversing DB2® server upgrade involves creating a plan using
the steps in this procedure to fall back to the DB2 release from which you upgraded your DB2 server. There is no utility
to fall back to a previous release of DB2 database
after upgrading your DB2 server.
Performing
an upgrade in a test environment will help you identify any issues
with the process and avoid having to reverse the upgrade.
Before you begin
Ensure that you have SYSADM authority, as well as root on Linux and UNIX operating systems or Local Administrator
authority on Windows operating
systems.
- Perform the following steps before upgrading your DB2 server:
Keep your existing pre-DB2 Version 10.1 copy during upgrade of your DB2 server. To do this, select the Install
New option to create a new copy when installing DB2 Version 10.1. Do not select the Work with an existing option
and then choose a pre-DB2 Version 10.1 copy with the upgrade action
that is available on Windows operating
systems.
Keep all the S*.MIG files in the active
log path in case you want to rollforward through these log files after
reversing the upgrade. For recoverable databases, the UPGRADE
DATABASE command renames log files in the active log path
with the extension .MIG.
Restrictions
- This procedure applies only to DB2 server
upgrade. It does not include DB2 clients.
- In partitioned database environments you must perform this procedure
on all participating database partition servers. If you have several
database partitions on a partition server, execute tasks at the database
level, such as backup and restore, on each database partition.
- Additional upgrade
restrictions apply. Review
the complete list.
Procedure
To reverse a DB2 server
upgrade, you need to perform the following steps:
- Log on to the DB2 server
as a user with SYSADM authority.
- Drop all databases in DB2 Version 10.1 by running the DROP DATABASE command.
- Log on to the DB2 server
as root on Linux and UNIX operating systems or a user
with Local Administrator authority on Windows operating
systems.
- Drop your DB2 Version 10.1 instances by running the db2idrop command.
This command does not remove the database files; you need to drop
your databases before dropping your instances.
- If you upgraded your pre-DB2 Version 10.1 instances to DB2 Version 10.1, re-create your instances in the pre-DB2 Version 10.1 by running the db2icrt. Then restore
the database manager configuration parameter values for each instance
using the UPDATE DATABASE MANAGER CONFIGURATION command.
- For each pre-DB2 Version 10.1 instance, log on to the DB2 server
as the instance owner and restore your upgraded databases from a pre-DB2 Version 10.1 offline full backup by running the RESTORE
DATABASE command. You cannot upgrade your databases from
DB2 Version 10.1 to pre-DB2 Version 10.1 release.
If you recreated the instances
using the same instance owner they had before upgrade and you did
not upgrade a database to a DB2 Version 10.1 instance, the database is still in pre-DB2 Version 10.1 release and you can access it by just re-cataloging
it.
- If you have recoverable databases and you want to rollforward
through the log files you had before the upgrade, rename all the S*.MIG files
in the active log path using the .LOG extension
and issue the ROLLFORWARD DATABASE command as shown
in the following example on Windows operating
system:
cd E:\DB2_01\NODE0000\SQL00001\LOGSTREAM0000
dir S*.MIG
...
25/02/2008 10:04 AM 12,288 S0000000.MIG
25/02/2008 10:10 AM 12,288 S0000001.MIG
25/02/2008 09:59 AM 4,104,192 S0000002.MIG
25/02/2008 10:10 AM 4,104,192 S0000003.MIG
25/02/2008 10:19 AM 4,104,192 S0000004.MIG
5 File(s) 12,337,152 bytes
2 Dir(s) 4,681,842,688 bytes free
rename S*.MIG S*.LOG
dir S*.LOG
...
25/02/2008 10:04 AM 12,288 S0000000.LOG
25/02/2008 10:10 AM 12,288 S0000001.LOG
25/02/2008 09:59 AM 4,104,192 S0000002.LOG
25/02/2008 10:10 AM 4,104,192 S0000003.LOG
25/02/2008 10:19 AM 4,104,192 S0000004.LOG
5 File(s) 12,337,152 bytes
2 Dir(s) 4,681,842,688 bytes free
db2 ROLLFORWARD DB sample TO END OF LOGS AND STOP