Copying a DCM database using pack and unpack

You can use the pack and unpack commands to duplicate an existing DCM database. The database that is to be packed must be initialized to use DCM.

About this task

There must be an active server and sufficient disk space where the database is to be unpacked. You can pack a database from a Windows server and unpack it on a UNIX server if you use the ccmdb upgrade /w command. For more information, see Moving databases between UNIX and Windows .

The pack operation includes the generate_directory and receive_directory. Therefore, all outstanding transfer or receive operations must be resolved before packing the database.

Note: When a database is unpacked or copied, the project work area paths of the new database are the same as the work area paths in the original database. To avoid possible conflicts, these paths must be changed before the new database is used. For details, see Finding and replacing a character string in a work area path.

Procedure

  1. Make sure that there are no active sessions running on the database that is to be packed.
  2. Protect the database that is to be packed (see the ccm monitor and ccmdb protect commands).
  3. Pack the DCM database.

    > ccmdb pack database_path /to packfile

    For Windows, database_path must be a UNC path.

    > ccmdb pack <database_path> /to packfile
    The resulting packed file is called database_name.cpk.
  4. Unpack the DCM database, and give it a new name.

    > ccmdb unpack database_name.cpk /t new_database_path\new_database_name /s server_name

    For Windows, new_database_path must be a UNC path.

  5. Change the work area paths.
  6. Change the DCM database ID.
    1. Start a session on the new database as ccm_admin.
    2. Protect the new database.
    3. Change the DCM database ID without updating objects to an ID that is unique in the DCM cluster. See Changing the database ID without updating objects.
    4. Exist from the session
  7. Set up the original database to send transfer packages to the new database.
    1. Unprotect the original database (see the ccmdb unprotect command for details).
    2. Start a session on the original database.
    3. Protect the original database so that no one else can start a session on it.
    4. Create a destination database definition for the new database. See Creating a database definition.
    5. Create and add objects to transfer sets for any transfer packages to be sent from the original to the new database. See Creating a transfer set.
    6. Initialize the new transfer sets.
    7. Generate transfer packages for each new transfer set, with Last Generated Time set to Current Time. The setting prevents unnecessary transfers. (That is, objects in the newly unpacked database are not sent by the original database). Moreover, only objects that have changed since the original database was unprotected are eligible to be transferred to the new database.
    8. Exit from the session.
  8. Unprotect the new database.
  9. Set up the new database to send transfer packages to the original database (optional).
    1. Start a session on the new database.
    2. Protect the new database so that no one else can start a session.
    3. Create a destination database definition for the new database. See Creating a database definition.
    4. Create and add objects to transfer sets for any transfer packages to be sent from the new to the original database. See Creating a transfer set.
    5. Initialize the new transfer sets.
    6. Generate transfer packages for each new transfer set, with Last Generated Time set to Current Time. The setting prevents unnecessary transfers. (That is, objects that were obtained from the original database are not sent back to it). Moreover, only objects that have changed since the new database was unprotected are eligible to be transferred to the original database.
    7. Exit from the session.
    8. Unprotect the new database.
    9. Unprotect the original database.

Feedback