db2inidb - Initialize a mirrored database command

If the instance that a database belongs to is changing, you must do the following to ensure that changes to the instance and database support files are made. If a database is being moved to another instance, create the new instance. The new instance must be at the same release level as the instance where the database currently resides.

You must issue this command before you can use a split-mirror database.

Authorization

Required connection

None

Command syntax

>>-db2inidb--database_alias--AS--+-SNAPSHOT---------+----------->
                                 +-+-----+--STANDBY-+   
                                 | '-ACS-'          |   
                                 '-MIRROR-----------'   

>--+----------------------------+------------------------------><
   '-RELOCATE USING--configFile-'   

Command parameters

database_alias

Specifies the alias of the database to be initialized.

SNAPSHOT

Specifies that the mirrored database will be initialized as a clone of the primary database.

STANDBY

Specifies that the database will be placed in rollforward pending state. New logs from the primary database can be fetched and applied to the standby database. The standby database can then be used in place of the primary database if it goes down.

ACS

Specifies that the db2inidb command is to be used against an ACS snapshot copy of the database to perform the STANDBY action. This option is required because the db2inidb command can only be issued against split mirror database snapshots created with the SET WRITE SUSPEND | RESUME command.

Together, the use of the ACS STANDBY option initiates the ACS snapshot copy to be placed into a rollforward pending state so that the DB2® BACKUP command can be successfully issued against the snapshot image. Without this, any attempt to connect to the snapshot image results in that copy of the database being placed in the RESTORE_PENDING state, removing its usefulness as a backup copy for future recovery.

This feature was introduced specifically for interfacing with storage managers such as IBM® Tivoli® Storage FlashCopy® Manager, for the purpose of producing an offloaded DB2 backup that is based upon an ACS snapshot. Using this option for any other purpose, to mount or modify the contents of an ACS snapshot copy, even including the production of a DB2 backup, can lead to undefined behavior in the future.

MIRROR

Specifies that the mirrored database is to be a backup image which you can use to restore the primary database.

RELOCATE USING configFile

Specifies that the database files are to be relocated based on the information listed in the configFile before the database is initialized as a snapshot, standby, or mirror. The format of configFile is described in db2relocatedb - Relocate database command.

Usage notes

Do not issue the db2 connect to database-alias operation before issuing the db2inidb database_alias as mirror command. Attempting to connect to a split mirror database before initializing it erases the log files needed during roll forward recovery. The connect sets your database back to the state it was in when you suspended the database. If the database is marked as consistent when it was suspended, the DB2 database system concludes there is no need for crash recovery and empties the logs for future use. If the logs have been emptied, attempting to roll forward results in the SQL4970N error message being returned.

In partitioned database environments, the db2inidb command must be issued on every database partition before the split mirror from any of the database partitions can be used. db2inidb can be run on all database partitions simultaneously using the db2_all command.

If, However, if you are using the RELOCATE USING option, you cannot use the db2_all command to run db2inidb on all of the partitions simultaneously. A separate configuration file must be supplied for each partition, that includes the NODENUM value of the database partition being changed. For example, if the name of a database is being changed, every database partition will be affected and the db2relocatedb command must be run with a separate configuration file on each database partition. If containers belonging to a single database partition are being moved, the db2relocatedb command only needs to be run once on that database partition.

If the RELOCATE USING configFile parameter is specified and the database is relocated successfully, the specified configFile will be copied into the database directory and renamed to db2path.cfg. During a subsequent crash recovery or rollforward recovery, this file will be used to rename container paths as log files are being processed.

If a clone database is being initialized, the specified configFile will be automatically removed from the database directory after a crash recovery is completed.

If a standby database or mirrored database is being initialized, the specified configFile file is automatically removed from the database directory after a rollforward recovery is completed or canceled. New container paths can be added to the db2path.cfg file after db2inidb has been run. This would be necessary when CREATE or ALTER TABLESPACE operations are done on the original database and different paths must be used on the standby database.

In DB2 pureScale® environments, you can issue the db2inidb command from any member and have to issue the command only once.