Introduction to VOBs database
The VOB storage directory has numerous sub-directories in it. The four main areas of VOB storage are source pools, cleartext pools, derived object pools, and the database. Things can go wrong in any of these areas.
The VOB database (the db subdirectory) is one of the more important parts of the system (along with the source pools, which are in the s subdirectory). Taking a closer look at the database, we see that it uses the Raima proprietary format (where Raima is a company that's gone out of business twice since we started using
them). There's one database per VOB; on a VOB server, no matter how many VOBs you have, there will be just one database in each VOB storage directory. The database consists of 8 major files:
* Three data files (.d01 through .d03), which contain the actual data
* Four key files (.k01 through .k04), which contain indexes for random access into the data files
* String file (.str_file), which contains configuration records, among other things
Possible Problems and Their Causes
Three main types of things can go wrong:
01. Corruption in source containers : Source containers get corrupted for a variety of reasons, usually network-related. These reasons include: NFS problems that create zeroes in the middle of the files; network problems such as fragmentation or reassembly errors for large NFS packets; or faulty NICs (network interface cards).
02. VOB accesses not working : VOB accesses can stop working because you ran out of disk space or hit an OS file size limitation (2 GB on some systems) or internal database limitation (particularly in ClearCase 3.0 or schema version 53). If you encounter one of these problems, you're in big trouble, because you won't be allowed to write anything else into the VOB.
03. Data loss or corruption in the VOB database : Hardware-induced failures, Software-induced failures, from either the operating system or ClearCase (in Raima), try to remove individual database files to save space.
Detecting Data Loss or Corruption
Symptoms of having a corrupt VOB database include the following:
* You're unable to access the VOB or VOB objects. (cleartool commands fail, reporting an error like a database ID not found.)
* Either scrubber or vob_scrubber fails.
* You can't lock the VOB (which in general means you can't do any write transactions to the database).
* You can't replicate (or import replica packets). This indicates possible database corruption, but it might also just indicate divergence, depending on the error logs.
* Reformatting the VOB fails. In this case, the database is almost certainly corrupt.
The only two processes that talk to the VOB database are db_server and vobrpc_server. In their ClearCase log files, you'll see messages like these in the event of data loss or corruption:
* Unable to open VOB database - This isn't critical. It usually means you've tried to move or copy the VOB without maintaining the proper permissions on a subset of files in the VOB storage directory tree).
* db_VISTA error nnn- You'll see error numbers like -922, -909, and -6. Note that db_VISTA is essentially synonymous with Raima; anything that's a db_VISTA error is a Raima problem, although not necessarily a corruption. Raima could be having problems with the system, as in not being able to see it, read it, or write to it. This message can also mean that the API being used in ClearCase to interact with Raima is returning an error code.
* Internal error in VOB database, Unexpected error in VOB database, or Something not found in VOB database (basically, "I don't know what you're looking for, but it's not there") - If you see one of these not-so-useful messages, please call Rational Technical Support right away; don't wait a few months or ignore it altogether.
Detecting When a VOB Is Near a Limit
A VOB can stop working if it's near a limit. To detect how full a VOB database is, two utilities are available from Technical Support: countdb analyzes the data (.d01-.d03) files, and string_report analyzes the string file.
Clearcase : Restore an element that has been rmnamed
Posted by
Mahanthesh KN
comments (1)
Question : What procedures can be use to restore an IBM® Rational® ClearCase® element whose name has been removed (rmname)?
Cause : A directory used to have a full compliment of file elements, and along the way, some elements had the name removed from the directory using the cleartool rmname command. Note: The Delete operation from within ClearCase Explorer also executes a cleartool rmname, not a cleartool rmelem or cleartool rmver. For example, from within your view, right-click a file or directory element, select Delete, and read the details in the dialogue that appears, then click Cancel.
Answer : There are a few different ways to get the element names back into the directory in question.
Prerequisites: Determine which files are invisible. Here are three methods which can be used to help determine the needed directory version for the next steps:
a. On the branch that your view is set to run the following command to list out all the versions that are not visible (excludes those that are visible).
cleartool find . -all -nvisible -print
b. Within ClearCase Explorer, right click the directory where the element is missing and select Compare with Previous Version to see if the element existed in the previous version of the directory.
The ClearDiff window that is displayed will show the missing element in the left pane of the window. On top of that window you will see a path like the following that identifies version 4 of the directory named "directory" on the main branch: Note: You will need this path information after the version extended syntax (@@) as this is to be used in the link command. From the example, @@\main\4 can be used to find the missing element at the path .@@\main\4\
c. Run the cleartool lshistory command or the History Browser GUI on the directory to find which version of the directory the file was rmnamed which will indicate that it existed in the prior directory version prior to its removal. Note: You will need the previous version of the directory for the next step. For example, say lshistory reports the following:
M:\view\my_test_vob>cleartool lshistory -d -minor -since today
17-May.07:31 user1 create directory version ".@@\main\43"
"Uncataloged file element "cs.txt"."
You will need to use version \main\42 for the next steps.
Restoring the elements
1. Checkout the directory where the element is missing.
2. Use one of the following procedures to restore the element name back to the LATEST version of the directory:
• Create a link using the cleartool ln operation for each element. For example, the missing element is called test.txt
cleartool> ls
foo.c@@\main\13 Rule: \main\LATEST
cleartool> ln .@@\main\4\test.txt .\test.txt
Link created: ".\test.txt".
cleartool> ls
foo.c@@\main\13 Rule: \main\LATEST
test.txt@@\main\7 Rule: \main\LATEST
•
• Merge the directory graphically from the version tree browser:
1. Start the version tree browser for the directory by right-clicking on the file directory, then select Version Tree.
2. After the version tree browser appears, right-click on a version of the directory known to contain the missing file and select Merge to... and select the current version of the directory in use.
3. When the dialog box appears, select Yes, and also select the option Merge the element graphically. Once the merge GUI appears, manually step through the differences between the current version and the selected prior version with the files.
Note: If you need assistance, you can use the Help available from within the Merge Manager tool.
4. Undo the difference resolution for the removed element names and then select the correct contributor you wish to use.
5. Save the results, and close the graphical merge window.
You may need to Refresh your view for the element names to reappear in the directory version that they were just restored to.
6. If the results are correct, then right-click the directory and click Checkin.
• Merge the directory using cleartool merge -delete to "undo" the rmname operation (this option is somewhat more complicated).
Caution: If more than one change was made to the directory in this version, those changes could be reverted as well. Use the cleartool lshistory command to determine what other changes were made to that directory version.
1. Determine the version where the element was rmnamed.
2. Use cleartool merge -delete to remove the changes applied in that version of the directory.
For example:
cleartool merge-to . -delete -version \main\17
3. If the only change made in this version was the removal of the desired element, the change should automatically be made (see about caution).
Cause : A directory used to have a full compliment of file elements, and along the way, some elements had the name removed from the directory using the cleartool rmname command. Note: The Delete operation from within ClearCase Explorer also executes a cleartool rmname, not a cleartool rmelem or cleartool rmver. For example, from within your view, right-click a file or directory element, select Delete, and read the details in the dialogue that appears, then click Cancel.
Answer : There are a few different ways to get the element names back into the directory in question.
Prerequisites: Determine which files are invisible. Here are three methods which can be used to help determine the needed directory version for the next steps:
a. On the branch that your view is set to run the following command to list out all the versions that are not visible (excludes those that are visible).
cleartool find . -all -nvisible -print
b. Within ClearCase Explorer, right click the directory where the element is missing and select Compare with Previous Version to see if the element existed in the previous version of the directory.
The ClearDiff window that is displayed will show the missing element in the left pane of the window. On top of that window you will see a path like the following that identifies version 4 of the directory named "directory" on the main branch: Note: You will need this path information after the version extended syntax (@@) as this is to be used in the link command. From the example, @@\main\4 can be used to find the missing element at the path .@@\main\4\
c. Run the cleartool lshistory command or the History Browser GUI on the directory to find which version of the directory the file was rmnamed which will indicate that it existed in the prior directory version prior to its removal. Note: You will need the previous version of the directory for the next step. For example, say lshistory reports the following:
M:\view\my_test_vob>cleartool lshistory -d -minor -since today
17-May.07:31 user1 create directory version ".@@\main\43"
"Uncataloged file element "cs.txt"."
You will need to use version \main\42 for the next steps.
Restoring the elements
1. Checkout the directory where the element is missing.
2. Use one of the following procedures to restore the element name back to the LATEST version of the directory:
• Create a link using the cleartool ln operation for each element. For example, the missing element is called test.txt
cleartool> ls
foo.c@@\main\13 Rule: \main\LATEST
cleartool> ln .@@\main\4\test.txt .\test.txt
Link created: ".\test.txt".
cleartool> ls
foo.c@@\main\13 Rule: \main\LATEST
test.txt@@\main\7 Rule: \main\LATEST
•
• Merge the directory graphically from the version tree browser:
1. Start the version tree browser for the directory by right-clicking on the file directory, then select Version Tree.
2. After the version tree browser appears, right-click on a version of the directory known to contain the missing file and select Merge to... and select the current version of the directory in use.
3. When the dialog box appears, select Yes, and also select the option Merge the element graphically. Once the merge GUI appears, manually step through the differences between the current version and the selected prior version with the files.
Note: If you need assistance, you can use the Help available from within the Merge Manager tool.
4. Undo the difference resolution for the removed element names and then select the correct contributor you wish to use.
5. Save the results, and close the graphical merge window.
You may need to Refresh your view for the element names to reappear in the directory version that they were just restored to.
6. If the results are correct, then right-click the directory and click Checkin.
• Merge the directory using cleartool merge -delete to "undo" the rmname operation (this option is somewhat more complicated).
Caution: If more than one change was made to the directory in this version, those changes could be reverted as well. Use the cleartool lshistory command to determine what other changes were made to that directory version.
1. Determine the version where the element was rmnamed.
2. Use cleartool merge -delete to remove the changes applied in that version of the directory.
For example:
cleartool merge-to . -delete -version \main\17
3. If the only change made in this version was the removal of the desired element, the change should automatically be made (see about caution).
Clearcase : Why Elements Are Moved to the VOB lost+found Directory
Posted by
Mahanthesh KN
comments (1)
An object will be placed in a VOB's lost+found directory when the parent directory namespace has been removed (in which case there is no longer a context in which to show the object) or altered such that it's contents have no reference in a previous directory version. This can happen under the following circumstances:
1. The object's parent directory element is removed with rmelem and there are no other hardlinks to the object elsewhere in the VOB.
Example:
%>cleartool rmelem dir1
CAUTION! This will destroy the element, all its branches and versions, including all data, meta-data and history, and will remove the element from all directory versions that now contain it. Once you destroy the element, there will be no way to restore it to its current state. If you want to preserve the element, but remove references to it from future directory versions, use the "rmname" command.
Element "dir1" has 1 branches, 2 versions, and is entered in 1 directory versions. Destroy element? [no] y
cleartool: Warning: Object "foo.c" no longer referenced.
cleartool: Warning: Moving object to vob lost+found directory as "foo.c.986de380d90b479db49316560deba2f2".
Removed element "dir1".
2. The parent directory is checked out, files and/or directories are added, and then the parent directory is unchecked out.
Example:
%>cleartool co -nc dir1
Checked out "dir1" from version "/main/7".
%>cleartool mkelem -ci -nc foo.c
Created element "foo.c" (type "text_file").
Checked in "foo.c" version "/main/1".
%>cleartool unco dir1
cleartool: Warning: Object "foo.c" no longer referenced.
cleartool: Warning: Moving object to vob lost+found directory as
"foo.c.c7592f61ab0b11db83b5000180f96245".
Checkout cancelled for "dir1".
3. The parent directory is checked out, files and/or directories are added, and then the file or directory has its name removed (rmname) before the parent directory is checked in.
Example:
%>cleartool co -nc dir1
Checked out "dir1" from version "/main/7".
%>cleartool mkelem -ci -nc foo.c
Created element "foo.c" (type "text_file").
Checked in "foo.c" version "/main/1".
%>cleartool rmname foo.c
cleartool: Warning: Object "foo.c" no longer referenced.
cleartool: Warning: Moving object to vob lost+found directory as
"foo.c.c7592f61ab0b11db83b5000180f96245".
Removed "foo.c".
When an object is moved to the lost+found root directory its OID (object ID) is appended to the original filename. For example:
Before : foo.c
After : foo.c.282d5d339cba4043905da6ca201e1f3d
If a directory element is moved to lost+found, all of the subdirectories and elements it contains are moved along with it (the directory structure is kept intact). Since these contents are not located in the lost+found root, however, they are not renamed in the manner described above.
1. The object's parent directory element is removed with rmelem and there are no other hardlinks to the object elsewhere in the VOB.
Example:
%>cleartool rmelem dir1
CAUTION! This will destroy the element, all its branches and versions, including all data, meta-data and history, and will remove the element from all directory versions that now contain it. Once you destroy the element, there will be no way to restore it to its current state. If you want to preserve the element, but remove references to it from future directory versions, use the "rmname" command.
Element "dir1" has 1 branches, 2 versions, and is entered in 1 directory versions. Destroy element? [no] y
cleartool: Warning: Object "foo.c" no longer referenced.
cleartool: Warning: Moving object to vob lost+found directory as "foo.c.986de380d90b479db49316560deba2f2".
Removed element "dir1".
2. The parent directory is checked out, files and/or directories are added, and then the parent directory is unchecked out.
Example:
%>cleartool co -nc dir1
Checked out "dir1" from version "/main/7".
%>cleartool mkelem -ci -nc foo.c
Created element "foo.c" (type "text_file").
Checked in "foo.c" version "/main/1".
%>cleartool unco dir1
cleartool: Warning: Object "foo.c" no longer referenced.
cleartool: Warning: Moving object to vob lost+found directory as
"foo.c.c7592f61ab0b11db83b5000180f96245".
Checkout cancelled for "dir1".
3. The parent directory is checked out, files and/or directories are added, and then the file or directory has its name removed (rmname) before the parent directory is checked in.
Example:
%>cleartool co -nc dir1
Checked out "dir1" from version "/main/7".
%>cleartool mkelem -ci -nc foo.c
Created element "foo.c" (type "text_file").
Checked in "foo.c" version "/main/1".
%>cleartool rmname foo.c
cleartool: Warning: Object "foo.c" no longer referenced.
cleartool: Warning: Moving object to vob lost+found directory as
"foo.c.c7592f61ab0b11db83b5000180f96245".
Removed "foo.c".
When an object is moved to the lost+found root directory its OID (object ID) is appended to the original filename. For example:
Before : foo.c
After : foo.c.282d5d339cba4043905da6ca201e1f3d
If a directory element is moved to lost+found, all of the subdirectories and elements it contains are moved along with it (the directory structure is kept intact). Since these contents are not located in the lost+found root, however, they are not renamed in the manner described above.
Subscribe to:
Posts (Atom)
