DB2 10.5 for Linux, UNIX, and Windows
DB2 10.5 for Linux, UNIX, and Windows
A topology change involves adding members or dropping members from a DB2® pureScale® instance (explicitly or through restore), or restoring between a DB2 pureScale instance and a DB2 Enterprise Server Edition instance. Some topology change scenarios also allow restore followed by rollforward recovery.
A strict superset DB2 pureScale environment refers to an environment where all members in the backup image are defined in the target member topology; and the target member topology contains additional members. For example, the backup source member topology includes members 0 and 1, and the target member topology contains members 0, 1 and 2.
To restore the backup source member topology instance (containing two members) to the target member topology instance (containing three members):
db2 backup database sample to /dev3/backup db2 restore database sample from /dev3/backup db2 activate database sampleThese examples include an offline database backup image for a consistent database that is restored to a DB2 pureScale instance. However, the DB2 pureScale instance has a member topology that is not a superset of the source member topology in the backup image. This case could refer to strictly shrinking the topology (target member topology is a subset of the source member topology), both growing and shrinking (the intersection between the source and target member topology is not empty.) In all cases, there must be a common member between the source and target member topology. In addition, to ensure recoverability, following the restore you must perform either an incremental or full offline database backup.
A subset DB2 pureScale environment refers to an environment where not all members in the backup image are defined in the target member topology. For example, the backup source member topology includes members 0, 1, 2, and the target member topology contains members 0 and 1.
To restore the backup source member topology instance (containing three members) to the target member topology instance (containing two members):
db2stop
db2 backup database sample to /dev3/backup db2 restore database sample from /dev3/backup without rolling forward db2 backup database sample to /dev3/backup db2 backup database sample incremental to /dev3/backupTo restore the backup source member topology instance (containing three members) to the target member topology instance (containing two members):
This example restores a source member topology (containing members 0, 1) to the target member topology instance (containing members 1 and 2). In this case, the only common member between the two topologies is member 1.
db2stop
db2 backup database sample to /dev3/backup db2 restore database sample from /dev3/backup without rolling forward db2 backup database sample to /dev3/backup db2 backup database sample incremental to /dev3/backupStarting in V10.5, the mobility of backup images back and forth between ESE instances and a DB2 pureScale instance is supported. For steps, see Restore from DB2 pureScale Feature to DB2 Enterprise Server Edition or Restore from DB2 Enterprise Server Edition to DB2 pureScale instance.
An online backup results in a database that is in an inconsistent state. A database in an inconsistent backup requires a rollforward operation. However, a rollforward operation through a drop member event is not supported. Running the restore command results in an error message.
For recoverable databases, after a topology change you must take either an incremental or a full offline database backup for the database to be usable again. To ensure the recoverability of the database from that point in time, this recoverability is enforced by placing the databases in backup pending state.
A high risk workaround to this requirement, instead of running the BACKUP DATABASE command, you can run the db2dart command. However, any updates that are performed on the database are not recoverable until a full database backup is taken. This command has high risk of jeopardizing recoverability of the database, so it must be used only under the advisement of DB2 Service.
db2dart sample /CHST /WHAT DBBP OFFThe ROLLFORWARD DATABASE command supports the recovery through add member events. After the addition of a new member to a target topology, you do not need to take a database backup. Instead, you can restore a backup that is taken before the add member events took place. Then, perform a rollforward recovery to either the end of the transaction log or to any point in time after the add member events occurred. Inconsistent backups are also supported. Inconsistent backups are those backups when restored require a rollforward operation to bring the database back to a consistent point. In addition, a rollforward operation supports encountering add member events in the transaction logs and handle them transparently.
The members that do not exist in the backup image could be added during the rollforward operation as the add member log record is found (this is referred to as an explicit add). Or if the add member log record (AMLR) is not found, members could be added on the subsequent connect to those members (this is referred to as an implicit add).
Explicit add: a full database backup B0 for database sample is taken on a DB2 pureScale instance with a topology that includes only member 0. After some time of processing read/write transactions for this database on member 0, member 1 is added. Clients continue processing transactions both in member 0 and member 1. The backup image B0 is restored to a cluster with two members 0 and 1. The user initiates a rollforward operation through the transaction logs. The rollforward operation encounters an add member log record for member 1 before you reach the end of the logs.
db2 backup database sample to /dev3/backup db2iupdt -m -add db2 restore database sample from /dev3/backup db2 rollforward database sample to end of logs and stopImplicit add: a full database backup B0 for database sample is taken on a DB2 pureScale instance with a topology that includes only member 0. Process read/write transactions for this database on member 0. Backup image B0 is restored to a cluster with two members that is a superset of the source member topology: which includes members 0 and 1. Initiate a rollforward operation through the transaction logs, which does not find any events for member 1. In this case, after the rollforward completes, to use member 1, issue a CONNECT command (or ACTIVATE DATABASE command). Member 1 is added implicitly by either of these commands.
db2 backup database sample to /dev3/backup db2 restore database sample from /dev3/backup db2 rollforward database sample to end of logs and stopImplicit add at a point in time: a full database backup B0 for database sample is taken on a DB2 pureScale instance with a topology that includes only member 0. After some time of processing read/write transactions for this database on member 0, backup image B0 is restored to a cluster with two members that is a superset of the source member topology. This superset includes members 0 and 1. Initiate a rollforward operation through the transaction logs to a point in time before the add member event (instead of rolling forward to end of logs).
db2 backup database sample to /dev3/backup db2iupdt -m -add db2 restore database sample from /dev3/backup db2 rollforward database sample to 2013-04-03-14.21.56 and stop