Replicated VOB considerations

The checkvob command is a per-replica operation. You run it to achieve local pool or database consistency. The checkvob command does not create oplog entries for its updates. (In fact, this is a requirement; in a VOB replica restoration scenario, checkvob must be able to run before restorereplica.) To synchronize replicas after running checkvob –fix, run the restorereplica command.

When fixing a data loss (missing container) problem, checkvob does not search other replicas for missing containers or version data. Similarly, after the current replica's database is updated with rmver –data to reflect missing version data, you cannot use Rational® ClearCase MultiSite® to repopulate this database with version data from another replica. If you choose this approach (create new branches and versions, move labels, and so on), version selection based on config records is not affected; the old versions (now with no version data) are still selected.

Data loss (missing containers) at the current replica does not affect synchronization exports or imports. Data loss at the current replica can be propagated only with mkreplica. In this case, the new replica inherits the “lost data” state. For example, if data loss occurs on the replica that created the lost version, there are two synchronizing export scenarios:

Subsequent export packet contains a dataless “create version” operation (as if rmver –data followed checkin).
The system appends a comment at the end of the event record for a dataless sync-import “create version” event. The additional text says that a dataless checkin occurred, and it identifies the replica (OID) from which this dataless “create version” originated.
A full data create-version operation was already propagated to a sibling replica. The sibling replica retains the data.