Expiring index data

Indexes expire (are eligible for removal) because their life of data period has passed. The indexes, and the documents that they point to, can then be removed from the system. When you remove an index, information about the document to which it points is removed from the database (the document can no longer be retrieved). However, because indexes are eligible to be removed does not mean that they will be deleted from the database. IBM® Content Manager OnDemand does not delete expired index data from the database until expiration processing runs.

The application group expiration policy determines when index data is eligible for deletion from the database. You define the expiration policy when you create the application group. The following properties on the Storage Management page comprise the expiration policy:
  • Life of data and indexes. The length of time in days to maintain index data and documents on the system. After the index data is on the system for this number of days, it is eligible to be deleted. The value of Life of Data and Indexes is set in the Storage Management tab of the Content Manager OnDemand application group definition. If you change this value after you have loaded data, the change affects the data that is already in Content Manager OnDemand as well as any new data loaded after the change is made.
    Tip: If you specify Never Expire, then expiration processing is disabled for the application group. (That is, index data will not be removed from the database.)
  • Expiration Type. Determines whether individual indexes or an entire table of index data is deleted at a time. When Content Manager OnDemand deletes index data, it either deletes a row (if the Expiration Type is Document), deletes all rows for the specific load (if the Expiration Type is Load), or deletes a table (if the Expiration Type is Segment). The amount of index data in a table and the number of reports the data represents is determined by the Database Organization. If the Database Organization is Multiple Loads per Database Table, then by default, Single table for all loads is selected, in which case there is no maximum number of records for the index table. If you clear the Single table for all loads check box, then by default, a table of index data can hold up to 10 million indexes. You can modify the maximum number of rows by changing the Maximum rows value.

A table of index data is not eligible to be deleted until the latest date in any of its rows reaches the Life of Data and Indexes period. For example, suppose that the Life of Data and Indexes is set to 365 days, the Expiration Type is set to Load, and the Database Organization is set to Multiple loads per database table. If you have cleared the Single table for all loads check box, a table will contain approximately 10 million rows. Further, suppose that a report is loaded into the application group once every month and that each report adds one million rows to the database. Each table can hold the index data from approximately 10 reports. Using these assumptions, the data that is loaded into the application group in January will be eligible to be deleted by expiration processing in January of the following year. You should consider selecting Single table for all loads if you have a small number of documents to be archived over time. You should not select Single table for all loads if your Expiration Type is Segment.

Content Manager OnDemand uses the application group's expiration policy to determine when indexes and documents expire and should be removed from the system. The archive storage manager marks documents for removal based on the Expire level specified in the migration policy. For more information on migrating and expiring documents, and recommendations for storage management criteria defined in your application groups, storage sets, and migration policies, see Defining document storage management.