Resolving The Problem
You have objects stored in the resource manager in a particular volume with an associated storage class that you want to migrate to another volume and storage class (for example, for archiving purposes). When you define a new migration rule in an existing migration policy, the objects are not migrated to that new volume and storage class as defined by the newly added migration rule.
For objects stored that have already reached their final migration destination according to the old migration rules, the new rules are not in effect for those objects. So, the resource manager migrator does not migrate those objects.
Before you do the following steps, you should identify the collection ID (collection name) and the storage class. You must know which collection provides the location for storing those existing documents. In the example used in this technote, the collection name is COLL1 with a collection ID of 3 and the storage class name is FIXED with a storage class ID of 1. You can find this information in the RMCOLLECTIONS and RMSTORAGECLASS tables.
Important: The information in this technote supports migration rules that have been appended with only one new transition. This final transition must be a rule with a retention period of forever. That means that the existing objects can only be migrated to a target storage one time and that the target storage must be the permanent place for holding those objects.
1. Stop your resource manager server and all resource manager services.
2. Back up your resource manager database. This step is very important because some important metadata will be modified in this procedure.
3. Connect to the resource manager database and run these SQL queries:
- For DB2: db2cmd
- For Oracle: sqlplus
4. Identify the collection ID.
5. Identify the storage class ID of the final rule before the new migration rule that was added.
6. Calculate the date for the new OBJ_ACTIONDATE in the format MM/DD/YYYY. See the example after this procedure for more details about how to calculate the date.
|7. Run the following SQL query, where MM/DD/YYYY is the date, Collection_ID is the collection ID, and Storage_class_ID is the storage class ID:
7. Check the RMMIGRATIONTASKS table to determine whether rows of items have been inserted.
8. Start your resource manager server and start the migration service. Check the results.
Here is an example that uses the steps in the previous procedure:
For a given collection named COLL1 and a collection ID of 1 that is derived from a storage group and a migration policy, the storage group contains a storage class named FIXED with an ID of 1. The migration policy is named MGTCLASS and the migration policy has these rules:
You want to modify this migration policy to migrate to a new storage class named TSM that is used to migrate objects to Tivoli Storage Manager. After you change the existing rule and add the new migration rule, the migration policy has these rules:
Assume that today is May 28, 2009. If you want to update the assets stored in FIXED and follow the new duration of 2 days, then the assets that are currently stored in FIXED should have the OBJ_ACTIONDATE="05/30/2009".
Based on this information, you would run the following SQL query for your database:
Was this topic helpful?
05 February 2020