Re: Complete in-place alters

On Oct 31, 6:21 pm, Fernando Nunes <domusonl...@gmail.com> wrote: > Habichtsberg, Reinhard wrote: > > > Fernando Nunes wrote > >> Habichtsberg, Reinhard wrote: > >>> Hi all, > > >>> In preperation for migration from IDS 9.40 to 11.5 we have > >> to complete all > >>> in-place alters. We have tables up to a billion rows with > >> many pending > >>> in-place alters. The amount of data adds up to some TB. > >> Why do you "have to"? Is that in IDS 11.50 documentation? > >> I know that this question can turn this into an hot topic... > >> I browsed through > >> the documentation very quickly and I think that step is not there... > > >> Note that if you need to revert you should not have pending > >> in-place alter tables. > > > In Migration Guide chapter 1: Overview of Dynamic Server Migration page 1.3 > > and 1.4 topics: Upgrading Dynamic Server (In-place Migration) and Migrating > > Dynamic Server (Non-in-place Migration): 1. Prepare your system. That > > includes removing outstanding in-place alters, ... > > > May be the reason is the reverting issue as you an OTC pointed out. Anyway > > it seems to be no mistake to the job. What I'm looking for is some advice to > > do it well... > > > Any further suggestions? > > Nice. On the detailed sections the reference does not exists as it's not a > requirement for the upgrade. As stated it's a requirement for the reversion. > Which leads me to a question: How many of you did a reversion, and why you did > it? Not flame intended. I understand perfectly the "prefer to be safe" point of > view... > > Regarding your points, or in other words, assuming you will remove the in-place > alters...: > > There is no real "magic" here. You can find out quickly with SQL which tables > _had_ an in-place alter at any time in the past. AFAIK there is no quick way to > get which tables have _pending_ in-place alters. I believe there is a feature > request for this, although I can't think of a way to do it quickly. > > Some suggestions: > - You can start by the quick SQL, and then look at the tables returned... If > they are small, it's probably better to do the dummy updates. > If they're big, you may want to consider the use of oncheck. > > - Note that a table that suffers the dummy updates will still appear in the > "quick SQL" > > - You can spend some days (if you have the time) doing some dummy updates in > batches, eventually at off-peak hours > > - If you have the hardware to do it (and most environments will not) you can > create an HDR secondary. If your migration is not successful, redirect the > clients to the secondary, while you restore your primary. Your secondary will > be with the image before the upgrade. Obviously this is not an option if you > decide to revert after running thins on the new version.... this leads to my > final comments: > > The question above, about how many times did you revert, and why (not a > question for you, but for whom wants to answer), is because, there are so many > restrictions on the reversion process that I find it hard to use it in a real > live scenario. > I had migrations that aborted (always while testing, thankfully), but in this > cases I ended up with a crashed instance. Reversion was not an option. Other > situations where I could consider reversion are probably related to problems in > the most important phases of a migrations: plan, test, plan, test, plan, > test.... ;) > > This year I did a lot of 7.31 to 10.00.FC8 (in place migrations) rather > successfully. Next year it will be for 11.50 (with platform change, so not > in-place). Reversion was never an option I considered. > > By the way, someone posted a script to find the in-place alters in the IIUG > list. I'm not sure if you're posting through IIUG or not, but in the newsgroup > I don't see the message with the script. It could be useful for you. If you > don't see it someone that follows the IIUG can send it to you. > > Regards. > > -- > Fernando Nunes > Portugal > > http://informix-technology.blogspot.com > My email works... but I don't check it frequently... When I upgraded from 9.21 to 10 I had problems with all of the tables that had in place alters during testing. It seemed like there was a bug. After I fixed the in place alters I didn't see the problems anymore. This could be superstition on my part but I am definitely fixing the in place alters before I upgrade to 11.5. Also, like anyone I want to be able to revert if I have to. Sorry, I am clearly not reading this site often enough to be helpful. I noticed that this is almost a month old.