Hello,
After, the post Documentum : Moving Content Files via Administration Method MIGRATE_CONTENT (1/3) concerning the content’s migration via MIGRATE_CONTENT administration method, I propose to focus on content’s migration via Records Migration Job.
Reminder, Content Server supports three ways to move content files:
- 1. MIGRATE_CONTENT administration method
- 2. Records migration job
- 3. Migration Policy (need of Documentum Content Storage Services license)
2. RECORDS MIGRATION JOB
A records migration job moves batches of content files based on criteria you define. Records migration jobs are an alternate way to move a large number of content files if you do not want to execute MIGRATE_CONTENT manually or if you do not have a Content Storage Services license.
In DA, under “Job Management / Jobs / Records Migration Job:
Job Management:
+ Jobs
+ Methods
+ Administration Methods
Records migration jobs move content files from one storage area to another. The target storage area can be another file store storage area or a secondary storage medium, such as an optical jukebox or a tape. If the target storage area is secondary storage, the storage must be defined in the repository as a storage area. That is, it must be represented in the repository by some type of storage object.
When you define the records migration job, you can define parameters for selecting the files that are moved. For example, you might want to move all documents that carry a particular version label or all documents created before a particular date. All the parameters you define are connected with an AND to build the query that selects the content files to move.
When a records migration job runs, it generates a report that lists the criteria selected for the job, the query built from the criteria, and the files selected for moving. You can execute the job in report-only mode, so that the report is created but the files are not actually moved.
You must have superuser privileges to create a records migration job.
The procedure of creation is detailed from page 215 in the “Administrator Version 7.2 User Guide” http://www.emc.com/collateral/TechnicalDocument/docu57878.pdf, however, you would find below several important points:
- The selection of objects for migration is possible via Selection by criteria OR Selection via a query stored in dm_query
- The selection of objects (documents) by criteria is possible ONLY by ONE UNIQUE DCTM-system attribute of objects. Example:
r_aspect_name IS 'my_aspect_java'
So, the selection of object by attribute is not possible:- by attribute of attached ASPECT
- by custom attribute,
- by attribute in register table.
- The selection of objects (documents) by query stored in dm_query. The dm_query type could be created by DCTM API:
create,c,dm_query set,c,l,object_name myqueryhuo setfile,c,l,C:\temp\mig_query_huo.txt,crtext save,c,l
The file mig_query_huo.txt must be on DEVELOPER PC and has to contain the request:
SELECT doc.object_name, doc.r_object_id, doc.r_object_type FROM dm_document doc WHERE any doc.r_aspect_name = 'my_aspect_java';
The request must return dm_sysobject of sub-type of dm_sysobject (containing the r_object_type attribute). Otherwise the method adds automatically a filter in WHERE instruction “r_object_type <> ‘dm_plugin'” and we obtain the following ERROR :
- Query Used: select r_object_id, parent_id, rendition, parent_count, content_size, full_format, format, page, page_modifier, storage_id from dmr_content where any parent_id IN (SELECT r_object_id from dm_document WHERE any r_aspect_name = 'my_aspect_java';
Error: ExecQuery Failed for Main Query: select r_object_id, parent_id, rendition, parent_count, content_size, full_format, format, page, page_modifier, storage_id from dmr_content where r_object_type <> 'dm_plugin' AND any parent_id IN (SELECT r_object_id from dm_document WHERE any r_aspect_name = 'my_aspect_java'); in routine ExecShmeMethod
[DM_QUERY_E_NOT_ATTRIBUTE]error: "You have specified an invalid attribute name (r_object_type)."
- The migration job updates the r_modify_date and r_modifier fields of target objects type with the dm_query based on dm_document
- It is possible to designate and execute the job as a test only by setting job’s configuration. After running the job, the job’s report will the above precision:
NOTE: This is a report only - no objects will be moved.
- More informations could be specified in the job rules configuration:
- type of objects : my_huo_document
- target storage
- move all versions
- exclusion of objects that are already migrated
- formats : Primary format and/or Annotations and/or Renditions
- definition of version criteria : Affect the current version OR Affect the previous versions
- The Records migration job uses the system Administration method dm_Migration.
Here, an example of execution report available in :
SELECT * FROM dm_sysobject WHERE folder('/Temp/Jobs/My_ContentArchivingJob') ORDER BY r_creation_date DESC;
11/01/2016 5:03:57 PM Migration Agent Started
Connected To MY_DOCBASE_DEV.MY_DOCBASE_DEV
DMconnected to docbase MY_DOCBASE_DEV.MY_DOCBASE_DEV as mydctmuser
My_ContentArchivingJob Tool Completed at 11/01/2016 17:04:17. Total duration was 0 minutes.
Calling SetJobStatus function...
--- Start d:\Documentum\dba\log\xxxxx\sysadmin\My_ContentArchivingJobDoc.txt report output ----
My_ContentArchivingJob Report For DocBase MY_DOCBASE_DEV As Of 11/01/2016 17:04:02
Summary of Rule 'My_ContentArchivingJob'
-----------------------------------------------------------------------
- Objects of this type (and it's subtypes) will be moved: my_document
- Objects will be moved to filestore: centera_store_no_retention
- Object Selection:
- Objects are being selected by Query Object: myqueryhuo
- With Each Selected Object:
- The primary format will be moved. PRIMARY FORMAT
- Renditions will be moved. RENDITIONS
- Annotations will be moved. ANNOTATIONS
- The current version will be moved. CURRENT VERSION
- Previous Versions will NOT be moved.
- Only Including the Root Node of a Virtual Document
- Ignoring documents on filestores marked as 'Secondary'
- Number of filestores considered Secondary Storage: 0
- Query Used: SELECT doc.object_name, doc.r_object_id, doc.r_object_type FROM my_document doc WHERE any doc.r_aspect_name = 'my_aspect_java';
Object Name Owner Name Component Moved
----------- ---------- ----------------------------
MY DOC1 mydctmuser Primary Format Current Version
- - -
MY DOC2 mydctmuser Primary Format Current Version
- - -
Report End 11/01/2016 17:04:17
--- End d:\Documentum\dba\log\xxxxx\sysadmin\My_ContentArchivingJobDoc.txt report output ---
Successful Execution of Method
Migration Agent Disconnecting...
Migration Agent Completed at 11/01/2016 5:04:18 PM
Best regards,
Huseyin