Question & Answer
Question
How do you restore an IBM Rational ClearCase source container in a MultiSite replicated VOB from a copy in another replica within the same family on Windows, UNIX or Linux?
Cause
Sometimes the source containers in a VOB become missing or corrupt and need to be replaced. The replacement container can come from a backup or from a copy in another replica within the same family. This technote provides instructions for the latter discussing how to replace a source container using a copy from another sibling replica.
Answer
THESE INSTRUCTIONS ARE ONLY FOR REPLACING A CONTAINER IN A REPLICATED VOB USING A CONTAINER FROM A SIBLING REPLICA.
- This technote assumes you have already made the determination that the container is missing or corrupt. It does not discuss how to make that determination, or the possible causes of the condition.
- This technote also assumes you have already made the decision to retrieve a container from a sibling replica as the data source for the replacement.
- If you are replacing the container from backup in a replicated VOB review technote 1221899.
- If you are replacing the container from backup in a non-replicated VOB review technote 1226698.
- If you know the file that has the problem, but are unsure of the container name.
(This could be the case if a user has reported a problem.)
Get a "cleartool describe" and "cleartool dump" of the version with a problem. It is easiest to do this in a view where the problem has been seen.
Example 1:
%>cleartool desc foo.c
version "/tmp/tag1/foo.c@@/main/2"
created 2010-05-04T13:24:43+10:00 by user1.group1@myworkstation
... SNIP ...
element type: text_file
... SNIP ...
%>cleartool dump foo.c
foo.c (41fbe138.ed0511d2.b552.00:01:80:86:79:de)
/tmp/tag1/foo.c@@/main/2
oid=41fbe138.ed0511d2.b552.00:01:80:86:79:de dbid=36 (0x24)
... SNIP ...
cont dbid=536870958 container="16/2e/0-41fbe138ed0511d2b5520001808679de-k5"
source cont="/net/host1/tmp/tag1.vbs/s/sdft/16/2e/0-41fbe138ed0511d2b55200018086
79de-k5"
clrtxt cont="/net/host1/tmp/tag1.vbs/c/cdft/2f/2b/41fbe138ed0511d2b5520001808679
de"
Proceed to step 3.
- If you know the name of the corrupt source container, but are unsure of the file name.
(This could be the case if the problem is detected by a failed MultiSite export.)
Get a "cleartool describe" and "cleartool dump" of the version with a problem. The version can be identified from the name of the source container, which is of the form xx-oooooooooooooooooooooooooooooooo-yy
The "oooooooooooooooooooooooooooooooo" is an OID, and an alternate name for the version is oid:oooooooooooooooooooooooooooooooo
Example 2:
multitool: Error: multitool: Error: Type manager "text_file_delta" failed construct_version operation.
text_file_delta: Error: "/tmp/tag1..vbs/s/sdft/16/2e/0-
41fbe138ed0511d2b5520001808679de-k5" is not a 'text file': it contains a '\000'.
This object's type (operation "construct_version") does not support binary data.
multitool: Error: multitool: Error: Type manager "text_file_delta" failed construct_version operation.
multitool: Error: multitool: Error: Could not get statistics of the version data file for this operation.
%>cleartool desc oid:41fbe138ed0511d2b5520001808679de
version "/tmp/tag1/foo.c@@/main/2"
created 2010-05-04T13:24:43+10:00 by user1.group1@myworkstation
... SNIP ...
element type: text_file
... SNIP ...
%>cleartool dump oid:41fbe138ed0511d2b5520001808679de
foo.c (41fbe138.ed0511d2.b552.00:01:80:86:79:de)
/tmp/tag1/foo.c@@/main/2
oid=41fbe138.ed0511d2.b552.00:01:80:86:79:de dbid=36 (0x24)
... SNIP ...
cont dbid=536870958 container="16/2e/0-41fbe138ed0511d2b5520001808679de-k5"
source cont="/net/host1/tmp/tag1.vbs/s/sdft/16/2e/0-41fbe138ed0511d2b55200018086
79de-k5"
clrtxt cont="/net/host1/tmp/tag1.vbs/c/cdft/2f/2b/41fbe138ed0511d2b5520001808679
de"
- Take note of the element type and the container paths as highlighted in the examples above.
There are three basic source container formats and it is important to know which type of container is being used before proceeding.
A single container for each version such as a binary file.
A single container for all versions such as a text file.
A single container for each branch such as a binary delta type.
Note For binary delta type of element the zero version of the branch will belong to the source container of the of the parent branch.
Note the replacement source container and the one being replaced must be the same type. So if the file type has been changed in either location it must be changed back before proceeding.
The source file prefix can assist in confirming this but noting the element type ouput of cleartool describe is the most reliable method.
For example if the element type is "file" it has a prefix of 2, and a compressed_file has a prefix of 3.
If these do not match between replicas use cleartool describe to verify the type and cleartool dump to verify that it is the correct source file.
Check whether the source container exists. If there is a corrupt container there, then remove it from the VOB storage.
If there is a cleartext container and you know it has the correct content, you may leave it there. If you are following this instruction and the cleartext container exists, it is probably invalid and should be removed.
It is left to the reader to decide whether to keep the corrupt container. It maybe useful for determining root cause of corruption, but not for anything else. The remainder of these instructions assume we are treating a missing container condition.
- Use multitool lsepoch to determine which replica is the most up to date concerning local information. Hereafter, "remote" will refer to the "most-up-to-date" remote replica.
- At the "remote" replica get a "cleartool dump" of the version with the problem. Use the OID name as in step 2, or make sure you are using the same view config spec as used in step 1. Verify that the dump shows the same OID.
It is expected that the DBID will be different.
Note that the version may not exist at the remote replica !
cleartool: Error: Not a vob object: "41fbe138.ed0511d2.b552.00:01:80:86:79:de"
If the dump DOES succeed, then proceed to step 6.
If the version does not exist (replica synchronization never succeeded for that version)
AND the element type is either "file" or "compressed_file" then there is no chance to retrieve the container from the remote replica. The version will have to be marked "ndata" at the local replica using checkvob. Proceed to step 9.
If the version does not exist (replica synchronization never succeeded for that version)
AND the element type is neither "file" nor "compressed_file" ("text_file" for example) then we instead get a "cleartool dump" from a version which shares the same source container. For many element types ("text_file" for example) this can be any version of the element, including /main/0. For some element types it must be another version on the same branch, including the .../branch/0. We recommend you get a "cleartool dump" of this other version at the local replica to verify it also reference the same missing source container, then get a "cleartool dump" at the remote replica.
Using the example above you might do
%>cleartool dump foo.c@@/main/0
foo.c (f27e2951.380d4195.8c64.d5:28:88:13:c0:f8)
/tmp/tag1/foo.c@@/main/0
oid=f27e2951.380d4195.8c64.d5:28:88:13:c0:f8 dbid=33 (0x21)
... SNIP ...
cont dbid=538058346 container="16/2e/0-41fbe138ed0511d2b5520001808679de-k5"
source cont="/net/hostess/vobstore/tag1.vbs/s/sdft/16/2e/0-41fbe138ed0511d2b5520
001808679de-k5"
clrtxt cont="/net/hostess/vobstore/tag1.vbs/c/cdft/7/1b/f27e2951380d41958c64d528
8813c0f8"
- Now you have a "cleartool dump" at the remote replica. Take note that the source container name is almost certainly different from the name of the container being replaced.
%>cleartool dump foo.c
foo.c (c95013c5.8e07460d.b2ac.e0:dc:b3:49:4d:c2)
/tmp/tag1/foo.c@@/main/1
oid=c95013c5.8e07460d.b2ac.e0:dc:b3:49:4d:c2 dbid=631 (0x277)
... SNIP ...
cont dbid=565907863 container="10/9/0-c95013c58e07460db2ace0dcb3494dc2-qx"
source cont="/net/host1/tmp/tag1.vbs/s/sdft/10/9/0-c95013c58e07460db2ace0dcb3494dc2-qx"
clrtxt cont="/net/host1/tmp/tag1.vbs/c/cdft/6/1a/c95013c58e07460db2ace0dcb3494dc2"
Where the container name is of the form xx-oooooooooooooooooooooooooooooooo-yy
yy will almost certainly be different
oooooooooooooooooooooooooooooooo maybe the same or different
xx should be the same
If "xx" is different, abandon this procedure as it will not work. Contact Rational Client Support for further advice.
It is an indication there has been a recent "chtype" to change the element type, and the change has not been replicated.
Assuming "xx" matches, transfer this file to the local replica site.
If you use FTP be sure to use a binary (image) transfer.
FTP ASCII transfer can corrupt even a text_file source container.
- element type is either "file" or "compressed_file" only
Copy / move the transferred container to the location of the missing container, renaming it to the name of the missing container.
The container replacement is complete!
- All other element types
Copy / move the transferred container to the folder/directory of the missing container.
DO NOT rename it to the name of the missing container.
For the process to work the container name must
a) have the same xx- prefix as the missing container
b) have a different name from the missing container.
If by some coincidence the replacement container DOES have exactly the same name as the missing container, then rename it by, for example, adding a ".1" suffix to the name.
- In a view, run "cleartool checkvob -fix <filename>"
The checkvob utility will build a new container using the transferred container as input. (It calls it an alternate related container.) The alternate container may have data for versions which have never been imported to the local replica. It may also be missing the data of versions that were never exported from the local replica.
Warning If checkvob is unable to find the data needed for all locally known versions, it will report all versions that are missing and wait for confirmation before committing any changes. If it proceeds the missing versions (/main/3 in the example below) should be marked as ndata. The VOB will remember the date and time of checkin and any labels etc for the version, but the data will be lost at this replica any attempt to read the content of the version will give an I/O error.
If checkvob warns of data loss but you think the data loss is avoidable, abandon the "checkvob" process and contact Rational Client Support for further advice. If data loss is accepted at this point but another backup source is found later, the data cannot be added back!
Example:
%>cleartool checkvob -fix foo.c
>The session's log directory is 'checkvob.12-Apr-99.12:18:23'.
>=================================================================
>Processing element "/tmp/tag1/foo.c@@".
>The element is now locked.
>Checking status of 1 referenced containers in pool "s/sdft"...
> 16/2e/0-cafbe174f0f211d2b5520001808679de-c3 (missing)
>Initial container status: 1 missing, 0 misprotected.
>Fixing element with 1 missing containers (out of 1)...
>Found 1 alternate related containers.
>Constructing new containers...
>.
>
>Unable to find the data (cleartext) of 1 versions (out of 4):
> 12-Apr-99.12:07:23 /main/3
>0 of these versions are "interesting" (i.e. have labels,
>sub-branches, attributes or hyperlinks).
>
>Do users want to continue and update the VOB database
>(including irreversibly making 1 versions 'ndata')? [no] y
>
>OK. Updating the VOB database...
>Cleaning up unused containers...
>Moving unreferenced containers to the pool's lost and found area...
>.
>The VOB database has been updated with the fixes.
>Final container status: 0 missing, 0 misprotected.
>1 new 'ndata' versions created.
>The element is now unlocked.
>=================================================================
The container replacement is complete!
If checkvob -fix fails with the following error:
cleartool: Error: Type manager "text_file_delta" failed get_cont_info operation.
cleartool: Error: Unable to process container
Review technote 1259721 for the corresponding explanation and workaround to the problem.
Related Information
[{"Product":{"code":"SSSH27","label":"Rational ClearCase"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"Backup and Restore","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"}],"Version":"7.0;7.0.0.1;7.0.0.2;7.0.0.3;7.0.0.4;7.0.0.5;7.0.0.6;7.0.0.7;7.0.0.8;7.0.1;7.0.1.1;7.0.1.2;7.0.1.3;7.0.1.4;7.0.1.5;7.0.1.6;7.0.1.7;7.1;7.1.0.1;7.1.0.2;7.1.1;7.1.2;8.0","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]
Was this topic helpful?
Document Information
Modified date:
16 June 2018
UID
swg21221900