|
|
A VOB database maintains references to one or more view databases, and vice versa. When a VOB or view is restored from backup, the view and VOB are potentially out of sync; some of the references are no longer valid. This skew can cause a variety of problems.
View-private files can become stranded because the VOB directory element that they were cataloged in (or under) no longer exist in the VOB.
Elements can become "checked out but removed" when the VOB has recorded that the view has the element checked out, but the view doesn't have a view-private file for the element.
Elements can become eclipsed by a view-private file when the checkout that was once valid in the view is no longer recognized in the VOB. (The VOB says the element isn't checked out in the view.)
DO promotions can fail because the VOB records DO information about unshared DOs that don't exist.
Winked-in DOs become inaccessible when the VOB no longer contains the shared DOs. For example, this can occur if the VOB loses its DO pools and the shared DOs are removed by checkvob fix processing.
DOs are prevented from being scrubbed because the VOB has recorded stale reference counts for views (references that the view currently doesn't have).
There are a several things you can do to correct the skew and identify and/or eliminate the problems. You can take action immediately following VOB or view restore, or you can wait until problems surface.
When a view is restored, perform the resynchronization described in Resynchronizing Views and VOBs on the restored view.
When a VOB is restored, resynchronize it on each view it references. To collect this view list, navigate to the Referenced Views subnode for the VOB storage node in the ClearCase Administration console or run the following command:
cleartool describe -long vob:restored-vob
NOTE: The Referenced Views subnode and the cleartool describe command do not list views whose only interaction with the VOB has been to wink in DOs from the VOB. You must find and resynchronize any such views as well.
To resynchronize views and VOBs:
(Dynamic views only) Run cleartool recoverview -synchronize. This command recovers stranded view-private files. If a view was restored, synchronize it with all of the VOBs. If a VOB was restored, you can restrict the recovery synchronization to the restored VOB. See the recoverview reference page for more information.
For a dynamic view, inspect the list of checked-out files in the Private Files subnode of the view storage node in the ClearCase Administration Console or run cleartool lsprivate -co. For a snapshot view, run cleartool ls -recurse -view_only. Look at the output for any checkouts that are marked as "checked out but removed."
If the VOB was restored, this probably means that the user had once checked out the element but then resolved the checkout (uncheckout or checkin) at some point more recent than the restored VOB's backup time. If it was a checkin, the data has been lost.
If the view was restored, any view-private modifications to the checked-out element have been lost.
In either case, the user must now cancel the checkout (uncheckout) or re-create the version data and check it in.
For a dynamic view, inspect the list of files in the Private Files subnode of the view storage node in the ClearCase Administration Console or run cleartool lsprivate -other -long. For a snapshot view, run cleartool ls -recurse -view_only. Look at the output for any elements that are marked as "eclipsed."
If the VOB was restored, the user had probably checked out the element at a time more recent than the restored VOB's backup time. If the view was restored, this probably means that the user had checked out the element but canceled the checkout later on, or had checked in the version data now present in the restored view.
If the version had been checked in, the eclipsing view-private file can be removed and the user can check out a new version and continue working. If the version had not been checked in, the eclipsing view-private file may still contain the most recent changes. In this case, it must be moved aside (renamed, not removed) so that the a new version of the element can be checked out to hold these changes.
(Dynamic views only) View the list of derived objects in the Private Files subnode of the view storage node in the ClearCase Administration Console or run cleartool lsprivate -do. Attempt to open each file. The view then detects winked-in DOs that are no longer valid and removes them.
NOTE: On UNIX systems, you can use the UNIX xargs utility to automatically open the file names returned by lsprivate. This command does the job for 50 DOs:
cleartool lsprivate -do | xargs -n50 file
(Dynamic views only) Remove all of the view's .cmake.state files. The view then queries the VOB regarding the state of DOs created by this view. Rebuilding in the view causes the view to detect view-private files that are no longer recognized as DOs and rebuild them.
After you fix DO promotion problems for a dynamic view, isolated problems may still occur (for example, when a view's DO container does not exist). To prevent this problem from reoccurring, remove the offending DO with rmdo. The following section shows a sample cleanup of DOs whose config records have been lost, causing errors at build time.
This section applies to dynamic views in any situation where a VOB's database has been rolled back to a previous state.
After you restore a VOB from backup, its VOB database may be out of date with respect to certain derived objects. The old database does not store config records for any DOs that were created in subsequent builds. As a result, errors occur during hierarchical builds that reuse those late-arriving DOs to construct higher-level targets. The following example is typical of the error messages generated when this problem occurs:
======== Rebuilding "libbld.a"========
building libbld.a
rm -f libbld.a
rm -f /vobs/atria/sun5/pvtlib/libbld.a
/opt/SUNWspro/bin/cc -c -o ...
ar cq libbld.a bld.o bld_pp.o ...
Will store derived object "/vobs/proj/sun5/libbld_V.o"
Will store derived object "/vobs/proj/sun5/libbld.a"
clearmake: Error: INTERNAL ERROR detected and logged in
"/var/adm/atria/error_log".
Sunday 12/19/93 15:55:02. host "scandium", pid 440, user "chase"
Internal Error detected in "../bldr_vob.c"line 114
clearmake/cm/bldr_vob:
Error: VOB "scandium:/vobs/proj"
missing config record for derived object (OID)
"0b5759d0.fb1811cc.a0af.08:00:69:02:2e:aa"
To reestablish the view's consistency with the VOB:
Determine which DOs are causing the inconsistency. The cleartool ls command annotates them with [no config record]:
cleartool ls
bldr_comm.ugh@@09-Dec.18:26.287028
bldr_cr.msg.o [no config record]
bldr_cr.o [no config record]
bldr_cr.ugh [no config record]
bldr_cr_cache.msg.c@@24-May.20:51.42929
.
.
.
Remove the DOs that have no config record. Use the standard rm(1) command on UNIX:
rm bldr_cr.msg.o bldr_cr.o bldr_cr.ugh
Use the del command on Windows.
del bldr_cr.msg.o bldr_cr.o bldr_cr.ugh
|
|
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |
