二、定義　　Rational ClearCase提供了一個開放的體系結構用來進行軟件配置管理（Software Configuration Management，SCM）。ClearCase可以管理軟件項目開發的過程中產生的源程序及各種文檔的系統。從更廣的意義上來說，任何一種項目的智力資產，只要可以被記錄為數字形式都可以用ClearCase進行管理。 　　ClearCase不僅提供了對這些智力資產存取的功能，而且記錄了對這些資產每次修改的所有版本。ClearCase將中所有的版本存儲在Versioned Object Base (VOB) 中。VOB中還保留了一些其它與項目和配置有關的信息，所以VOB可以看作是整個ClearCase SCM系統的中心數據庫。

編輯本段三、結構

　　正如前面所說，可以把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的命令僅供參考。

編輯本段四、相關問題

　　當用戶提取一個文件的某個版本時，通常的操作是這樣的： 　　1． 用戶發送請求到VOB數據庫； 　　2． 數據庫找到相應的源代碼存儲池并查詢到相應的版本號，將請求送給一個叫做Type Manager的程序； 　　3． Type Manager 發現Cleartext pool緩存中沒有這個版本的文件； 　　4． Type Manager 從源代碼存儲池中獲取相應版本的文件并放入Cleartext pool中； 　　5． 用戶從Cleartext pool 中得到要求的文件版本 　　因此經常出現的與VOB相關的問題大致可以分為以下三類：

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命令對各類問題的解決方法： 問題解決方法 ： 　　找不到存儲池 掃描整個存儲池目錄，重建各條記錄 ，沒有記錄的存儲池將沒有引用的存儲池放入lost+found目錄 ，存儲池訪問控制錯誤 在用戶權限允許的情況下重建訪問控制信息 。

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 查看數據庫的使用情況，如下。 　　有三種方法可以幫助您解決此類問題： 　　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等可以縮小字符串文件的大小。

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恢復操作。

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過大，但是如果參數太小，會造成系統性能下降。

5.總結

　　當VOB發生問題時，應該盡量先使用上面提到的工具對問題進行定位,確定問題發生在VOB內嵌數據庫，存儲池，還是兩者之間的同步。然后使用相應的工具進行修理。最后提醒一下，作為一個ClearCase管理員，應該經常備份系統關鍵數據。