Minimizing down time on 24x7 app on migration from 8i to 9i

[Henrique Silva_3]

The environment is. An 24x7 application that is running on 8i on a MCSG ( two N4000 ) running hpux 11. The DB is about 40 GB right now.

We do not have DRP or failover in place, just MCSG to allow for package switching if we have a server failure.

Now, we need to upgrade to 9i. My idea was to install 9i on the inactive node, switch the SG package over, do the DB instance migration there ( requiring down time on the app here ), bring the app up, and then, do the oracle 9i bit upgrade on the original node.

Since I have not done this DB instance migration, can anyone give me an idea how long does this utility take to complete, and whether this is the way to go here ?

Another possible way to do this was to realize a testing box, where we could install 9i. Create a brand new instance there, then, do a dump of the 8i DB and load into the 9i one. This might take some time tough, and the app servers for the app would have to be down. Then, we could use that server as the production server for a while, update the oracle bits on the original MCSG nodes, and get a stand by setup going from this node to the MCSG setup and eventually, cut over to the MCSG servers.

Now, I believe we will have to have just as much downtime here, if not more, as the step above where we would be using oracle migration tools. I am trying to minimize downtime to the 24x7 app, and the problem that I can not seem to solve is that there is no way to keep this app up, even if we would move the DB to a DRP location, because the app servers are looking for some structure within the DB instance, and if we upgrade the DB instance to 9i, it might break that. I am not sure and can not be sure until I test it, but it would be nice to have somebody that had some experience about this in the past that I could learn from it.

I appreciate any help.

Henrique

[Steven E. Protter]

After practicing this a few times we managed to do it on a Sunday.

We installed the binaries and got them to coexist with the 8i binaries.

Then we practed the data instance migration a few times.

Then on a sunday we went through the process of 32 bit to 64 bit word size conversion and the rest of the process oracle outlines.

The window was set for 12 hours, we'd practiced it so much we got it done in 4.

SEP

[Henrique Silva_3]

Thanks Steven.

That helps a lot. I am planning on doing lots of practice runs here as well.

Henrique

[Thierry Poels_1]

Hi,

the required time for migration will more or less be the same for a 40GB DB as for a 100TB DB, as only the data dictionary needs to be migrated, application data & indexes are not touched.

As already said you can install Oracle 9i next to Oracle 8i, so there's no need or advantage in switching to other cluster nodes. Anyway DB migration is the fastest way to migrate, import/export would require much more down time.

regards,
Thierry.

[Henrique Silva_3]

Thanks Thierry.

That is what I suspect.

I will give it a go on a test environment and see what happens here.

Henrique

[Volker Borowski]

Hello Henrique,

since source release 8i is a bit unspecific, check Metalink document 214887.1 "Upgradeing directly to a 9.2.0 Patchset".

Depending on your startrelease you may save one "catpatch" run.

Steps when direct upgrade is possible:
- Install 9.2.0 SW ( 40-80 min. )
- Install Patchset (9.2.0.4 or 9.2.0.5) ( 20-40 Min )
- DB Migration ( 30-60 min )
- optional Steps dep. on installed components ( 30-60 min )
- Application dependend steps ( ???? )
- Client-SW update on all clients if required (???)

But this is not possible, if your source is i.e. 8.0.5 or 8.1.6. so please check that metalink note in addition.

Volker

[Henrique Silva_3]

Thanks Volker.

We are running 8.1.7.4 64 bit on HPUX.

I will check the metalink doc as well.

Henrique