How to check your file system cache & archive in Rational Synergy

Technote (FAQ)


Question

How do you verify that the cache & archive files for your database are correct in IBM Rational Synergy?

Cause

As with all database management systems is it good practise to validate the consistency of the information you have stored.

Answer

A Rational Synergy database consists of two parts:

  • Metadata: This is the data which defines the objects you are managing in Rational Synergy. This data is stores in an Informix or Oracle database.
  • Source files: This is the actual source code you are managing. It consists of active files in the cache and archives for previous versions. This data is stored in the file system under the database path.
For more details on the Synergy database structure, see the relevant 'Administration Guide for Synergy' in the Related URL section and TechNote 1325187: Structure of the Rational Synergy Cache and Archive for Release 6.5 / 6.6a and earlier.


The 'ccm fs_check' command is used to verify the cache and archive files. This document discusses this command in more detail.

The 'ccmdb_check' command verifies the metadata for your database. This command is discussed in other documents and not here.


Using fs_check command.

The “ccm fs_check” command is run within a Synergy CLI session on a database.

    ccm fsck|fs_check
    [-d|-dir
    directory_path] [-f|-fix] [-t|-type type]
    [-c|-cutoff
    cutoffTime] [-v|-verbose] [-e|-empty_skip]
    [-u|-unused_skip] [-nd|-no_duplicates] [-w|-windows]
    [-nb|-null_byte] [-z|-zero_counts]

    ccm fsck|fs_check
    [-d|-dir
    directory_path] [-f|-fix] [-c|-cutoff cutoffTime]
    [-v|-verbose] [-e|-empty_skip] [-u|-unused_skip]
    [-nd|-no_duplicates] [-w|-windows] [-nb|-null_byte]
    [-z|-zero_counts]
    object_spec...




The command checks the consistency of the database cache and archive by attempting to extracting the archived sources to temporary files, and comparing those temporary files with their corresponding cache files. If there are any inconsistencies, these are reported to you.

It is recommended that 'fs_check' is run regularly, just as you would run the 'ccmdb check' command to verify consistency at the metadata level. But the 'fs_check' command can take a long time to run, particularly on large databases. Even if you run 'ccmdb backup' or 'ccmdb check' every day, you may want to run 'fs_check' every weekend. You should run this command at least as often as you run ‘ccm clean_cache’ and always run it if you receive any errors when running ‘ccm clean_cache

For assistance running “fs_check”, please refer to the Online Help.

Command Output

The “fs_check” command produces a detailed report for all problems found. At the end of the report there is a summary.

      SUMMARY:

      22229 objects selected:
      198 objects skipped because they are model objects
      7758 objects skipped because they do not have source attributes
      14273 objects were checked.

      Archive information check for 14066 static objects:
      14066 objects have separate, readable archives
      Comment: 334 objects were archived with an older archiver

      Cache file check for 14273 objects:
      4336 static objects had no cache file present
      207 objects were not static, so their cache file times were not checked
      3403 cache files matched their corresponding source modification times
      - 6327 cache files' modification times were NEWER than their source mod times

      Archive file comparison for 9730 static objects:
      9725 objects had matching cache and archive files
      - 329 objects matched only after ignoring carriage return characters
      - 23 objects had empty sources
      * 5 objects had DIFFERENT cache and archive files

      Checked that 24003 cache files and archive entries were in use:
      9937 used cache files
      14066 used archive files and entries

      Database check failed with 5 serious errors and 6679 warnings.

The output reports the following types of messages:

  • Informational: Informational messages do not necessarily indicate a problem with the database but some administrators may want to investigate them.
  • WARNING: Warnings are informational. You should review the error and consider if a fix is required.
  • SERIOUS: Serious Errors must be resolved as soon as possible and may be corrected by user action
  • CRITICAL: Critical Errors must be resolved as soon as possible and are usually unrecoverable, They may require restoration of files from a database backup.

Details on how to manage individual problems reported by fs_check can be found in other TechNotes which will deal with each problem separately. When you search on the error message you should be able to find the relevant information. If you see an error which is not covered by an existing TechNote or if you are anyway unsure what to do then please contact Rational Client Support.

Related information

Windows fs_check
UNIX Informix fs_check
UNIX Oracle fs_check
7.1 Administration Guides

Rate this page:

(0 users)Average rating

Document information


More support for:

Rational Synergy
General Information

Software version:

6.3, 6.4, 6.5a, 6.5, 6.6a, 7.0, 7.1, 7.2

Operating system(s):

AIX, HP-UX, Linux, Solaris, Windows

Reference #:

1624983

Modified date:

2013-06-05

Translate my page

Machine Translation

Content navigation