Can RedHat ASE 2.1 primary Oracle DB have SUSE physical standby?

[Dave]

We are trying to migrate or DB from RH 2.1 to SUSE 9,
need to do it with no downtime (we have a standby).

Can we re-create standby on SUSE platform and switch to it
(e.g. will the redo logs generated by RedHat ASE 2.1
2.4.9-e.27enterprise be compatible with SUSE 9 kernel 2.6.5?)

I know the primary db and standby must be the same OS,
the question if those two linux distributions are compatible enough?

Thank you!

Dave

[=?iso-8859-1?Q?Lin=F8nut?=]

Dave poked his little head through the XP firewall and said:
We are trying to migrate or DB from RH 2.1 to SUSE 9, need to do it with no downtime (we have a standby). Can we re-create standby on SUSE platform and switch to it (e.g. will the redo logs generated by RedHat ASE 2.1 2.4.9-e.27enterprise be compatible with SUSE 9 kernel 2.6.5?) I know the primary db and standby must be the same OS, the question if those two linux distributions are compatible enough?

Wish I could help you. Probably the best source for your answers would
be a group covering the database you are wishing to migrate.

--
When all you have is a hammer, everything looks like a nail.

[John Bailo]

Dave wrote: We are trying to migrate or DB from RH 2.1 to SUSE 9, need to do it with no downtime (we have a standby). Can we re-create standby on SUSE platform and switch to it (e.g. will the redo logs generated by RedHat ASE 2.1 2.4.9-e.27enterprise be compatible with SUSE 9 kernel 2.6.5?) I know the primary db and standby must be the same OS, the question if those two linux distributions are compatible enough?

The OS will have nothing to do with it. You could do this between
Solaris and SCO Unix if you wanted to.

The database server will have everything to do with it. If you're using
a replication program that's part of the DBMS ( I guess Oracle in this
situation ) it should work by connecting the databases using IP
address...the two database servers will "talk" to each other using
whatever protocol your DMBS vendor uses for replication.

Capisce?


Thank you! Dave


--
Texeme
http://texeme.com

[Sybrand Bakker]

On Mon, 23 May 2005 18:09:00 -0700, John Bailo <jabailo@texeme.com>
wrote:
The OS will have nothing to do with it. You could do this betweenSolaris and SCO Unix if you wanted to.The database server will have everything to do with it. If you're usinga replication program that's part of the DBMS ( I guess Oracle in thissituation ) it should work by connecting the databases using IPaddress...the two database servers will "talk" to each other usingwhatever protocol your DMBS vendor uses for replication.Capisce?

Regrettably, this is fully incorrect.
Standby <> Replication, so OS *does* matter, at least until 9i.
Standby means : the primary database ships online redo logs file to
the standby server. No individual transactions are being shipped.
This means both O/Ses have to be identical.


--
Sybrand Bakker, Senior Oracle DBA

[chao_ping]

Hi, Sybrand,
While John Bailo is in-correct , your answer is not very precise.
If same oracle executable can run on both platform, then yes, you
can run standby on redhat/suse.
Oracle suggest you use identical os release and even os patch
level, but this is not necessary.

[Dave]

Thank you for replies guys!

I don't get however why the binary compatability is the issue.
If I understand it properly, the Primary doesn't run it's executables
on Standby and vice versa.

It transports the arch redo logs using network protocol and applies to
Standby. So as long as arch redo log file format is the same, they
should be compatible.

Am I missing something?

[Joel Garry]

Dave wrote: Thank you for replies guys! I don't get however why the binary compatability is the issue. If I understand it properly, the Primary doesn't run it's executables on Standby and vice versa. It transports the arch redo logs using network protocol and applies to Standby. So as long as arch redo log file format is the same, they should be compatible. Am I missing something?

Well, it's probably what you are not missing, namely, bugs.

Oracle clearly states (Note 234508.1):

3.2 Limitations ---------------
Primary and Standby Database must
- reside on the same Platform
- use the same Oracle Baserelease (eg. 9.2.0)

Primary and Standby should have
- the same Patchlevel (eg. 9.2.0.3)
- the same OS-Version
- the same Hardware Configuration

--- End Inclusion ---

Now, the "why" of this isn't so easily ascertained. If you start going
through the recent bug lists, you will see many configurations have
bizarre little bugs. And that's supported configurations. I can
imagine adding unsupported configurations exponentiates the problems,
or rather the difficulty of isolating the problems. Not to mention all
the various options for standby.

Referring to a previous post about binaries, I'm sure you must realize
that installing Oracle requires linking to certain libraries. Those
libraries must be identical across the platforms, or who knows what may
happen. Very heterogenous platforms obviously may have issues of the
data actually being formatted differently, but near-platforms may have
more subtle issues, such as how RFS handles interactions with TCP. And
your kernels are different enough to be worrisome.

That is enough to explain why you shouldn't run a production setup
across platforms. But you aren't really doing that, you are doing a
one-time conversion. So your assertion about the log file formats
becomes reasonable, and the answer becomes, "go ahead and try it." But
give it a lot of grief, high transaction loads and some network
plug-pulling, at least. Your management may be persuaded to allow some
down time to do it "correctly," and you might give CTAS + index
rebuilding some consideration. Or it may work in testing, but not in
the actual cutover, since you can't exactly anticipate or duplicate
what will happen. Management always _loves_ that, especially with the
bugs that blow back into the primary database.

Now, why is comp.os.linux.advocacy on this xpost? And no Oracle
version? Could this be a troll?

jg
--
@home.com is bogus.
"Some recovered datafiles maybe left media fuzzy" - seen in 9206 alert
log. Reminds me of my old roomies' science experiments in
refrigeration.