Home » Server Options » Data Guard » standby alternative... is it possible?
standby alternative... is it possible? [message #110867] Thu, 10 March 2005 14:44 Go to next message
DBAgurrl
Messages: 2
Registered: March 2005
Junior Member
hello,

considering this architecture:

1 quad xenon machine + 1 dual xenon machine both installed with oracle 9i enterprise edition over RHEL AS 3.0. and connected to a raid'd emc2 SAN which hosts the datafiles for two separate oracle instances.

is this possible:

quad xenon dies, bring up the dual xenon pointing to the same exact files that the quad was pointing to.

essentially, the SAs are saying that they would pull out the drives of the down quad xenon and insert them into the dual xenon. both machines would be identical except for the number of CPUs.

will the dual xenon have any issue reading/writing to the database files stored on the SAN? will both oracle instances start up (and recover) without problems once the drives are installed in the dual xenon machine?

i have NO experience with SAN, and am trying to convice the SAs that standby is the only efficient means for failover (considering our budget), but they disagree...

any help would be most appreciated. i need ammunition!!

thanks!

kris


Re: standby alternative... is it possible? [message #110925 is a reply to message #110867] Fri, 11 March 2005 02:51 Go to previous messageGo to next message
Frank Naude
Messages: 4579
Registered: April 1998
Senior Member
Hi,

Yes, it should work - I've seen many sites that do exactly this. However, backup the database and schedule some test to ensure the solution is working as proposed.

A physical standby database will, however, still be better as you will have a duplicate set of the data on a separate machine. You are thus covered in case something happens to the machine or to the SAN.

Best regards.

Frank
Re: standby alternative... is it possible? [message #110982 is a reply to message #110867] Fri, 11 March 2005 11:52 Go to previous messageGo to next message
jbatista
Messages: 8
Registered: March 2005
Location: Horsham, PA
Junior Member
As Frank said, schedule some test to ensure the solution is working as proposed.

Also, this is possible with either Host based failover mechanism or Oracle (RAC) Primary/Secondary failover.

I am not sure whether Linux provides any Host based failover mechanism or not but you can always use the Oracle RAC failover mechanism.


Re: standby alternative... is it possible? [message #115552 is a reply to message #110982] Tue, 12 April 2005 11:03 Go to previous message
pscjhe
Messages: 38
Registered: April 2005
Member
Here are couple options that I can think of.
1. All in SAN or not
Make sure where are your parameter files, oracle software, database files. If they are all in SAN, you don't need to synchronize them when start from the second host when first host is down. If your oracle software, parameter files are in private disks, you need to synch whenever changes happen. Also a lot of manual work for client to reconnect or switch roles.
2. Split mirror
If you have mirrors for all of you database files, you can split mirror (you may need 'alter system suspend' depends on SAN) so that you will always have another copy of database for second host. It avoids possible human errors in option 1. But as in 1, it can protect data corruption such as block corruption.
3. Dataguard
If you already have EE licensed, apparently it is recommended to protect data errors. Relative easier to set up and change roles between nodes for hardware changes upgrades.
4. RAC
RAC won't protect your data errors plus additional license cost. But it does provide TAF for application.

I would argue that option 1 is least protective, longest downtime if SA has to pull drive from one and install them to the other computer. Even if I have to use SAN, I would go option 2. Since you have EE, which is expensive but required for DG. I would definitely go with DG.
Previous Topic: Logical Standby Performance overhead
Next Topic: Standby Database
Goto Forum:
  


Current Time: Thu Mar 28 18:48:51 CDT 2024