Translating with DrWatson… this can take a few seconds the first time.
This is a genuine, complex translation. DrWatson protects commands, error codes, and log output while naturally translating the surrounding text. It’s translated once and saved.
Bobb reported a table on IDS 9.21.UC4 where oncheck, dbaccess and ontape -s -L 0 all hung, with no errors in online.log after restarts and other tables fine. Siebrand suggested oncheck -cc and -cID. Scottishpoet suspected hardware and asked whether dd could read the device; Robert C B said yes. No resolution in the thread.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
Hi Bob,
I would recommend performing an oncheck against the instance.
oncheck -cc
oncheck -cID
Cheers,
Robert C B wrote:
> We had a hardware controller glitch yesterday and the IDS engine
> panic-ed and crashed. This history was reconstructed from online.log.
>
> Informix came up after rebooting the OS, recovered from the logs and
> gave no error indications. (Lost the af... dump )
>
> Of a total of about 50 tables in 2 major databases there is one table
> that appears to be unaccessible.
>
> 1. A simple 'select count(*) from tabname;' sits around and gets no
IO
> (onstat -u).
>
> 2. In dbaccess table/info/tabname/status does not complete. At the
> bottom of dbaccess page it shows 'Running.....' but does nothing
>
> 3. dbaccess table/info/index will list the indices ok.
>
> 4. dbaccess table/info/fragments just hangs and will not complete.
>
> 5. oncheck on the table just just hangs around and does not get any
IOs.
>
> 6. An attempt to drop the primary index just hung and did no IOs.
>
> 7. Have restarted IDS several times and there are no error messages
of
> any kind related to this table in the online.log. The table still
does
> not function (as if some lock is being held in sysmaster??)
>
>
> One of the temporarily failed disks contained a fragment of this
table.
> However there were over a dozen failed disks from other
> tables/fragments and they now work fine including the dbspace for
> physical log..
>
> We need to be able to access the info in this table We would really
> prefer not to restore from the last backup which is about 2 weeks
old.
>
>
> Help please
>
> Bob Bankay
In reply to the last couple of suggestions:
1. All other tables in the same db work fine. So the hardware in now working.
2. Among the first things that I did was try to run oncheck and it just sat and
did nothing on the damaged table.
I have been using informix since 1999 and have had previous failures and done
recoveries including unloading and loading back the data, skipping over corrupt
pages. However this is the first time that no dbaccess or utitlity will give me
a reading on the table AND the online.log does *not* show any errors for the
table after numerous informix restarts.
PS. We tried to do an ontape -s -L 0 and it just hung when it came to the table.
Bob
siebrand@gmail.com wrote:
> Hi Bob,
>
> I would recommend performing an oncheck against the instance.
> oncheck -cc
> oncheck -cID>
> Cheers,
>
> Robert C B wrote:
>
>>We had a hardware controller glitch yesterday and the IDS engine
>>panic-ed and crashed. This history was reconstructed from online.log.
>>
>>Informix came up after rebooting the OS, recovered from the logs and
>>gave no error indications. (Lost the af... dump )
>>
>>Of a total of about 50 tables in 2 major databases there is one table
>
>
>>that appears to be unaccessible.
>>
>>1. A simple 'select count(*) from tabname;' sits around and gets no
>
> IO
>
>>(onstat -u).
>>
>>2. In dbaccess table/info/tabname/status does not complete. At the
>
>
>>bottom of dbaccess page it shows 'Running.....' but does nothing
>>
>>3. dbaccess table/info/index will list the indices ok.
>>
>>4. dbaccess table/info/fragments just hangs and will not complete.
>>
>>5. oncheck on the table just just hangs around and does not get any
>
> IOs.
>
>>6. An attempt to drop the primary index just hung and did no IOs.
>>
>>7. Have restarted IDS several times and there are no error messages
>
> of
>
>>any kind related to this table in the online.log. The table still
>
> does
>
>>not function (as if some lock is being held in sysmaster??)
>>
>>
>>One of the temporarily failed disks contained a fragment of this
>
> table.
>
>> However there were over a dozen failed disks from other
>>tables/fragments and they now work fine including the dbspace for
>>physical log..
>>
>>We need to be able to access the info in this table We would really
>>prefer not to restore from the last backup which is about 2 weeks
>
> old.
>
>>
>>Help please
>>
>>Bob Bankay
>
>
We use strictly necessary cookies to make this site work. With your
consent we’d also use optional cookies for analytics and marketing. You can accept all,
reject all, or choose. Read our Cookie Policy.