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 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 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 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 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 of concurrent_sessions (default: 100).