We recently upgrded our PPM from 7.5 to 9.13 and I am trying to see if we can make use of the great new PPM DMS enhancement that PPM 9.13 introduced. Unfotunately, while trying for DMS migration from filesystem to PPM DMS I am getting some unexpected errors. :
" DMSDocumentException: Unable to destroy the document [DOCUMENT_ID=33728]. Please see server log."
And when I dig into Server Log I just see the following:
" ERROR :MigrationWorker(fe13e38a-d69b-4541-856f-e2598f9adb9e)-1:com.kintana.dms:2012/02/08-12:20:19.428 CST: java.sql.SQLException: ORA-29861: domain index is marked LOADING/FAILED/UNUSABLE "
Wonder if anyone has run into this this kind of error during their DMS Migration.
Do you have this error for all the documents migrated or only for some of them? If it's only for some of them, you can click the button "retry failed documents" any time to try again to migrate these documents.
Looks to me like the only domain index we are using in PPM are the PPM Database DMS Full Text Index. The message seems to indicate that the index was being in an invalid state (maybe it was rebuilt at that time), and thus deleting the related rows seems to be forbidden. More details on this error here:
If I remember, in the release notes it is advised to create the full-text indexes after the documents have been migrated to PPM Database DMS. There are multiple ways to solve this (if it is indeed a problem with the full text index).
The one I would advise is to drop the full text indexes, perform the migration, and then (re)create the full text indexes. If for any reason you cannot drop the full text indexes, just stop the automatic refresh which by default occurs every 10 minutes. It shouldn't be a problem to delete a row as long as the index is not in the process of being rebuilt.
Thanks for the response Etienne ! Sorry it took me while to reply back !!
One issue we were facing Yeasterday afternoon and evening was that we were getting that error regarding domain index even though our query for that index was showing that it was VALID.
Looks like this migration process created the domain index called "DMS_TIP_META_IDX" itself as DBAs verified that we didn't create that manually. But not sure why the difference in failure log and actual value in DB (Valid)...
BUT Great News is: I tried the whole thing again this morning and it just worked effortlessly ??? I don't think it had any impact but the only difference was that I had re-started my Application last night. .. Guess is it probably was somethng to do with DB and may be index creation was taking forever even though it mentioned VALID in the query..... No worries now though ... I plan on Prod dms migration on weekend right after my 7.5-->8.0-->9.13 Upgrade so can probably provde it few hours if needed...