本文介绍了在使用IBM Rational ClearCase 过程中可能出现的有关VOB的问题和解决方法，并且提供了有关的实例以便读者在实际操作中作为参考。

1．VOB作用与结构

1.1 什么是VOB

Rational ClearCase提供了一个开放的体系结构用来进行软件配置管理（Software Configuration Management, SCM）。ClearCase可以管理软件项目开发的过程中产生的源程序及各种文档的系统。从更广的意义上来说，任何一种项目的智力资产，只要可以被记录为数字形式都可以用ClearCase进行管理。

ClearCase不仅提供了对这些智力资产存取的功能，而且记录了对这些资产每次修改的所有版本。ClearCase将中所有的版本存储在Versioned Object Base (VOB) 中。VOB中还保留了一些其它与项目和配置有关的信息，所以VOB可以看作是整个ClearCase SCM系统的中心数据库。

1.2 VOB的结构

正如前面所说，我们可以把VOB看作一个数据库系统。一个数据库系统的逻辑和物理的结构是截然不同的，比如一个关系型数据库，逻辑上可以看到的是：表，字段，视图，存储过程，用户，和权限等；物理上可能是一系列文件或磁盘分区。了解数据库的逻辑结构可以帮助我们更好的使用它，而了解数据库的物理结构是为了更好地对它进行管理。因为本文主要阐述的是管理方面的问题，下面我们将简单介绍一下ClearCase VOB的逻辑结构，然后着重描述它的物理结构。

VOB中的数据主要有两种：简单数据（文件和目录及其各个版本）、复杂数据（分支、标签、事件记录、等等）。这些数据的结构和格式被VOB的Schema所决定。VOB的Schema是可以改变的。一个VOB增加了一定属性可以具有特殊用途，比如：管理VOB, 统一变更管理(Unified change management, UCM)VOB, 和项目VOB(PVOB)。另外VOB提供的功能还与它的特性层次（Feature level）有关，某些功能的使用，要求改变VOB的特性层次。

有关一个VOB的物理文件都是存储在一个目录（VOB Storage directory）中的。了解这个目录中的每个文件，有助于我们更好地管理VOB。我需要在这里着重指出一点就是：请勿用非ClearCase的工具对此目录或里面的文件进行任何操作，包括修改文件或目录的内容及其读写权限。这样做很可能会导致VOB无法访问。因为虽然它们看起来像普通的文件和目录，但是ClearCase赋予了它们很多附加属性，而一般的工具很难识别并保存这些属性。当然如果您不幸犯了这样的错误导致VOB无法访问，ClearCase提供的一系列工具仍然可以帮助您修复。这在本文的后部将有所介绍。

当用操作系统的列目录命令（ls, dir等）查看VOB存储目录时，您将会看到以下内容：

.pid 单行文本文件，记录了vob_server的进程号。

admin 一个目录，包含VOB使用的磁盘空间

vob_oid 单行文本文件，记录VOB的对象标识号，用UUID的方式表示。可以在ClearCase多复本（MultiSite）环境中用来表示一个VOB家族。一个VOB家族通常包含一个原始VOB和若干个它的克隆VOB。

replica_uuid 单行文本文件，记录了该VOB复本UUID，用于区分在一个VOB家族中的不同复本VOB。

.identity 一个目录，在UNIX系统中，记录了VOB的所有者和所有者组的信息，用于访问权限控制。

identity.sd 一个二进制文件，在Windows系统中，记录了VOB存储目录用户的安全描述符。

groups.sd 一个二进制文件，在Windows系统中，记录了VOB存储目录次要用户组的安全描述符。

s 一个目录，用来存储文件或目录的所有版本。

c 一个目录，暂时存储一个文件或目录的某个版本，用来作为s的缓冲池。这个缓冲区会经常进行刷新，在ClearCase中被叫做Scrub。在[CC Admin]中有专门的章节介绍Scrubbing操作。

d 一个目录，用来存储派生对象。当您编译VOB中的源文件时所产生的目标文件在ClearCase中可以作为一个派生对象（Derived Object， DO）。共享这些DO就可以使不同视图使用相同的二进制目标文件，从而减少冗余，更加快了编译的速度。ClearCase中把一个DO的第一次产生叫做wink in。这个目录也会被系统定期Scrub。

