IBM Support

How to manage the size of your database in Rational Synergy

Technote (FAQ)


How do you manage the size of your database in IBM Rational Synergy?


As development work progresses the number of objects you manage in your Rational Synergy database increases and this in turn increases the size of your database in the file system and Relational Database Management System(RDBMS) and it increases the size of you backup files and the length of time it takes to backup and restore your database. Backing up the databases is discussed in TechNote 1325161: How to backup very large Rational Synergy databases. Managing the size of the database is part of this process.
What does a database consist of?

A Rational Synergy database consists of two parts; The file system and the metadata.. The biggest part is the file system. This contains all the source files managed by the database and are in the form of cache files and archive files. The metadata is the part of the data stored in the RDBMS and consists of the attribute names, tasks objects, problem objects, type definitions, baselines, the relationships between objects and many other data elements used to define the data. Managing the size of the database requires you to manage both parts of the database.

Why do databases grow?

Databases grow over time due to a number of factors. As new versions of objects are created, those versions consume space in the database. Additionally, personal build products (executables and libraries) consume significant space. While this space is necessary during active development of a release, once that software has been released and begins to age, there is less and less chance that it will ever be referenced


Another contributing factor to the size of a database is the size of the cache area. Like most modern software systems, Rational Synergy maintains a cache of frequently referenced information. Like all caches, the Rational Synergy cache must be maintained, and while this maintenance is necessary, it is not automated. Clearing items from the cache that have not been referenced in a given period of time can drastically reduce the size of a Rational Synergy database, and the corresponding size of the repository backup.

As Rational Synergy code bases grow, the databases can become more cumbersome. Backups take longer. Day-to-day performance may degrade. Version histories may get so long that they are impractical to view.

The remedy for these conditions is some database maintenance. Regularly scheduled clean up of cache files, removal of unused intermediate versions, management and housekeeping of developer workspaces and off-loading data to another repository. When these steps are followed, most Synergy repositories will stay within a manageable size with adequate performance.

This TechNote presents recommendations based on average usage of Rational Synergy. These recommendations may be inadequate for a particular installation, or may be contrary to policy at your location. To schedule an analysis of the specific needs of your organization and the best way

address those needs, you should engage IBM Field Services or contact Rational Client Support


