OnDemand Users Group

Support Forums => CMOD for Multiplatforms => Topic started by: LWagner on April 08, 2013, 04:42:54 PM

Title: experience with orphaned indexes ?
Post by: LWagner on April 08, 2013, 04:42:54 PM
Loading to a new app group, we had three partial load failures.  Data was not loaded but indexes were. On access to those record, the server has no record to retrieve.  Delete of the loadid returned 0 rows deleted, and the index rows are still present.

Would an SQL delete of the index rows in question have any negative impact on the the system ?  There seem to be 294 rows in the three loads.
Title: Re: experience with orphaned indexes ?
Post by: Justin Derrick on April 09, 2013, 10:32:34 AM
I'd be more inclined to use arsdoc delete with an SQL command that deletes the index rows based on the doc_name field.

Are you on 8.5.0.6?  I'm seeing this behavior in a customer site as well.

-JD.
Title: arsload -f ?
Post by: Ed_Arnold on April 09, 2013, 03:08:53 PM
Hi Larry -

Are you using the -f parm? 

Quote-f
    Use to unload the data if the load process fails. If the database manager step fails, then Content Manager OnDemand should remove any index data that was added to the database. If the storage manager step fails, then Content Manager OnDemand should remove any storage objects that were copied to storage volumes.

Ed
Title: Re: experience with orphaned indexes ?
Post by: Justin Derrick on April 09, 2013, 08:41:12 PM
Hey Ed.

When my customer has tried that, they still get zero rows unloaded, and the rows persist (and are returned in queries).

-JD.
Title: Re: experience with orphaned indexes ?
Post by: jeffs42885 on July 01, 2014, 02:35:07 PM
Bumping this back to life- JD did you resolve this by any chance? I am seeing this issue when unloading VIA system load folder.
Title: Re: experience with orphaned indexes ?
Post by: Justin Derrick on July 01, 2014, 03:31:56 PM
I don't have a good answer -- I wasn't involved in the ultimate resolution.

I don't know if anyone had any success with the 'arsdoc delete' option with an SQL statement using the Doc_Name field though.

-JD.