db 一个目录，包含VOB使用的一个内嵌数据库系统（Raima Database）。除了文件和目录版本实际拷贝以外的其他数据都存储在这个数据库中。当您进行了reformatvob命令之后，这个目录的旧版本将会以重命名的方式保留下来，以防万一。

vob_server.conf 一个文本文件，用于配置vob_server启动时的一些信息。

.hostname 一个文本文件，记录了VOB服务器的名字。

.msadm_acls 记录ClearCase多复本环境中管理服务器的访问控制列表。

在此还有必要介绍一下内嵌数据库（目录d）的物理结构：

vob_db.dbd 一个编译好的数据库Schema，描述了数据库的结构。

vob_db_schema_version 一个Schema版本文件，数据库用它来比对编译好的数据库Schema。

vob_db.d0n, vobdb.k0n 数据库的内容。

vista.* 数据库的控制文件和交易日志

db_dumper 一个系统可执行db_dumper的备份。reformatvob将会调用此备份，如果系统目录下的版本不可用，以确保数据库导出的成功。

vob_db.str_file 数据库字符串文件，用来存储长字符串。

从以上的结构中可以看出，ClearCase是一个复杂而功能强大的系统。它包含了一个内嵌的数据库和若干个自制的存储池。它们之间的相互协作不仅可以提供简单的版本管理，更可以实现分布式开发，并行编译等其他系统不具备的功能。因此对VOB的任何操作必须是十分小心和有计划地进行。但是在具体应用中往往会发生一些人为和不可避免的错误，下面就这些问题进行一些探讨。所有列举的ClearCase的命令仅供参考。有关具体使用，请参考与您系统相应的[CC Ref]，本人对由这些例子产生的后果不承担任何责任。

2．与VOB相关的问题及其处理

我们可以将VOB的结构简化为以下图示（来自[SCM503]）：

当用户提取一个文件的某个版本时，通常的操作是这样的：

1． 用户发送请求到VOB数据库；

2． 数据库找到相应的源代码存储池并查询到相应的版本号，将请求送给一个叫做Type Manager的程序；

3． Type Manager 发现Cleartext pool缓存中没有这个版本的文件；

4． Type Manager 从源代码存储池中获取相应版本的文件并放入Cleartext pool中；

5． 用户从Cleartext pool 中得到要求的文件版本

因此经常出现的与VOB相关的问题大致可以分为以下三类：

2.1 内嵌数据库和存储池之间不同步问题

这类问题的产生主要是因为VOB数据库中有关存储池的信息和实际的存储池信息不一致造成的，比如：VOB数据库中含有不存在的存储池，VOB数据库中对于存储池的访问控制信息不正确，或者有的存储池在VOB数据库中没有记录。造成这些不一致的原因可能是因为网络问题，不成功的备份恢复，或者是用户错误地操作了VOB存储目录下面的文件或目录。解决这些问题的方法就是将VOB数据库和存储池的信息实施同步。

下图（来自[SCM503]）显示了一个典型的此类错误的view_log中有关的信息


　

可以看出系统无法找到cleartext pool或source pool相应文件。我们可以用checkvob命令来检测和修复此类问题：

checkvob -pool -source /vobstg/vob1.vbs 用来检测vob1的源代码存储池问题。

checkvob -fix -pool -source /vobstg/vob1.vbs 用来修复vob1的源代码存储池问题。

下面是checkvob命令对各类问题的解决方法：

2.2 有关VOB 内嵌数据库的问题

当VOB内嵌数据库本身出现问题时，您将会发现很多操作无法完成。db_server 和vobrpc_server是和数据库通信的两个进程，查看它们的日志有助于问题的解决。dbcheck 和 reformatvob可以帮助您从大部分的问题中恢复。更深层次的内嵌数据库本身的问题已经超出本文的范畴，请参考文档[VOB DB]。

内嵌数据库另外一种常见问题是由于数据库的某些文件超出上限造成的VOB不可访问。VOB内嵌数据库所存储的纪录是有限的。这可能是因为磁盘没有空间，数据库文件达到本身或操作系统的上限。在Schema 53中，数据库可以存储的记录大概是224，数据库文件的大小一般不能超过2GB。

