Replica Creation Scenario


For the example in this section, the company’s software development takes place in Boston and in a new development office in San Francisco. Work is about to begin on a new release.

Relevant characteristics of the two sites:

Location
Synchronization server
Replica name (site name)
Boston
minuteman
boston_hub
San Francisco
goldengate
sanfran_hub

Prerequisites

Before you create a new replica, you must perform these steps at the original site:

  1. Make sure MultiSite licenses are installed.
  2. After you enter the activate command for a database set, users at the original database cannot access it without a MultiSite license (in addition to a ClearQuest license).

  3. When you create a replica of a specific database for the first time, all users must log off the database.
  4. The mkreplica –export command locks the database after you start to export the replica. All users must log off before the procedure begins and log on after it is finished. Data is lost if sessions are left open during the replication process.

  5. If you use the ClearCase/ClearQuest UCM integration, you must terminate all cqintsrv processes before running the first mkreplica –export on the schema repository.
  6. Determine the size of the user database and schema repository.
  7. Replica-creation packets can be four times as large as the respective databases. Verify that the working directory you use has enough free space. You must have write permission for the directory, and the directory you specify must not exist.

Activating the Database Set

The following command activates the database set in Boston. It names the clan telecomm and the site boston_hub, and it specifies minuteman as the synchronization server.

multiutil activate –user susan –password passwd –clan telecomm –site boston_hub 
–host minuteman 

Export Phase

In Boston, perform the following steps.

  1. Use the mkreplica –export command to create the replica for San Francisco.
  2. The following command creates the sanfran_hub replica of the PRODA user database in the telecomm clan. It also creates the sanfran_hub replica of the schema repository in the telecomm clan. The synchronization server for the new site is goldengate. The administrator uses the –fship option to send the packet immediately using the Rational Shipping Server.

    multiutil mkreplica –export –clan telecomm –site boston_hub –family PRODA 
    –user susan –password passwd –maxsize 50m –fship –workdir c:\temp\packets 
    –sclass cq_default goldengate:sanfran_hub 
  3. Back up the newly replicated database.
  4. This backup records the fact that the database is replicated. If you try to restore a database from a backup copy that was made before the database was replicated, the replica restoration procedure fails. (Although the restorereplica command may succeed, you cannot import update packets from other replicas because the original database is marked as unreplicated.)

Transport Phase

  1. Send the replica-creation packet to the new site. This process differs depending on the options you used in Step 1:
    • If you used –fship, the packet was sent to the new site immediately.
    • If you used –ship, you must run shipping_server to send the packet to the new site. For example:
    • shipping_server –sclass cq_default –poll

    • If you used –out to write the packet to a file, you must transport the file to the new site.

Import Phase

These steps take place in San Francisco, which has no replicas in the clan.

  1. If you used store-and-forward, verify the packet’s arrival by entering the lspacket command on the synchronization server.
  2. multiutil lspacket –short 
    Multiutil:Packet 
    ’d:\temp\ms_ship\incoming\mk_sanfran_hub_21-May-01_19-28-01.xml’...
  3. Create empty vendor databases for the new schema repository and user databases.
  4. Enter the import form of the replica-creation command.
  5. In the mkreplica –import command, you must specify the pathname of the incoming packet as listed by the lspacket command. For example:

    multiutil mkreplica –import –site sanfran_hub –repository ORC1 –vendor 
    ORACLE –dbologin orcadmin password –connectopts 
    host=sanfran_dbserver;SID=ORC1;server_ver:8.1;client_ver=8.0;log_type=long 
    –database ORC1 –vendor ORACLE ORC1 –dbologin orcuser password 
    –connectopts 
    host=sanfran_dbserver;SID=ORC1;server_ver:8.1;client_ver=8.0;log_type=long 
    –comments “Importing the initial replicas of the PRODA database and its 
    schema repository for the San Francisco site in the telecommunication clan” 
    d:\temp\ms_ship\incoming\mk_sanfran_hub_21-May-01_19-28-01.xml 
  6. Confirm that import was successful, and then delete the replica-creation packet. (Update packets are deleted automatically.)
  7. Begin development.
  8. Users in San Francisco can access the new replica in the same way they access an unreplicated database.