Troubleshooting
Problem
Following a successful conversion of the archive of a database in IBM Rational Synergy, It is suggested that the ccm fs_check utility be re-run on the database. Following the archive conversion, something similar to the following results may come from the ccm fs_check command, and this occurs despite the ccm fs_check running clean prior to the archive.conversion. Why is this problem occurring and how can it be resolved?
Symptom
Results
SUMMARY:
19529 objects selected:
332 objects skipped because they are model objects
0 objects skipped because they are symbolic links
1163 objects skipped because they do not have source attributes
0 objects skipped because they have been deleted from the database
0 objects do not have source attributes, but should
18034 objects were checked.
Archive information check for 17066 static objects:
0 objects have not yet been archived
0 objects have not been archived after more than 5 days
0 objects have missing archive attributes
0 objects had their archive attributes reset
0 objects contain bad archive info
0 objects have inconsistent archive attributes
0 objects use a bad archive path
0 objects had this error repaired by re-archiving their cache files
0 objects reference a duplicate archive entry
0 objects failed to extract the archive revision
0 objects with bad archives also had no cache file present
17066 objects have separate, readable archives
Comment: 0 objects were archived with an older archiver
Comment: ASCII objects were not checked for null bytes
Cache file check for 18034 objects:
0 non-static objects had no cache file present
467 static objects had no cache file present
968 objects were not static, so their cache file times were not checked
16599 cache files matched their corresponding source modification times
0 cache files' modification times were older than their source mod times
0 cache files' modification times were NEWER than their source mod times
0 cache files had their timestamps fixed
0 objects were missing the source_modify_time attribute
Archive file comparison for 16599 static objects:
16599 objects had matching cache and archive files
0 objects matched only after ignoring carriage return characters
Comment: checks for empty source files were skipped
0 objects had DIFFERENT cache and archive files
0 objects had this difference repaired by deleting their cache files
Checked that 34948 cache files and archive entries were in use:
0 unexpected files - not cache files?
0 unused cache files
17567 used cache files
0 unexpected files - not archives?
315 unused archive files and entries
17066 used archive files and entries
0 archive files could not be listed
Database check succeeded.
This example shows 315 unused archive files are reported, although that is confusing as they are usually unused archive entries and not files. For each of these, the entry will look something like this:
INFO: unused archive entry
Archive file path:
/data/ccmdb/mydb/st_root/archive/source/ascii/ccm_rcs/1/8/myfile.txt,v
Revision number: 1.1
Cause
It is possible that the conversion process, while it may have completed, nevertheless has left some of the older archive files in situ.
Resolving The Problem
Check the Archive Conversion:
The archive conversion progress can be shown and verified from the Synergy command line by running: ccm info -f "Level=%level, total=%total, unconverted=%unconverted, errors=%bad"
archive_conversion-1:admin:base
where the level attribute on the admin object shows the last complete archive conversion level as in the following table:
0 or non-existent - the database contains GNU/BSD archives
1 - the database contains 7.1 archives, but no GNU or BSD archives
2 - the archives are at version 2, with delta compression (7.1.0.1)
For example, the result from this command may be as follows:
Level=2, total=17066, unconverted=0, errors=0
This shows that the archive conversion process completed successfully and that all the archives are now at level 2 (ccm_delta truezip)
The _archive_info and associated attributes can be queried on one of the error objects (to further verify) eg:
>ccm attr -s _archive_info myfile.txt,1:ascii:1
60711216/140844081
>ccm attr -s _archive_version myfile.txt,1:ascii:1
2
Finally the database can be queried to show if there is any object with an _archive_info attribute value of "none". This should return 0 objects across the database.
Assuming all of the above are correct, it can be concluded that the Archive Conversion has completed successfully.
Fixing the problem
Since all new archive files are created in database/st_root/archive/ccm_delta directory, if the archive conversion is complete, there should be no subdirectories in database/st_root/archive other than ccm_delta.
Any such subdirectories likely correspond to the types of the objects in the errors.
These subdirectories should be moved aside in the file system and the ccm fs_check process repeated. This should now returned clean.
Finally, the database may not have a "Remove" button in the Archive Conversion tab in the Synergy Web Admin tool (presumably because the conversion had not cleaned out the old archiver entries fully)
The conversion process can be restarted from the Web Admin tool, it will likely complete immediately and the "Remove" button will be displayed. The database can thus be removed from the Archive Conversion tool as having been completely converted.
Was this topic helpful?
Document Information
Modified date:
22 December 2020
UID
swg21472877