There is no single solution to managing the size of the database. There are a number of different steps you can do which will all contribute something to the total solution.

  • Save Offline And Delete(SOAD)
  • Collapsing object versions
  • Housekeeping
  • Clean Cache
  • Clean Up
  • Rational Synergy Distributed / Distributed Change Management (DCM) files

  • Save Offline And Delete(SOAD)

    SOAD is a methodology of identifying unwanted data, saving this data to an offline repository and deleting it from the active database. The process is designed so this offline data can be restored without loss. See Removing unwanted data for details on this methodology and the relevant commands.

    See also Removing unnecessary baselines using the SOAD methodology.

  • Collapsing object versions
    Collapsing object versions is a method for removing intermediate versions of objects. When versions are collapsed, they are physically deleted from the repository, and the history links updated to reflect the removed objects.

    Note: The ccm collapse command is not available from release 7.2. Use the SOAD methodology described above.

    As an example, consider the following history diagram:

    In this diagram, Version 1 was in Release 1. Versions 2 and 3 are in no release. They’re also one release back, so the likelihood of them being used drops significantly. Following a collapse, the history tree diagram would look like:

    In a practical sense, the code base is unchanged, as it’s unlikely anyone would ever begin development from version 2 or 3 that were not in a release. This is especially true for individual developers personal use build products. For very active modules, and very large modules, this operation can reduce the storage requirements of a Rational Synergy repository.

    To collapse object versions use the ccm collapse command. See Deleting obsolete product files for more information on using this command.

  • Housekeeping
    Most human activities generate some amount of refuse as a by-product, so does software development. To keep from drowning, some housekeeping is necessary, and it just happens to help with the overall problem of the growth of our repository. Just like you would clean up after a guest leaves, throwing away their paper plate and cup, you must clean up after developers who have left, throwing away their working projects, products, versions and tasks.

    When the developers leave

    Keep track of the users defined in your system and the users actually on the project. When they leave the company, remove their userid and role definitions from the Rational Synergy database. This helps to ensure you’re really getting rid of them, and keeps them out of your code base should they find their way back into your network. After you’ve removed them from the users list, query for all of their working projects, turn off the workarea for each project, and non-recursively collapse them. This doesn’t free up much space in the database, but may free up some on the desktop. Query for all their working build products, and collapse them. This will help reduce the database space utilization. Maybe not much, maybe a lot, depending on how many developers you remove at any one time and how big their products are. If they’re working in Powerbuilder, for example, where the .pbl files can be extremely large, this step alone may net you hundreds of megabytes. Source code and tasks require a bit more thought than products and projects. Working source code can either be deleted or rejected, but rejecting the working objects without removing them from the repository is more in line with the library functionality expected of Configuration Management and is therefore recommended. Tasks still need to get done even after someone leaves, so they’re typically re-assigned to another developer. See TechNote 1419794: How to change the ownership of the object to a new user ID

    The Save Offline and Delete (SOAD) tool provides a scope for this purpose called "All non-static projects and products for a specified user"

    When releases die

    A similar set of steps should be done when releases are made inactive. The system should be queried for all non-static projects and products for inactive releases, and these should be collapsed. Any static projects for inactive releases that are not in the released state and are not used as baselines for further development should also be collapsed. Working source should rejected as above. Tasks will need to be reviewed carefully to see if they must be re-assigned or rejected.

    When releases are completed or abandoned, mark them as inactive. You can delete old baselines and old prep hierarchies using the following SOAD scopes:

        • Non released baselines for specified release older than specified date
        • Integration Testing prep projects and products for a specified release

    See also Removing unnecessary baselines.

  • Clean Cache

    Rational Synergy maintains a cache of all objects that have ever been extracted from the archive. For most repositories, this is every object in the repository! Many of these objects will never be referenced again, allowing their cached copy to be removed and re-cached automatically when needed.

    Architecture Overview

    In order to be efficient in it’s use of space, Rational Synergy does not keep the full text of every source file. Instead, it keeps only the deltas, or changes, to a source file (assuming an ascii file, binaries are stored in a compressed format). These deltas are maintained using an industry standard reverse delta engine. The deltas, or archives, are stored in an archive area of the database. When a particular version is needed, the deltas are applied to the most recent version to get the contents back to where they were at a

    particular version. There is a significant time penalty for extracting back versions from the archive, so once a version has been extracted, it is kept in the cache in its full form. Since many of these old versions may never be referenced again, the full text copy may be removed from the cache. If it is ever referenced again, the system will automatically extract it from the archive, recreating the cached version. For more details of the architecture, see TechNote 1325187: Structure of the Rational Synergy Cache and Archive

    Cleaning the cache.

    Cache clean-up is performed using the clean_cache command. Using this command can drastically reduce the size of a database and it’s associated backup file. The default behavior of the clean_cache command is the best practice, and it will remove from the cache any file that is greater than 14 days old and not used in a project. Should you want greater control over the contents of the cache, clean_cache can be adjusted to delete files either that are older or newer, or only specific types of files. See Cleaning objects from the database cache for more detailed information.


    One strategy is to add a clean_cache command with no arguments (default behavior) to your nightly database check and backup script, right after the backup. This will ensure that the cache remains clean while minimizing the effects on the database at any given time.

    Should there be issues with the archive, the cached copy of the source will be captured in the immediately preceding backup where it can be restored if necessary.

    Before you clean your cache files you must ensure that your archive files are correct. You can do this using the ccm fs_check command. For more details see:

  • Clean Up
    Use the clean_up command to delete unused automatic tasks or to delete process rules from your database. See the online-help for details.

    Note: The ccm clean_up command is not available from release 7.2. Use the SOAD methodology described above.

  • Rational Synergy Distributed / Distributed Change Management (DCM) files

    As part of the DCM methodology files are transferred from one database to another in the form of a transfer package. These files are often stored on the file system as part of the database. The existence of these files does not affect the performance of Rational Synergy but they do affect the size of the database and the backup.

    You need to review the files in the <database path>/dcm for the generate, receive and log directories/folders to see if they are still required. The DCM administrator is possibly the best person to manage these files. See Administrating Rational Synergy Distributed for more information.

Related information

Monitoring Database Space
Removing Unwanted data
Reducing database size
PDF: CLI commands for 7.1

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 #: 1618321

Modified date: 15 April 2014

Translate this page: