Re: how to check chuncknumber 2 page 346207

unload to rowids.unl select rowid, * from problemtable then: unload to rowids.unl select rowid, * from problemtable where rowid > the last one found add 256 to it and unload therest.... unload to savetable.unl select * from problemtable unload to savetable_part2.unl select * from problemtable where rowid > the last one found add 256 to it Superboer. ddk24 schreef: > Hi Rob, > > Since I'm rather new, can you help me to unload around the bad rows?? > > Thanks, > Danny > > > RoB wrote: > >Re-run the oncheck -cDI and if the problem is still there then oncheck > >couldn't fix the it. > > > >What is the output from oncheck -cDI? > >Does the engine Assert Fail (AF) when accessing the rows on that tblspace? > > > >Is this tblspace for a table or index? If it's an index then just try > >dropping and recreating the index. > > > >Otherwise you might have to unload around the bad rows (all rows on that page) > >in the table if the engine AFs each time you access those rows. Try unloading > >all rows in the table to see what happens? If it finishes successfully > >without any AFs then you could just recreate the table and then load it again. > > > >Your interim version (xC2) is very old so this problem might have been caused > >by a bug in that release. Interim version 9.40.xC7 (or perhaps higher) is > >available. Personally I would NEVER NEVER NEVER NEVER EVER use any IDS > >interim below .xC4 in a production environment unless you REALLY LOVE dealing > >with product defects (speaking as an ex-advanced tech-support engineer).

Thanks Superboer, phase 1 is done. phase 2 did not succeed I get: Could not position within a file via an index. By the way, I drop the index in trying to recover the file. Now I can't even create it again. Any further suggestions? "Superboer" <superboer7@t-online.de> schreef in bericht news:1158211816.602352.299820@e3g2000cwe.googlegroups.com... > unload to rowids.unl > select rowid, * from problemtable> > > then: > unload to rowids.unl > select rowid, * from problemtable > where rowid > the last one found add 256 to it and unload the> rest.... > > unload to savetable.unl > select * from problemtable> > unload to savetable_part2.unl > select * from problemtable > where rowid > the last one found add 256 to it> > Superboer. > > > > ddk24 schreef: > >> Hi Rob, >> >> Since I'm rather new, can you help me to unload around the bad rows?? >> >> Thanks, >> Danny >> >> >> RoB wrote: >> >Re-run the oncheck -cDI and if the problem is still there then oncheck >> >couldn't fix the it. >> > >> >What is the output from oncheck -cDI? >> >Does the engine Assert Fail (AF) when accessing the rows on that >> >tblspace? >> > >> >Is this tblspace for a table or index? If it's an index then just try >> >dropping and recreating the index. >> > >> >Otherwise you might have to unload around the bad rows (all rows on that >> >page) >> >in the table if the engine AFs each time you access those rows. Try >> >unloading >> >all rows in the table to see what happens? If it finishes successfully >> >without any AFs then you could just recreate the table and then load it >> >again. >> > >> >Your interim version (xC2) is very old so this problem might have been >> >caused >> >by a bug in that release. Interim version 9.40.xC7 (or perhaps higher) >> >is >> >available. Personally I would NEVER NEVER NEVER NEVER EVER use any IDS >> >interim below .xC4 in a production environment unless you REALLY LOVE >> >dealing >> >with product defects (speaking as an ex-advanced tech-support engineer). >

