The following sample scenarios (see Figure 20) illustrate some general guidelines for using checkvob.
Figure 20 Common Scenarios in VOB Database or Storage Pool Synchronization
A disk crash destroyed remote storage pools, which have been retrieved from backup. The VOB database is current, and the VOB is locked against any further write operations.
The VOB database records development activity that is not substantiated in the storage pools. Under these circumstances, checkvob ought to find these anomalies:
File element or source pool problems: missing and unreferenced data containers. Checkins have been recorded in the VOB database, but they do not appear in the storage pools. This represents real data loss. checkvob synchronizes the VOB database with the storage pool by executing rmver -data on missing versions.
DO or DO pool problems: missing data containers. The database references DOs that were promoted to VOB storage containers, but these containers are not found in the (older) pool. checkvob deletes these DOs from the database with the equivalent of rmdo.
DO or DO pool problems: unreferenced data containers. DOs were scrubbed from VOB storage, but the (older) pool still includes their containers.
To accept as lost any pool data (versions or DOs) added in the interval between the pool and database reference times, run checkvob -force -fix and supply an appropriate time interval (see Force-Fix Mode).
To accept the default, one-day data loss interval, run checkvob -force -fix; then, run checkvob without -force and fix any remaining elements with missing containers manually (as you are prompted by checkvob).
The VOB database is corrupted. The storage pools are current, and you have a recent VOB database snapshot on disk. You have run vob_restore to recover the VOB database and storage pools. checkvob runs to complete the restoration process.
The VOB storage pools reflect development activity that has not been recorded in the VOB database. This scenario, like the previous one, is consistent with using a semi-live VOB backup scheme, as described in Backing Up a VOB. Under these circumstances, checkvob ought to find these anomalies:
File element or source pool problems: missing and unreferenced data containers. New checked-in versions have been written to VOB storage after the reference time on the available VOB database. Note that if any rmver, rmbranch, or rmelem events occurred during the time gap, recovering all versions is not possible (and, presumably, not desirable).
DO or DO pool problems: missing data containers. The scrubber has deleted DOs from the (newer) pool, but the (older) database still references them.
DO or DO pool problems: unreferenced data containers. DOs have been promoted from view-private to VOB storage, but the (older) database does not know about them.
Run checkvob -force -fix and supply an appropriate time interval (see Force-Fix Mode). Most new work (versions found in the newer pools, but unknown to the older database) will be captured in containers identified as debris and moved to the pool's lost+found subdirectory (from where you can, under some circumstances, retrieve it successfully). Note that under no circumstances does checkvob update a VOB database with "new" version data found in more recent pools. You may be able to construct versions from containers in lost+found and check them in as new versions, but checkvob cannot do so. The safety net features (see Force-Fix Mode) prevent large scale data loss. The only expected data loss reports should be the result of rmver or rmbranch operations no longer reflected by the (older) database.
Feedback on the documentation in this site? We welcome any comments!
Copyright © 2001 by Rational Software Corporation. All rights reserved. |