–exp/ort[
–cl/an clan-name ] [ –site site-name ] –fam/ily family-name
–u/ser username [–p/assword] password
[–max/size size ] [–c/omments comments ]
[–size id-block-size ] [ –thres/hold id-block-threshold ]
{
{–sh/ip | –fsh/ip} -wor/kdir temp-dir-pname
[–sc/lass storage-class ]
[ –pex/pire date-time ]
[–not/ify e-mail-addr ]
| –out packet-file-pname } hostname:site-name ...
–imp/ort
{ –site site-name–repo/sitory db-info [ –vendor
vendor-type ] db-params
}
{ [ –data/base db-info [ –vendor vendor-type ] db-params
[ –c/omments comments ] { packet-file-pname|packet-dir-path }...
–imp/ort {
[–cl/an clan-name ] [ -site site-name ] –u/ser username
[–p/assword ] password { –data/base db-info
[ –vendor vendor-type ] db-params
[ –c/omments comments ] { packet-file-pname|packet-dir-path }...
The mkreplica –export command may take a long time. The database and the schema repository are locked while an export is in progress. Make sure that all users are logged out before you run mkreplica –export.
The creation of a new replica is a three-phase process:
At each new site, the administrator must create empty vendor databases for the replica data. If this is the first replica in the new site, you need at least two empty vendor databases, one for the schema repository replica and one for the user database replica.
When a database is replicated for the first time, the database's operation log (oplog) is enabled. All operations to be replicated are recorded in the oplog. Logging of operations continues until all replicas are deleted, leaving only the original database set. Creation of additional replicas is recorded in oplog entries. Existing replicas learn about a new replica through the standard synchronization mechanism.
MultiSite controls how many record ID numbers are allocated to each replica. This allocation is done by using ID blocks (groups of IDs).
By default, each replica is given an ID block of 4096 IDs when it is created. When a replica reaches a threshold of 1024 IDs left to use, it is allocated another ID block of 4096 IDs to ensure that all IDs are unique. ID block allocation is handled internally by the working schema repository during synchronization.
Depending on the activity level of a replica family, it may be helpful to increase the size of the ID blocks that are allocated to a replica. For example, with the default settings, if you try to submit a large number of defects, the first 4096 are submitted successfully, but submissions after that fail.
To control how many IDs a replica is allocated, you can use the –size option combined with the –threshold option when you create a replica with the mkreplica –export command. You can modify these settings with the chreplica command.
Each invocation of mkreplica –export creates a single logical replica-creation packet. (This is true even if you create several new replicas with one mkreplica command.) Each packet includes one or more replica specifications, each of which indicates the new replica's name and the synchronization server associated with the new replica.
The user database and schema repository are locked during the export phase.
The –maxsize option divides the single logical packet into multiple physical packets to conform to the limitations of the transfer medium.
If a replica import is interrupted or fails for any reason (a power outage, for example), you must delete the vendor databases, create new vendor databases for the failed import operation, and rerun mkreplica –import.
It is possible to have a successful import of the schema repository, but a failed import of the user database replica. In this case, you must delete and re-create the vendor database that was intended for the user database replica.
Replica-creation packets are not deleted after import. After you import a replica-creation packet with mkreplica –import, you must delete the packet.
If a packet cannot be delivered, it is sent through the store-and-forward facility back to the administrator at the site of the originating replica. A mail message is sent to the store-and-forward administrator. This occurs after repeated attempts to deliver the packet have failed and the allotted time has expired; it can also occur when the destination host is unknown or a data file does not exist. The store-and-forward configuration settings specify the expiration period, the e-mail address of the administrator, and the notification program.
Locks: This command fails if the database is locked (for example, during the upgrade process) or while another Rational ClearQuest MultiSite operation is being performed.
Other: You cannot replicate a database to a host running a different version of MultiSite. You can run mkreplica –export at any site; however, you should always run it at the working schema repository site to avoid the creation of multiple sites with the same name.
Site: Current site. If there is more than one site on this host, –site is required.
Family: No default; you must specify a family.
Schema repository family: Not applicable. When you run mkreplica, the associated schema repository of the user database family you specify is included in the replica-creation packet.
Default: None.
–fship (force ship) invokes shipping_server to send the replica-creation packet. –ship places the packet in a storage bay. To send the packet, invoke shipping_server.
The disk partition where the storage bay is located (on the sending host and the receiving host) must have available space equal to or greater than the size of the replica-creation packet.
Default: mkreplica places the packet in the storage bay location specified for the cq_default class.
The replica-creation packets are not delivered automatically; use an appropriate method to deliver them. You can create a packet using –out, and subsequently deliver it using the store-and-forward facility.
The date-time argument can have any of the following formats:
Specify the time in 24-hour format, relative to the local time zone. If you omit the time, the default value is 00:00:00. If you omit the date, the default value is today. If you omit the century, year, or a specific date, the most recent one is used. Specify UTC if you want the time to be resolved to the same moment in time regardless of time zone. Use the plus (+) or minus (-) operator to specify a positive or negative offset to the UTC time. If you specify UTC without hour or minute offsets, the default setting is Greenwich Mean Time (GMT). (Dates before January 1, 1970 Universal Coordinated Time (UTC) are not valid.)
If a failure occurs on a Windows host that does not have e-mail notification enabled, a message is displayed in the Windows Event Viewer. The message includes the e-mail-address value specified with this option and a note requesting that this user be informed of the status of the operation.
hostname can be either the IP address of the host, or the computer name, for example, minuteman. You may have to append an IP domain name, for example, minuteman.purpledoc.com.
On Linux and the UNIX system, use the uname –n command to display the computer name. On Windows, the computer name is accessible from the System icon in the Control Panel. On Windows 2000, click the Network Identification tab. On Windows® Server 2003, click the Computer Name tab.
When you import a replica, you must specify the database parameters of the vendor database for the schema repository replica and the vendor database for the user database replica. You must create these databases before importing a replica packet.
If you also specify one or more packet-dir-path arguments, mkreplica searches for additional packets in these directories.
Site: Current site. If there is more than one site on this host, –site is required.
Specifying db-info and db-paramsfor DB2, Oracle and Microsoft SQL Server
Each database vendor has a default port number:
Vendor | Default port |
---|---|
DB2 | 50000 |
Oracle | 1521 |
Microsoft SQL Server | 1433 |
If your database uses a different port, you must specify it using the connect-options parameter. For example, if you have an Oracle database on port 1526, enter the following command:
multiutil mkreplica -imp -site SITEA -repo CQDEV -server cqsvr3 -vendor ORACLE -dbo admin_1 admin_1 -con PORT=1526 -data CQDEV -server cqsvr3 -vendor ORACLE -dbo admin_2 admin_2 -con PORT=1526 C:\TEMP\admin\mk_SITEA.xml
Important: For more information about the supported values for the vendor databases, see the "Vendor database properties" topic in the Administering Rational ClearQuest section of the Help.
If you also specify one or more packet-dir-path arguments, mkreplica searches for additional packets in these directories.
Default: None.
multiutil mkreplica -export -clan telecomm -site boston_hub -family DEV
-u susan -p passwd -out c:\cqms\boston_hub.xml goldengate:sanfran_hub
Multiutil: Packet file `c:\cqms\boston_hub.xml' generated
multiutil mkreplica -export -clan telecomm -site boston_hub -family LAB
-user susan -p passwd -out c:\cqms\lab.xml goldengate:sanfran_hub
Multiutil: Packet file `c:\cqms\lab.xml' generated
multiutil mkreplica -export -clan testing -site tokyo -family TEST
-user masako -p passwd -fship -workdir c:\cqms\working -sclass
cq_default taronga:sydney
Multiutil: Packet file
`c:\cqms\working\mk_TOKYO_29-January-02_09-47-27.xml' generated
multiutil: Shipping order
"C:\temp\cqms\ms_ship\outgoing\sh_o_mk_TOKYO_29-January-02_09-47-27.xml"
generated.
multiutil: Attempting to forward/deliver generated packets...
multiutil: -- Forwarded/delivered packet
C:\temp\cqms\ms_ship\outgoing\mk_TOKYO_29-January-02_09-4
multiutil mkreplia -export -clan telecomm -site boston_hub -family DEV
-user susan -password passwd -c "make a new replica for sanfran_hub"
-ship -workdir c:\temp\working -sclass cq_default
-pexpire 22-November-2003
goldengate:sanfran_hub
multiutil mkreplica -import -site sanfran_hub
-repository sanfran_schemarepo
-vendor SQL_SERVER -server sb_server -dbologin jcole passwd
-database sanfran_userdb -vendor SQL_SERVER
-dbologin jcole passwd
multiutil mkreplica -import -clan testing -site sydney -user bfife
-p passwd -database syd_userdb -vendor SQL_SERVER
-dbologin bfife passwd