Hello Danny, may be there is more then one page broken, add another 256 to the last row id. sorry a bit trial and error... > > By the way, I drop the index in trying to recover the file. Now I can't > even create it again. what index did you drop?? if the data is corrupt then it really makes sense that you can not recreate an index... Superboer. Danny De Koster schreef: > Thanks Superboer, > > phase 1 is done. > phase 2 did not succeed > > I get: Could not position within a file via an index. > > By the way, I drop the index in trying to recover the file. Now I can't > even create it again. > > Any further suggestions? > > > "Superboer" <superboer7@t-online.de> schreef in bericht > news:1158211816.602352.299820@e3g2000cwe.googlegroups.com... > > unload to rowids.unl > > select rowid, * from problemtable> > > > > > then: > > unload to rowids.unl > > select rowid, * from problemtable > > where rowid > the last one found add 256 to it and unload the> > rest.... > > > > unload to savetable.unl > > select * from problemtable> > > > unload to savetable_part2.unl > > select * from problemtable > > where rowid > the last one found add 256 to it> > > > Superboer. > > > > > > > > ddk24 schreef: > > > >> Hi Rob, > >> > >> Since I'm rather new, can you help me to unload around the bad rows?? > >> > >> Thanks, > >> Danny > >> > >> > >> RoB wrote: > >> >Re-run the oncheck -cDI and if the problem is still there then oncheck > >> >couldn't fix the it. > >> > > >> >What is the output from oncheck -cDI? > >> >Does the engine Assert Fail (AF) when accessing the rows on that > >> >tblspace? > >> > > >> >Is this tblspace for a table or index? If it's an index then just try > >> >dropping and recreating the index. > >> > > >> >Otherwise you might have to unload around the bad rows (all rows on that > >> >page) > >> >in the table if the engine AFs each time you access those rows. Try > >> >unloading > >> >all rows in the table to see what happens? If it finishes successfully > >> >without any AFs then you could just recreate the table and then load it > >> >again. > >> > > >> >Your interim version (xC2) is very old so this problem might have been > >> >caused > >> >by a bug in that release. Interim version 9.40.xC7 (or perhaps higher) > >> >is > >> >available. Personally I would NEVER NEVER NEVER NEVER EVER use any IDS > >> >interim below .xC4 in a production environment unless you REALLY LOVE > >> >dealing > >> >with product defects (speaking as an ex-advanced tech-support engineer). > >

thanks for the tip. I managed to recover pretty much "Superboer" <superboer7@t-online.de> schreef in bericht news:1158225585.041386.199540@h48g2000cwc.googlegroups.com... > Hello Danny, > > may be there is more then one page broken, > > add another 256 to the last row id. > sorry a bit trial and error... > >> >> By the way, I drop the index in trying to recover the file. Now I >> can't >> even create it again. > > what index did you drop?? > if the data is corrupt then it really makes sense that you can not > recreate an index... > > > > Superboer. > > Danny De Koster schreef: > >> Thanks Superboer, >> >> phase 1 is done. >> phase 2 did not succeed >> >> I get: Could not position within a file via an index. >> >> By the way, I drop the index in trying to recover the file. Now I >> can't >> even create it again. >> >> Any further suggestions? >> >> >> "Superboer" <superboer7@t-online.de> schreef in bericht >> news:1158211816.602352.299820@e3g2000cwe.googlegroups.com... >> > unload to rowids.unl >> > select rowid, * from problemtable>> > >> > >> > then: >> > unload to rowids.unl >> > select rowid, * from problemtable >> > where rowid > the last one found add 256 to it and unload the>> > rest.... >> > >> > unload to savetable.unl >> > select * from problemtable>> > >> > unload to savetable_part2.unl >> > select * from problemtable >> > where rowid > the last one found add 256 to it>> > >> > Superboer. >> > >> > >> > >> > ddk24 schreef: >> > >> >> Hi Rob, >> >> >> >> Since I'm rather new, can you help me to unload around the bad rows?? >> >> >> >> Thanks, >> >> Danny >> >> >> >> >> >> RoB wrote: >> >> >Re-run the oncheck -cDI and if the problem is still there then >> >> >oncheck>> >> >couldn't fix the it. >> >> > >> >> >What is the output from oncheck -cDI? >> >> >Does the engine Assert Fail (AF) when accessing the rows on that >> >> >tblspace? >> >> > >> >> >Is this tblspace for a table or index? If it's an index then just try >> >> >dropping and recreating the index. >> >> > >> >> >Otherwise you might have to unload around the bad rows (all rows on >> >> >that >> >> >page) >> >> >in the table if the engine AFs each time you access those rows. Try >> >> >unloading >> >> >all rows in the table to see what happens? If it finishes >> >> >successfully >> >> >without any AFs then you could just recreate the table and then load >> >> >it >> >> >again. >> >> > >> >> >Your interim version (xC2) is very old so this problem might have >> >> >been >> >> >caused >> >> >by a bug in that release. Interim version 9.40.xC7 (or perhaps >> >> >higher) >> >> >is >> >> >available. Personally I would NEVER NEVER NEVER NEVER EVER use any >> >> >IDS >> >> >interim below .xC4 in a production environment unless you REALLY LOVE >> >> >dealing >> >> >with product defects (speaking as an ex-advanced tech-support >> >> >engineer). >> > >