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

rkusenet wrote: > Did u try this. > > > First drop the index directly by querying the sysmaster > > 1. select tabid from systables where tabname = 'your problem table' > > 2. delete from sysindices where tabid = that_table_tabid ; > > 3. delete from sysconstraints where tabid = that_table_tabid ; > > shutdown IDS and restart IDS. > > > > then do this > alter fragment on table <your problem table > init in <dbspace>> > make sure that it is some new dbspace. > > this will try to reorg the table without using index (by doing light scan) > and get back as many rows as possible. > > finally you can put back all the index. > > this is your last chance. > No. I did not try this method and will do it as soon as I can get sole access to the system. (The other db is working since all the tables recovered.) The broken table is the largest, about 400GB in 8 fragments. Will try to identify the fragments that reported problems in the online.log that are related to the table and do alters on those and then try to rebuild the indices. (This email is from home - hence the different name) Thanks Bob PS All the chunks report PO from onstat -d.

basically by this method you are forcibly stripping the table of all its constraints and index and hopefully it should work. By doing this you have reduced all potential corrupted indexes. if you are lucky, your data pages weren't corrupted and hence alter fragment will move all of them to a new location. Realistically I am not that hopeful. Reason: You mentioned that select count(*) just sits. Well select count(*) with no where clausereads from the table header and it is a bad news if even that is corrupted. But we should not give up trying. "Bobb" <robertcb-1@comcast.net> wrote in message news:StWdnbtkA8_MXh_fRVn-oA@comcast.com... > rkusenet wrote: > > Did u try this. > > > > > > First drop the index directly by querying the sysmaster > > > > 1. select tabid from systables where tabname = 'your problem table' > > > > 2. delete from sysindices where tabid = that_table_tabid ; > > > > 3. delete from sysconstraints where tabid = that_table_tabid ; > > > > shutdown IDS and restart IDS. > > > > > > > > then do this > > alter fragment on table <your problem table > init in <dbspace>> > > > make sure that it is some new dbspace. > > > > this will try to reorg the table without using index (by doing light scan) > > and get back as many rows as possible. > > > > finally you can put back all the index. > > > > this is your last chance. > > > No. I did not try this method and will do it as soon as I can get sole access > to the system. (The other db is working since all the tables recovered.) > > The broken table is the largest, about 400GB in 8 fragments. Will try to > identify the fragments that reported problems in the online.log that are related > to the table and do alters on those and then try to rebuild the indices. > > (This email is from home - hence the different name) > > Thanks > > Bob > PS All the chunks report PO from onstat -d.

Hi RK, I tried accessing the systables and only found info on sysmaster tables. Similarly for sysindices. Am I missing something here? I created the db with the following statement (about 4 years ago) create userdb in userdb_dbs; As a result there is a lot of sysmaster stuff in userdbs_dbs as well as constraints etc which are local to the specific db. This dbspace also had errors but I ran oncheck against sysmaster and seemed ok....maybe not. Now I am not sure that it ran against the correct sysmaster tables (rootdb or userdb in userdb_dbs). It probably ran against the sysmaster in rootdbs and not the one in userdb_dbs. Also when I look at userdb tables under dbaccess I do not see the sysmaster stuff in userdb_dbs, only when I run oncheck -pe can I see the tables by the allocations. Any ideas on how to access this local sysmaster information? Bob rkusenet wrote: > basically by this method you are forcibly stripping the table > of all its constraints and index and hopefully it should work. > By doing this you have reduced all potential corrupted indexes. > > if you are lucky, your data pages weren't corrupted and hence > alter fragment will move all of them to a new location.> > Realistically I am not that hopeful. Reason: You mentioned that > select count(*) just sits. Well select count(*) with no where clause> reads from the table header and it is a bad news if even that is > corrupted. > > But we should not give up trying. > > "Bobb" <robertcb-1@comcast.net> wrote in message news:StWdnbtkA8_MXh_fRVn-oA@comcast.com... > >>rkusenet wrote: >> >>>Did u try this. >>> >>> >>>First drop the index directly by querying the sysmaster >>> >>>1. select tabid from systables where tabname = 'your problem table' >>> >>>2. delete from sysindices where tabid = that_table_tabid ; >>> >>>3. delete from sysconstraints where tabid = that_table_tabid ; >>> >>>shutdown IDS and restart IDS. >>> >>> >>> >>>then do this >>>alter fragment on table <your problem table > init in <dbspace>>>> >>>make sure that it is some new dbspace. >>> >>>this will try to reorg the table without using index (by doing light scan) >>>and get back as many rows as possible. >>> >>>finally you can put back all the index. >>> >>>this is your last chance. >>> >> >>No. I did not try this method and will do it as soon as I can get sole access >>to the system. (The other db is working since all the tables recovered.) >> >>The broken table is the largest, about 400GB in 8 fragments. Will try to >>identify the fragments that reported problems in the online.log that are related >>to the table and do alters on those and then try to rebuild the indices. >> >>(This email is from home - hence the different name) >> >>Thanks >> >>Bob >>PS All the chunks report PO from onstat -d. > >

taking off-line.