Re: Platform + version migration, no downtime?

Comments embedded

On Tue, 06 Jan 2004 23:45:12 +0100, Rick Denoire <100.17706_at_germanynet.de> wrote:

>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.

You would have better posted your transition plan, because currently you already seem to know the 'solution'. The solution, as demonstrated below, is not going to work however, and your assertions about customary migration methods are partly inadequate and partly incorrect.
Also in the Solaris/Solaris migration, you probably didn't make a proper distinction between preparation and the actual migration: backup scripts can be adapted beforehand, so you shouldn't take that into account when you specify a three to four days duration. The actual migration of a 20Gb database most likely took less than one day. I would have probably cloned the original 8.1.7 database to a new database, and migrated the new 8.1.7 database to 9ir2 using the migration assistant, and this procedure would have been -as the database format doesn't change- a piece of cake.

>
>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.

Synonyms exist. Synonyms can point to an object in a remote db. I don't consider this to be a trick, and I don't see which scripts would need to be tested.

>
>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.

On identical platforms, as the database format doesn't change, exp/imp is unnecessary, unless to reorganize the database at the same time.

> 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.
>

Migration in place would only change the datadictionary. The datafile format doesn't change.

>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?

(Advanced) replication by means of snapshot is by design logical. It is not going to work however, because replication only tracks changes, and the replicated database consists of snapshots, not of tables. You would still need to 'convert' your snapshots to tables.

 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"?

Standby database is not the same as replication. The standby feature replicates transactions. The existence of an up-to-date database on the standby server is a pre-requisite.
>
>If you wish to continue my brainstorming session, you are welcome!
>
>Regards
>Rick Denoire

--
Sybrand Bakker, Senior Oracle DBA