Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.misc -> Re: Can RedHat ASE 2.1 primary Oracle DB have SUSE physical standby?

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

From: Joel Garry <joel-garry_at_home.com>
Date: 25 May 2005 16:26:03 -0700
Message-ID: <1117063563.541472.210570@o13g2000cwo.googlegroups.com>

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

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.
Received on Wed May 25 2005 - 18:26:03 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US