Before the Migration
Though migrating DMS is practically as simple as clicking a button in the Administration Console, there are a few things of interest to know before proceeding. Before you start the migration, read the following carefully and take necessary actions:
Update Tablespaces before the Migration
If your DBA wants to change the tablespace used to store the document contents, this should preferably be done before the migration, as there is no data in the tables at that point. If you already started a migration before but cancelled it, there are already some data in the OpenText PPM Database DMS DB tables; you can safely truncate these tables. But do NOT change anything in the KNTA_DOCUMENTS table, as it is used by all three DMS solutions to store document information and should never be modified manually.
Create Indexes on Tables AFTER the Migration
If you plan on using Full Text search, do NOT create the indexes on the tables before the migration. The reasons are:
-
Performance impact on migration, additional load on Database Server CPU during the migration due to indexes update.
-
Updating the index while new documents are being added can result in more fragmented indexes, especially if the indexes are set to SYNC (ON COMMIT). You can get better results by creating the index after all documents are added.
-
Trying to remove a document (which can happen during the migration) while the TEXT index is currently being constructed can result in an Oracle error (
ORA-29861: domain index is marked LOADING/FAILED/UNUSABLE
).
Configure to Relieve Load on PPM Service Nodes during the Migration
The default DMS Migration settings provides a good migration speed, but might result in a heavy load on PPM Service nodes and OpenText PPM database. The easy way to relieve the load during peak hours is to pause the migration (this can be easily done from the migration page in the Administration Console).
However, if you want to alleviate the overall load on PPM Server during the migration process, you can:
-
Update the following parameters from the Administration Console of OpenText PPM before starting the migration (No PPM Server restart needed)
Parameter name
Description, Usage
Default and Valid Values
DMS_MIGRATION_DELAY_BETWEEN_DOCUMENT
Specifies duration (in seconds) that a thread waits between two documents to migrate. To lighten the load of the migration process on the PPM Server, increase the value of this parameter.
Default:
0
Valid values:
integer
DMS_MIGRATION_THREAD_COUNT
Specifies number of threads that migrate documents on a given PPM Service node.
Default:
3
Valid values: integer
DMS_MIGRATION_DOCUMENTS_BATCH_SIZE
Specifies the number of documents that to be queued for migration on a given PPM Service node. Every time the DMS Migration Engine Service runs on a Service node, the queue of documents to migrate is filled up.
Default:
1000
Valid values: integer
-
Change the scheduling of the DMS Migration Engine Service on the Schedule Services page. This dedicated heavy service runs regularly and fills a queue of documents to migrate on the PPM Server node where the service runs (which could be any node configured to run heavy services). Default setting is to run the service every 30 seconds. However, do NOT enable or disable that service manually from this page.
For details about configuring the DMS Migration Engine Service, see the Configure the migration background service .
Special Notes When Documentum is the Current DMS
If you are migrating from Documentum-based DMS to OpenText PPM Database DMS, you might run out of Documentum sessions during the migration with the default configuration (including default Documentum Server configuration).
The reason is that documents operations are asynchronous, and Documentum sessions can be busy for some time even when the document operation on PPM Server has completed. As the DMS Migration is a very demanding process, sometimes you might run out of Documentum sessions, which results in failure of some documents to be migrated.
This is not a blocking issue as you can retry migrating failed documents until they are successfully migrated. However, it results in unneeded manual operations. You can reduce the probability of running into such an issue by resorting to the following options:
-
Use one migration thread only.
-
Add a delay between documents to migrate (of 1 second or more). This gives time for the asynchronous operations to complete. Considering the performance impact, you should only resort to this option after you have tried to migrate all documents at least once.
-
Reduce the documents migration batch size so there can be some idle time between two migration service triggering.
-
Increase the maximum number of Documentum sessions on Documentum server. To do so, edit the
$DOCUMENTUM/dba/config/<
DOCBASE_NAME>/server.ini
file, and increase the value ofconcurrent_sessions
(default:100
).