In place alter issue

I am cleaning up my in place alters for my migration to 11.5. I have everything working. I can find them. I can fake update them. I only have one problem when I fake update them I get the following after running oncheck -pT db:table Home Data Page Version Summary Version Count 0 (oldest) 0 1 (current) 15961 I know I don't have any records in the old format but the version is still around. I fiddled around and found that if I alter the primary index to clustered I get: Home Data Page Version Summary Version Count 0 (current) 15961 What is going on and how can I fix it without doing a cluster on the index that I don't want to do? Or do I even need to fix it?

You don't need to fix it... You'll only see the second output after recreating the table. This is why it's not possible to get all the tables with "pending in-place alters" in a quick way. The "quick" way will always see the tables that *had* a pending alter. And to get a similar output you have to read all the partition pages... Regards. On Wed, Nov 26, 2008 at 2:28 PM, bozon <curtis@crowson1.com> wrote: > I am cleaning up my in place alters for my migration to 11.5. I have > everything working. I can find them. I can fake update them. I only > have one problem when I fake update them I get the following after > running oncheck -pT db:table > > Home Data Page Version Summary > > Version Count > > 0 (oldest) 0 > 1 (current) 15961 > > I know I don't have any records in the old format but the version is > still around. I fiddled around and found that if I alter the primary > index to clustered I get: > > Home Data Page Version Summary > > Version Count > > 0 (current) 15961 > > What is going on and how can I fix it without doing a cluster on the > index that I don't want to do? Or do I even need to fix it? > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list > -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...

On Nov 26, 12:25 pm, "Fernando Nunes" <domusonl...@gmail.com> wrote: > You don't need to fix it... > You'll only see the second output after recreating the table. > > This is why it's not possible to get all the tables with "pending in-place > alters" in a quick way. The "quick" way will always see the tables that > *had* a pending alter. > And to get a similar output you have to read all the partition pages... > > Regards. > > > > On Wed, Nov 26, 2008 at 2:28 PM, bozon <cur...@crowson1.com> wrote: > > I am cleaning up my in place alters for my migration to 11.5. I have > > everything working. I can find them. I can fake update them. I only > > have one problem when I fake update them I get the following after > > running oncheck -pT db:table > > > Home Data Page Version Summary > > > Version Count > > > 0 (oldest) 0 > > 1 (current) 15961 > > > I know I don't have any records in the old format but the version is > > still around. I fiddled around and found that if I alter the primary > > index to clustered I get: > > > Home Data Page Version Summary > > > Version Count > > > 0 (current) 15961 > > > What is going on and how can I fix it without doing a cluster on the > > index that I don't want to do? Or do I even need to fix it? > > _______________________________________________ > > Informix-list mailing list > > Informix-l...@iiug.org > >http://www.iiug.org/mailman/listinfo/informix-list > > -- > Fernando Nunes > Portugal > > http://informix-technology.blogspot.com > My email works... but I don't check it frequently... Thanks for your help. Using SQL to find the pending in-place-alters works pretty fast, much faster than oncheck does.

bozon wrote: > On Nov 26, 12:25 pm, "Fernando Nunes" <domusonl...@gmail.com> wrote: >> You don't need to fix it... >> You'll only see the second output after recreating the table. >> >> This is why it's not possible to get all the tables with "pending in-place >> alters" in a quick way. The "quick" way will always see the tables that >> *had* a pending alter. >> And to get a similar output you have to read all the partition pages... >> >> Regards. >> >> >> >> On Wed, Nov 26, 2008 at 2:28 PM, bozon <cur...@crowson1.com> wrote: >>> I am cleaning up my in place alters for my migration to 11.5. I have >>> everything working. I can find them. I can fake update them. I only >>> have one problem when I fake update them I get the following after >>> running oncheck -pT db:table >>> Home Data Page Version Summary >>> Version Count >>> 0 (oldest) 0 >>> 1 (current) 15961 >>> I know I don't have any records in the old format but the version is >>> still around. I fiddled around and found that if I alter the primary >>> index to clustered I get: >>> Home Data Page Version Summary >>> Version Count >>> 0 (current) 15961 >>> What is going on and how can I fix it without doing a cluster on the >>> index that I don't want to do? Or do I even need to fix it? >>> _______________________________________________ >>> Informix-list mailing list >>> Informix-l...@iiug.org >>> http://www.iiug.org/mailman/listinfo/informix-list >> -- >> Fernando Nunes >> Portugal >> >> http://informix-technology.blogspot.com >> My email works... but I don't check it frequently... > Thanks for your help. > > Using SQL to find the pending in-place-alters works pretty fast, much > faster than oncheck does. I didn't explain myself correctly. The "sql way" will check the partition headers. This more or less reads one page per partition. But as you doubt shows, it only shows the partitions (tables) that at some point in time were in-place altered. Oncheck reads all the partitions pages to count how many of them are in each version. Much slower of course, but it's the only way to really be sure. The SQL version will keep reporting all the tables, even those you applied dummy updates to. I'm not against the sql way... If the tables found are not many and are not too big you may get the SQL and the dummy updates for the found tables before you get the results from oncheck... By the way, you could also do the same that oncheck does, with SQL on sysmaster, but it would take the same amount of time... Regards. -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...