Re: Platform + version migration, no downtime?

Rick Denoire <100.17706_at_germanynet.de> wrote in message news:<99cmvvc5m3tt94m9be96t3c2hj23h68djm_at_4ax.com>...
> Hello
>
> I am in the process of migration of two databases. The first one went
> from Oracle 8.1.7 to 9.2.0.4 on the same host (Sun-Solaris). That was
> done successfully via export/import, but it took 3 to 4 days to finish
> (including testing, adapting backup scripts etc.).
>
> The second one is going from Oracle 8.1.7/Sun:Solaris 7 to
> 9.2.0.4/Intel:RH-Linux-AS; it is about ten times larger than the first
> one. In this case, using a similar procedure would take ten days at
> least (don't forget the network bottleneck). That is way too long. I
> am forced to reexamine my transition plan and need some breaking
> ideas.
>
> I am wondering if it is possible to do the transition in parts, one
> schema at a time, without disturbing normal work. But setting up a DB
> link for moved schemas does not seem to be a solution because too many
> scripts would have to be changed and tested; something would break. I
> am not aware of any other "trick" to implement a distributed DB.
>
> Another solution would be perhaps to try to upgrade the source DB
> from 8.1.7 to 9.2.0.4 in place on the same host first, using the
> migration procedure to avoid time consuming exp/imp. In a second step,
> a replication between the two platforms (Sun and Linux) would be setup
> and let run smoothly until replication is complete, while work keeps
> going in the source DB; finally, only switching to the new platform by
> a simple tnsname change would be necessary.
>
> Doing migration in place is a little bit risky, so I think that I
> would need a cold backup first, adding 10 hours to the procedure.
>
> But the crucial question here is if it is possible to do an online
> replication of databases of the same Oracle version but on different
> platforms... Is there something like a logical replication? I think I
> have heard something similar. Not blocks are transferred, but redolog
> entries (I think). I don't know if "replication" is the right word.
> "Shadow database"? "Stand by database"?
>
> If you wish to continue my brainstorming session, you are welcome!
>
> Regards
> Rick Denoire

Rick,

> Doing migration in place is a little bit risky, so I think that I
> would need a cold backup first, adding 10 hours to the procedure.

You could use a modified cold backup:

create a physical hot backup set on disk via the standard methods. copy the archived redo logs that were created during the hot backup set into the backup staging area.
once that has completed, shutdown the database instance. copy the controlfiles and online redo logs into the backup staging area.
You now have a cold backup set.

See, if you restore this backup set, you will have to perform media recovery, but as you have the current controlfile and the online redo logs, recovery will be complete, and no resetlogs will be required.

I have used this multiple times, where I could not afford the length of time of a cold backup set. It works for me.

hth.

Pd Received on Fri Jan 09 2004 - 13:35:58 CST