当内嵌数据库数据文件（vob_db.d0n, vobdb.k0n）过大时，您可以在ClearCase database server log 中看到db_VISTA 错误（错误号为：-900、-909、-912、-914、-919、2）。您可以进一步用命令countdb 查看数据库的使用情况，如下（图来自[SCM503]）

有三种方法可以帮助您解决此类问题：

1． 您可以将VOB中的一些目录移走来解决暂时的限制，也就是将大VOB分裂为几个较小的VOB；

2． 手工删除VERSION_LABEL_LINK, DOT_DOT/NAMESPACE_DIRECTORY_VERSION_ENTRY, 和 OPLOG_ENTRY 的记录数；

3． 最好的方法是采用或升级到Schema54或以上。升级VOB可以使用reformatvob命令，但是这个操作一般需要很长很长的时间。

除了数据文件过大以外，控制文件、日志文件、和字符串文件过大也会影响到VOB的访问。控制文件和日志文件的大小可以在db.conf文件中配置。字符串文件过大可以通过sting_report.exe检测到。根据sting_report.exe的结果删除不用的视图和DO等可以缩小字符串文件的大小。

2.3 有关存储池本身的问题

当排除了以上两种问题的可能性以后，VOB还有问题，那可能是因为存储池本身受到了损害，首先应该检查VOB存储目录下的文本文件中的信息是否正确。例如：如果VOB server的名字改变了应该检查.hostname。

如前文所述，ClearCase VOB存储目录下的文件不能用一般的工具进行修改。如果您不小心在Windows浏览器中修改了某个文件或目录的属性，可能会造成它们无法访问。如果是VOB的根目录，则整个VOB将无法访问。在Schema53中可以用fix_prot来修理，在Schema54中可以用vob_sidwalk。

如果问题仍然存在，最后可以用ck_all_tfd_for_nulls.pl命令进行检查，一旦发现错误可以将以前备份的存储池恢复到受损目录，然后再运行checkvob命令，或者运行一次标准的ClearCase恢复操作。

2.4 修复VOB常用工具和手段

• checkvob 可以发现存储池和内嵌数据库的不一致，用-fix选项可以对发现的错误进行修复。
• ck_all_tfd_for_nulls.pl 在文本存储池中查找受损部位。它是一个系统工具，一般在utils目录下。
• countdb.exe 可以显示内嵌数据库空间的使用情况，一般在utils目录下。
• string_report.exe 用于检测内嵌数据库字符串文件的使用情况，一般在utils目录下。
• db log and vobrpc log files 当怀疑内嵌数据库有问题时可以查看这些文件。
• dbcheck.exe 可以检查出80%有关内嵌数据库的问题。
• reformatvob 将VOB内嵌数据库导出为文本文件，或将导出的文件重新导入一个新的数据库，用于数据库的升级和减小数据库大小。
• vob_sidwalk 改变VOB数据库中元素的安全标示，也就是用户和用户组标示。
• fix_prot产生或修复.identity/ identity.sd文件。
• lsacl 显示一个VOB的安全标示结合fix_prot可以修复对目录和文件访问控制问题。
• rmtype 删除VOB中的对象类型，可以用来缩小内嵌数据库的大小。
• rmver 删除元素的版本，可以用来缩小内嵌数据库的大小。
• vob_scrubber_params file 调整scrubber运行的频率，以免VOB过大，但是如果参数太小，会造成系统性能下降。

3．总结

当您的VOB发生问题时，应该尽量先使用上面提到的工具对问题进行定位,确定问题发生在VOB内嵌数据库，存储池，还是两者之间的同步。然后使用相应的工具进行修理。最后提醒一下，作为一个ClearCase管理员，应该经常备份系统关键数据。

参考资料

• [CC Admin] Rational ClearCase/LT Administrator's Guide
• [CC Ref] Rational ClearCase Command Reference
• [SCM503] When Good VOBs Go Bad version 1.0
• [VOB DB] ClearCase VOB Database Troubleshooting