* db_VISTA error nnn- You'll see error numbers like -922, -909, and -6. 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). * Unable to open VOB database - This isn't critical. In their ClearCase log files, you'll see messages like these in the event of data loss or corruption: The only two processes that talk to the VOB database are db_server and vobrpc_server. In this case, the database is almost certainly corrupt. This indicates possible database corruption, but it might also just indicate divergence, depending on the error logs. * You can't replicate (or import replica packets). * You can't lock the VOB (which in general means you can't do any write transactions to the database). (cleartool commands fail, reporting an error like a database ID not found.) * You're unable to access the VOB or VOB objects. Symptoms of having a corrupt VOB database include the following: 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. 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.Ġ3. 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). 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).Ġ2. Corruption in source containers : Source containers get corrupted for a variety of reasons, usually network-related. * String file (.str_file), which contains configuration records, among other thingsĠ1. k04), which contain indexes for random access into the data files 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. 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 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). Things can go wrong in any of these areas. The four main areas of VOB storage are source pools, cleartext pools, derived object pools, and the database. The VOB storage directory has numerous sub-directories in it. If only the timestamp changed, but the CRC is still the same, then the new timestamp is updated in the copyarea.db. If the timestamp AND the CRC of the file have changed, then the file has been hijacked. If the timestamp has changed, then the CRC of the file is checked. If the file size has changed, then the file has been hijacked. The CCRC and the ClearCase Web use the following algorithm to detect if a file has been changed:ġ. If this file is missing or corrupt, you will notice that all or some of the loaded files will appear to be hijacked.Īlso, CCRC and CCWeb keep a record of both the timestamp and a checksum for each element version downloaded. copyarea.db file is created in each directory of a CCRC or CCWeb view which contains a list of files that are loaded in the view as well as metadata about the files. What http server the view was originally connecting to.copyarea.dat file stores information like: copyarea.dat file is used to detect if changes have been made to the loaded files to determine is hijacked state. Below is a brief explanation of how these files are used. copyarea.db files are used in an IBM® Rational® ClearCase® Remote Client (CCRC) or ClearCase Web (CCWeb) view.Įach CCRC or CCWeb view root directory (the directory tree where the files from the VOB are downloaded into the local view workspace) contains a.
0 kommentar(er)
