Serviceguard for Oracle failover

[Delrish]

Hi All,

Just two quick questions, Is it possible to setup oracle singular database (NOT RAC) with service guard just for failover? I mean using Service Guard for failover the oracle database.
What is the difference between Service Gaud failover and Oracle RAC failover? Are there work with together? Which one is recommended for this case (oracle failover)? Is service guard preparing any extra facility?

[Duncan Edmonstone]

There are a lot more simple 'failover' databases out there than there are implementations of RAC. Serviceguard has been deployed with Oracle in failover configurations for many years now, and from a practical resilience perspective I think is actually better than RAC (a much simpler solution = lots less things to go wrong than in a RAC configuration - also much easier to manage)

In a standard serviceguard configuration the database runs on only one node in the cluster at a atime - if that node fails the database is restarted on another node - all clients have to reconnect once oracle has restarted, which usually takes a few minutes... In a RAC cluster the database is running simultaneously on all nodes in the cluster, but each client connects to s specific node - if that node fails then clients attached to that node must re-connect to another node, while oracle rolls back and cleans up uncommited transactions on the failed node. In theory RAC offers better levels of resilience (simply reconnect to another node use the transparent application failover functionality in SQLnet), but in my opinion in practice this is rarely the case - the complexities in running RAC usually make for more downtime than you would get from a simple failover database - of course you'll never hear this from Oracle themselves - they don't make as much money in licensing out of you if you implement a failover database rather than a RAC database.

RAC comes into its own when you need the scalability that a single SMP system won't provide - if your cost models won't allow you to build a failover configuration.

So to summarise, if resilence is your main concern then consider a failover cluster, if scalability is more important, consider RAC.

HTH

Duncan

[Kent Ostby]

Yes ... you can set serviceguard up in a simple failover scenario with Oracle quite easily using HP's toolkit product.

http://www.software.hp.com/portal/swdepot/displayProductsList.do?category=HA

Depending on what version of HP-UX you are on, you can get the Enterprise Cluster Master Toolkit off of that page.

Best regards,

Oz

[Geoff Wild]

Yes - you can setup oracle singular database in MC/SG environment - in fact - you could have multiple db's controlled by MC/SG.

In this scenario, Oracle would be unavailble during a failover (we are talking a few minutes only).


Rgds...Geoff

[B. Hulst]

Hi,

You don't have to use Oracle RAC in clusters.

The best solution is is a MC/SG cluster that is aware of the Oracle RAC behavior. :-)

But also price and development time plays a role...

Regards,
Bob

[TwoProc]

It's actually a pretty easy process to Service Guard over an Oracle Database. It will take two parts - one system to learn on, and one to get up and running. HP was generous enough to give us a temporary license for Service Guard to learn how to implement this on some test systems. I also had the benefit of using HP consulting to help with the project, which of course made it really an easy project. After playing with it in test (with HP consulting) we put it in production with some Friday afternoon prep work, and then finished the install on Saturday. All in all not nearly as bad a project as I had envisioned. But, if your company allows for such, using HP consulting to get it done will make the whole project small in scope and quite painless. We used only 4 days of consulting for the whole thing - a very reasonable cost for a good, solid failover system.

[Bob_Vance]

IMHO, if you can afford it, RAC is better than MCSG simple failover.
I've seen it take 20 minutes get an Oracle DB back up in a SG failover scenario (although I haven't worked with any SG+Oracle lately;>), while, with RAC, half the users never know anything happened. Also, a query will continue on a new node without logical interruption (although there can be a perceived pause in a long query).

Further, with RAC, you have *both* nodes processing transactions at the *same* time, rather than having one node doing nothing. However, SG has the advantage of handling other applications, as well, so you could have the other node doing other "guarded" work.

Of course, Duncan is certainly right about the money -- RAC is not exactly a free lunch :>)

I'm curious as what you mean, Duncan, by the "complexities in running RAC" ? Also, have you had any experience with RAC 10g? It seems pretty simple to me. (I'm not challenging your opinions -- I'm just curious as to any actual bad experience you've had with RAC, especially 10g.) BTW, technically, users don't normally connect to a particular node, but, instead, connect to a "service", which will allows for automatically balancing of connections across all the nodes.


tks
bv

