07-21-2014 07:14 PM
I've been wrestling with the DCI recently (last few weeks). We upgraded from 6.2.5 to 7.1.2(2017), re-ran the DCI manually, on Date Registered periods. After that, I enabled the DCI event in TES and deployed the changes. The DCI event ran for some time and then stopped, blocked by error. The error message is:
HP TRIM Workgroup Server running on atmp02.main.dva reported the following message:
Error : VA User: ATMP22 - Error processing event on database 'VA' for processor 'Content Indexing', event details: 8234037, boburi=10002640, storeid=001+00A+0E5J0JTV0RM.PDF, error details: Function request (Extract Document) for HP TRIM Workgroup Server 'localhost' failed. Cannot read the file '\\Atmp21\EDMData\VA\5\001\00A\0E5J0JTV0RM.PDF'. The system cannot find the file specified. (0x00000002).
I ran the script on the database to find out which records were causing this error and found out that the record with the URI (10002640) was not in TSRECORD table. Also, there's no file on that URL in our document store. There were a few more DCI entries which were referring the non-existing records in TSRECORD.
Re-starting The workgroup servers did not help. Resuming the DCI event from TES did not help, either - it soon got blocked by the same error without having processed a single DCI event.
There are no TRIMpending.bin or TRIMtransactions.bin files in ISYS directories.
Our Document stores are fairly large, over 3 Tb, so there are many documents, large and small.
I suspect that, somehow, the DCI picks up the newly created records and stores those events in TSEVENTDAT. But, then, some things get in a way and delete those records - for which the DCI event has already been created but not processed. Then, at a later stage, those evetns get processed and, because the Records to which they refer, no longer exist in the database, the DCI process aborts....
It's just unclear to me - would this issue be causing the DCI to fail atogether? I would think that DCI would simply skip those event entries and proceeed with the other events, wouldn't it?
Thanks for help
07-21-2014 07:23 PM
Sounds a lot like this other post from yesterday:
7.1.X has had a number of issues already reported with DCI a number of those were addressed in later releases and since then the product as moved from ISYS to IDOL ( new indexing system) which is far more reliable, although can require more hardware to run.
Basically if you come across the 'blocked by error' message caused by events looking for documents that do not exist you will need to find the boburi number from the DCI logs, go to the db and use the boburi to find out which record is causing the problem. Then quarantine that document.
not an ideal scenario but unfortunately in that version this is the only work around.
07-21-2014 07:54 PM
That's what I would have done, if there was a record with that URI in TSRECORD. But, the problem is, that the event seems to be orphaned, referring to a non-existing record in tsrecord. So I even cannot quarantee it. But, because this wrong event is the first one in the TSEVENTDAT, it seems to be picked up and processed first, blocking the rest...
Just to clarify - a DCI event 's boburi referrs to a non-existing record (e.g., there is no entry in TSRECORD table with the given URI), trying to content index a non-existing file - e.g., there is no such like file in the specified document store...
What's worse, our database is managed by someone else and to get that someonelse to run the scripts is problematic, to an extent.
Maybe, other suggestions?
07-21-2014 08:11 PM
You could also remove it from the TSEventdat table.
07-21-2014 08:39 PM
07-21-2014 10:12 PM
You are right it wasn't an issue in 6.2 and it is not an issue in 7.3. Mostly in 7.1