Re: IDS 2000 9.21.UC4/Solaris/Sparc Problem accessing table - urgent

Some additional info: After I found systables and sysindices tables (hidden in userdb) can be accessed in dbaccess by just typing in the sys<tablesname> even though it is not listed. Was able to find entries of the damaged table and its indices. I ran oncheck -cdI against the 2 systables and it completed okay. We are trying every thing before making changes that may require us to restore everything from the last dump. We decided to again attempt oncheck against the damaged table. This time we noticed 2 threads were fired off and one of them is burning CPU (process loop?) and the other is 'waiting on join'. Still zero IOs after 20 minutes. Does this additional info shed any light? Bob 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