[Duncan Edmonstone]

Bob,

No all my experiences are with OPS & 9i - I have no doubt that things are getting better with 10g and when I have the chance I'll certainly take a look at it.

Complexities for me come from:

1. No filesystems (and no I don't count OCFS as a filesystem - only datafiles a nd redo files can live on them and you can only talk to them with specific tools) - OK this will be addressed in Q3 this year on HPUX and is already not a problem on some other platforms (notably Tru64), but right now you have to use raw disk - that makes a lot of people nervous!

2. Application tuning - no matter what Oracle say, you simply don't get 'near linear scalability' from RAC when adding nodes - this usually means some fairly involved perf tuning by some fairly technical DBAs to tune SQL for running acros the cluster.

3. Reaction to failure... OK so a standard cluster can take a long time to failover (I'm interested in ones that take 20 minutes! Mine generally take about 2-3 minutes), but the response to failure is pretty consistent - I have found RAC to behave quite bizarrely in some failure scenarios - and recovery from these situations often takes hours rather than minutes.

Perhaps I didn't explain myself correctly - I'm not saying that a well implemented, well tested and well managed RAC cluster isn't more reliable than a Serviceguard cluster, merely that given the complexities of RAC, the simpler option might be appropriate for some sites. I'd also argue that for some people a single-node system will have better HA than a cluster - it all depends on your peoples skills and proficiencies.

Cheers,

Duncan

[Duncan Edmonstone]

Perhaps I can phrase this another way:

Required to run standalone oracle = average sysadmin, average dba

Required to run oracle failover cluster = good sysadmin, average dba

Required to run oracle RAC cluster = good sysadmin, good dba

Thats my main point...

Duncan

[Bob_Vance]

Thanks, Duncan.

As I said, I haven't been done an SG+Oracle cluster for a while (2+ years -- well, actually I'm in the middle of one right now :>) and the 20 minutes was a while before that and after a node failure, not just a package move.

Anyway, I'm a little nervous about 9i, as well -- I would definitely recommend 10g, and ASM makes it so easy. As for performance, 10g is supposed to be self healing and tuning, but I have no actual data to back it up in a RAC environment.

OTOH, I would say that SG+Oracle is certainly a well-known and mature environment.


tks
bv

[Delrish]

Thank you
But
As i understand in singular database, SG canhandle the failover.
In RAC enviroment which obe handle the failover? ServiceGuard or Serviceguard extension for RAC?
I think we should install SGE for RAC just when we want to use filesystem for storage. Is it correct? If we want to use ASM or RAW device for storage, Is it still neccessary to install SGE for RAC?
Do I get the point correctly?

Regards,
Alireza

[Florian Heigl (new acc)]

A few days ago I read a bit about this here.
I think it's like this

Filesystem: MC/SG + RAC extension
RAW dev: MC/SG + RAC extension
ASM: MC/SG w/o RAC extension or (I think) just RAC

[Duncan Edmonstone]

Lets make sure we have this straight:

Serviceguard only = Cold failover of a non-RAC oracle database (i.e. database runs on only one node at any one time). The database can be on raw disk or on a file system.

Serviceguard extension for RAC = Serviceguard provides cluster services for RAC databases (database runs on all nodes consurrently). This is a must for 9i databases, but is not necessarily required for 10g databases, as oracle have their own cluster services in 10g. However I would maintain that SGeRAC does add value anyway as it allows you to do such things as provide failover for network cards, and cluster any non-database components that might also be on the same box. One thing I see people using standard Serviceguard for in SGeRAC is for NFS packages for archived redo areas so they can be moved around for backup/recovery purposes.

Regardless of whether the database is 9i or 10g and whether you are using SLVM, VxVM or ASM, you cannot put a RAC database on a filesystem on HP-UX. (However in Q3 this year HP will release a product combining SGeRAC with Veritas's clustered volume manager and filesystem which *will* allow you to do this.)

Naturally a lot of people see this current lack of filesystem as a weakness when compared to oracle RAC on windows or linux where you have OCFS, but as I have previously mentioned, what good is a filesystem if the only thing that can talk to it is the database anyway? OCFS is (as far as I am concerned) a bit of a gimmick, rather than a true value-adding feature.

HTH

Duncan