Unanswered: SYSOBJSTATE corrupted after HPL load problems?
Hi to all,
We've a DW which uses the High-Performance Loader to add to it's tables in an overnight cron job (IDS 9.40.FC3W2 on Solaris 8) each weekend.
This weekend, it looks as though one of the jobs on the DW db kicked off early, and "fought" with the HPL load job :-( 15:34:18 Records Processed -> 6680000
Cannot set mode of indexes objects '"informix".xpkparcel' to enabled mode,
SQL error -242, ISAM error -106
Cannot re-enable all objects, 619595 violations detected,
check for violations in violations table 'parcel_vio'
and diagnostics table 'parcel_dia'
Database Load Completed -- Processed 6686934 Records
Records Inserted-> 6067339
Detected Errors--> 0
Engine Rejected--> 619595
I'm not worried about the violations, they're likely to be an overlap in data, as the previous week's unload/load didn't happen until Thursday night, so will have loaded a few extra days' data from the earlier part of last week...
The problem is, if I do a dbschema of the table in question, I get the column details and table privs, followed by an error: ...
revoke all on "informix".parcel from "public";
100 - ISAM error: duplicate value for a record with unique key.
Attempting to query Info->Status thru dbaccess menu, or "info status for parcel" thru SQL gives: 397: System catalog (sysobjstate) corrupted.
111: ISAM error: no record found.
(SELECT * FROM parcel / SELECT COUNT (*) FROM parcel also give 397/111 errors. )
There's no warning messages in the online.log, and to trace of an assert fail or shm dump on the server.
I'd like to canvass opinion of anything else I can try, before calling IBM Support. What stage has dbschema got to when it hits the duplicate/unique problem? (and does this shed any light on a possible fix?)
I've an ON-Bar (whole) backup we can restore, but I'm loath to do this, as it means messing around with the (legacy) unload jobs to ensure they pick up the correct data...
Thanks in advance for any advice! Please let me know if you want me to post additional info.
PS Forgot to mention, the table and indices are fragmented... unload to...
where tabid = 880
order by 1,2,5