10g with HACMP (no RAC)?
Palooka
We are planning to implement Oracle 10.2.0.4 on AIX 5.3 with HACMP but
without RAC. The HACMP configuration will be active/passive.
The general idea is that the database will reside on shared EMC SAN, but
the Oracle binaries will be installed separately on both nodes. If the
instance on one node fails, the instance on the other node will mount,
recover and open the database.
I have Googled, and researched the Oracle and IBM documentation, but am
still confused. Do we need to install Oracle Clusterware? Are there any
other considerations? Is there a cookbook?
I'm a competent Oracle DBA and have reasonable experience with AIX, but
no knowledge of HACMP. Can anyone offer advice?
Thanks.
Palooka
sybr...@hccnet.nl
wrote:
>Hi,
>
>We are planning to implement Oracle 10.2.0.4 on AIX 5.3 with HACMP but
>without RAC.
Why? HACMP only offers server and application failover, it does not
offer any special facilities for Oracle. So the instances will not
failover properly.
In Oracle 10g RAC you don't even need HACMP!
Also Oracle RAC allows for active/passive configurations.
--
Sybrand Bakker
Senior Oracle DBA
Palooka
Two reasons: First, the application vendor does not support RAC, except
maybe as active/passive. But for that the RAC licence cost is
prohibitively expensive.
Secondly, whether we like it or not, the customer is a dedicated IBM
shop (personally I have doubts about AIX being the best *nix platform
for Oracle; I would far rather use Solaris or HP/UX). So HACMP is a given.
In any case, the architectural decisions have been made; I am just the
poor DBA who has actually to do the implementation. Can you offer some
practical advice?
Thanks,
Palooka
hpuxrac
snip
> In any case, the architectural decisions have been made; I am just the
> poor DBA who has actually to do the implementation. Can you offer some
> practical advice?
>
> Thanks,
> Palooka
http://oracle.ittoolbox.com/groups/technical-functional/oracle-db-l/hacmp-and-oracle-1152335
Palooka
downloaded the boulder docs and will peruse them with interest.
Palooka
DA Morgan
And why not Data Guard? First it is free ... Second it provides
transparent failover just like RAC.
--
Daniel A. Morgan
Oracle Ace Director & Instructor
University of Washington
damo...@x.washington.edu (replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org
Uwe Weber
just a few tips.
Palooka wrote:
> Hi,
>
> We are planning to implement Oracle 10.2.0.4 on AIX 5.3 with HACMP but
> without RAC. The HACMP configuration will be active/passive.
>
> The general idea is that the database will reside on shared EMC SAN, but
> the Oracle binaries will be installed separately on both nodes. If the
> instance on one node fails, the instance on the other node will mount,
> recover and open the database.
Make sure that the database VGs are 'enhanced concurrent' or failovers
will be painfully slow. If you want to have fast failovers, set MTTR
accordingly, so that the database will not have to apply huge amounts
of data from the redo logs. Put all the configuration files in your
ORA_BASE/admin into HACMP file collections to keep them in sync on al
HACMP nodes. Sync and verify the cluster after Test FAILOVER and RG move
after every change to the HACMP configuration or software. This means
planned downtime for your Oracle instance for every test :->.
Matthias Hoys
<sybr...@hccnet.nl> wrote in message
news:ob16c49uhqbvleb7f...@4ax.com...
> On Sat, 06 Sep 2008 21:14:28 +0100, Palooka <nob...@nowhere.com>
> wrote:
>
>>Hi,
>>
>>We are planning to implement Oracle 10.2.0.4 on AIX 5.3 with HACMP but
>>without RAC.
>
> Why? HACMP only offers server and application failover, it does not
> offer any special facilities for Oracle. So the instances will not
> failover properly.
>
I have used HACMP in the past with Oracle 8i & 9i on AIX 5.2 (also with EMC
SAN). What do you mean with "the instances will not failover properly" ? I
never had any problems with it, but of course, you always have downtime (in
our case 5-10 minutes) during a failover/failback since the instances have
to be stopped and the volume groups/filesystems unmounted on the active host
and mounted on the standby host. And, if you already have another instance
running on the standby host, you have to make sure the standby host has
enough free resources (CPU/memory) for the other instance.
But I don't think it's possible to have 100% uptime during a failover with
HACMP.
Matthias
Palooka
> Hi,
>
> just a few tips.
>
> will be painfully slow. If you want to have fast failovers, set MTTR
> accordingly, so that the database will not have to apply huge amounts
> of data from the redo logs. Put all the configuration files in your
> ORA_BASE/admin into HACMP file collections to keep them in sync on al
> HACMP nodes. Sync and verify the cluster after Test FAILOVER and RG move
> after every change to the HACMP configuration or software. This means
> planned downtime for your Oracle instance for every test :->.
>
>
Do we need to install any extra Oracle software (e.g clusterware)?
You mention the redo logs: I assume you refer to the online redo here,
since starting the database on the second node should presumably be, in
effect, the same thing as recovering from instance failure. That's
right, isn't it?
Palooka
Uwe Weber
No, afaik Oracle Clusterware and HACMP do the same things, i. e. defining
and monitoring of cluster ressources. IIRC you can build a failover
cluster with Clusterware as well as with HACMP. Only IBM support
will be lacking. Since IBM and SAP are aggresively marketing DB/2,
support for Oracle on AIX gets worse every day.
> You mention the redo logs: I assume you refer to the online redo here,
> since starting the database on the second node should presumably be, in
> effect, the same thing as recovering from instance failure. That's
> right, isn't it?
Yes, it is. If HACMP decides that the active node has gone missing,
it varies on the shared vgs, mounts the shared filesystems and sets
an IP alias with the cluster's ip on the "public" interface of the
standby node. It then executes all the application startup scripts
which you have configured into the Ressource Group (RG). One of these
scripts should start your Oracle instance, which will do an instance
recovery. Or at least this is the case with a node failure.
In case of a RG move your scripts should shutdown the instance on
the activie side and restart it on the other node.
Of course you have to do all the error checking in the scripts yourself
and take care of every possible situation that could go wrong with
db shutdown or startup.
Regards,
uwe
sybr...@hccnet.nl
<uwe....@teleos-web.de> wrote:
>Yes, it is. If HACMP decides that the active node has gone missing,
>it varies on the shared vgs, mounts the shared filesystems and sets
>an IP alias with the cluster's ip on the "public" interface of the
>standby node. It then executes all the application startup scripts
>which you have configured into the Ressource Group (RG). One of these
>scripts should start your Oracle instance, which will do an instance
>recovery. Or at least this is the case with a node failure.
>
>In case of a RG move your scripts should shutdown the instance on
>the activie side and restart it on the other node.
>
>Of course you have to do all the error checking in the scripts yourself
>and take care of every possible situation that could go wrong with
>db shutdown or startup.
>
>Regards,
>uwe
>
Obviously, not using RAC, you won't have any load balancing and
transparent application failover.
You also don't have the option of cross instance recovery (instance 2
helps instance 1 in recovery).
Consequently I don't understand why you see this as a viable solution.
sybr...@hccnet.nl
wrote:
>Thanks, Uwe. Your tips are noted.
>
>Do we need to install any extra Oracle software (e.g clusterware)?
>
>You mention the redo logs: I assume you refer to the online redo here,
>since starting the database on the second node should presumably be, in
>effect, the same thing as recovering from instance failure. That's
>right, isn't it?
>
>Palooka
Palooka,
Please note 'cheap' is usually a synonym for 'stupid'.
What HACMP has to offer has nothing to do with RAC, and it should not
be used as RAC replacement.
Basically HACMP is shared nothing technology and RAC is shared
everything technology.
Actually in 10g, using RAC, you don't even *need* HACMP anymore.
hpuxrac
snip
> Yes, it is. If HACMP decides that the active node has gone missing,
> it varies on the shared vgs, mounts the shared filesystems and sets
> an IP alias with the cluster's ip on the "public" interface of the
> standby node. It then executes all the application startup scripts
> which you have configured into the Ressource Group (RG). One of these
> scripts should start your Oracle instance, which will do an instance
> recovery. Or at least this is the case with a node failure.
>
> In case of a RG move your scripts should shutdown the instance on
> the activie side and restart it on the other node.
>
> Of course you have to do all the error checking in the scripts yourself
> and take care of every possible situation that could go wrong with
> db shutdown or startup.
>
> Regards,
> uwe
Of course hpux with service guard provides similar functionality ( but
OP noted that server decisions have already been made ).
Palooka
architecture, but as hpuxrac noted, the architectural decision has been
made. I just wanted some guidance as to what will be involved on the
Oracle side. It looks reasonably straightforward, provided, as Uwe says,
the scripts are tested thoroughly.
Regards,
Palooka
Uwe Weber
>
> Obviously, not using RAC, you won't have any load balancing and
> transparent application failover.
> You also don't have the option of cross instance recovery (instance 2
> helps instance 1 in recovery).
Of course not. Everything I know about Oracle on HACMP is from an
environment where they introduced HACMP back in ORA 7 days and slowly
started to migrate to RAC during their migration to 10g.
>
> Consequently I don't understand why you see this as a viable solution.
Where did I say that? But if the OP ist stuck with this anyway, I might as
well give him some info about it. I am not into RAC sales.
Regards,
uwe
Palooka
to go with RAC. Firstly, the application vendor doesn't actually support
it. Secondly, even if we had a database which was capable of transparent
failover, it wouldn't necessarily prevent loss of service; if the
application itself went down, it would have to fail over to its other
active/passive HACMP node. Plus there are two other layers.
The application, in business terms, is only as strong as its weakest
link. And some of us live in the real world, rather than in ivory towers.
Danke, mein freund.
Palooka
sybr...@hccnet.nl
wrote:
>Besides which, there are actually some reasons not
>to go with RAC. Firstly, the application vendor doesn't actually support
>it.
That would be the perfect reason to replace the application.
RAC is transparent to the application.
If a vendor states
'We don't support RAC'
this likely means 'My application is unscalable and it mightily sucks'
Note most application vendors still promote the 'database independent'
fairy tale, and a whole lot of so-called DBAs rather manage a mess and
get fired in the end, than to set up things professionally.
You seem to be no exception to this rule.
Your case is lost, yet you continue to defend it.
You will notice your case is lost SOON. Let's only pray Herr Weber is
there to help you out.
Palooka
integrators for a fee of around £2m. We are supposed to turn this down,
are we, because the client may not have made the best choice?
As I said, some of us live in the real world.
Palooka
DA Morgan
> And again, thank you. Besides which, there are actually some reasons not
> to go with RAC. Firstly, the application vendor doesn't actually support
> it.
That explains not going with RAC. Now can you explain why going with
HACMP, which costs money, makes more sense than going with Data Guard
which doesn't.
Shakespeare
<sybr...@hccnet.nl> schreef in bericht
news:pv6bc4541b7i2sn0r...@4ax.com...
So:
- Do you own a car?
- Did you ever have a flat tyre?
- Did your mechanic tell you to take run-flat tyres?
- Did he tell you they don't exist for your car?
- Did he tell you to buy a BMW, Mini, Lexus, Audi or other car that supports
run-flat tyres?
- Did he tell you your car mightily sucks and should be replaced?
Or did he just repair your tyre?
Shakespeare
Getting tyred....
sybr...@hccnet.nl
wrote:
>So:
>
>- Do you own a car?
No
Shakespeare
<sybr...@hccnet.nl> schreef in bericht
news:4olcc4h4v7ktd7tnc...@4ax.com...
<g> Guessed so...
Shakespeare
joel garry
£2m to bring in someone who asks for a cookbook??? And RAC is too
expensive? I tend to come down on the side of "real world," but that
just seems an alternate universe.
I don't know if I should say I'm in the wrong business or be glad I'm
not in the right business. Sybrand seems to be understating the
case.
jg
--
@home.com is bogus.
“There's nothing I can see that we did that was out of line.”
HAHAHAHA! http://www.signonsandiego.com/uniontrib/20080909/news_1n9united.html
Palooka
have been tasked with implementing the chosen solution in an IBM shop,
which is why I requested some guidance, and which some posters were kind
enough to provide.
In any case, Sybrand is way off base this time with his assumptions. The
application is not database agnostic, and has been benchmarked using IBM
facilities; it is limited in that the vendor does not support RAC,
except in an active/passive configuration, and the vendor has openly
stated that without major code changes, it will not scale at all with RAC.
Thus the issue at hand is resilience, rather than scaleability. Agreed
that RAC or DataGuard could offer transparent failover, but the
application itself is another component of the stack, and requires a
minute or two downtime in the event of failure.
Palooka
DA Morgan
Yet again ... why not Data Guard? For what technical reason?
--
Daniel A. Morgan
sybr...@hccnet.nl
wrote:
>facilities; it is limited in that the vendor does not support RAC,
>except in an active/passive configuration, and the vendor has openly
>stated that without major code changes, it will not scale at all with RAC.
>
>Thus the issue at hand is resilience, rather than scaleability. Agreed
>that RAC or DataGuard could offer transparent failover, but the
>application itself is another component of the stack, and requires a
>minute or two downtime in the event of failure.
Again, RAC is transparent to an application. RAC itself will not make
an application unscalable. If it is unscalable using RAC, it likely
doesn't scale as a normal app either. This means you need to have a
scalable OLTP app, to make it work under RAC sucessfully.
If the vendor doesn't support RAC, either it is not an OLTP
application, or he is not telling you everything.
RAC and Dataguard are two completely different beasts.
However, Dataguard will offer the protection you require at no extra
cost. HACMP is not required for the protection you require, nor is
HACMP required for RAC. Clusterware is a RAC component.
DA Morgan
> On Wed, 10 Sep 2008 01:45:35 +0100, Palooka <nob...@nowhere.com>
> wrote:
>
>> facilities; it is limited in that the vendor does not support RAC,
>> except in an active/passive configuration, and the vendor has openly
>> stated that without major code changes, it will not scale at all with RAC.
>>
>> Thus the issue at hand is resilience, rather than scaleability. Agreed
>> that RAC or DataGuard could offer transparent failover, but the
>> application itself is another component of the stack, and requires a
>> minute or two downtime in the event of failure.
>
>
> Again, RAC is transparent to an application. RAC itself will not make
> an application unscalable. If it is unscalable using RAC, it likely
> doesn't scale as a normal app either.
Technically true but not necessarily the full story.
RAC has what Oracle internally refers to as the spotlight effect.
While it is true that what is poorly written won't scale. And that
what is poorly written won't scale well in a stand-alone environment.
It is also true that RAC has a way of shining a very bright light on
unscalable code. It will fall over far faster on a RAC cluster than
stand-alone. That being, to a great degree, related to the sharing
of blocks, locks, and sequences across the cache fusion memory
interconnect.
What Palooka's vendor is saying is that they are selling a pile
of rubbish and that rather than fixing it they want their
customers to only install it in a configuration that covers up
for their errors in architecture and coding. They lose a few wise
customers but keep most people limping along.
If I found a vendor that said what Palooka's vendor has apparently
said I would be interviewing other companies and examining competitive
products.
What I can not understand, given that HACMP does not truly compete
with RAC but rather with Data Guard is why this discussion continues
to be about RAC.
--
Daniel A. Morgan
Oracle Ace Director & Instructor
University of Washington
damo...@x.washington.edu (replace x with u to respond)
Aya the Vampire Slayer
>What Palooka's vendor is saying is that they are selling a pile
>of rubbish and that rather than fixing it they want their
>customers to only install it in a configuration that covers up
>for their errors in architecture and coding. They lose a few wise
>customers but keep most people limping along.
Okay, I admit it, this got a chuckle out of me.
>If I found a vendor that said what Palooka's vendor has apparently
>said I would be interviewing other companies and examining competitive
>products.
If Palooka wants, he can tell the customer that it's likely the
application they chose is a pile of crap, but I don't see that really
changing the minds of the person who chose to go with it. We use pile-
of-crap applications where I work all the time (our source control
application comes immediately to mind), and many of us whine endlessly
about it, but nothing ever seems to change.
In any case, the customer made their decision, and Palooka should
probably stick within the bounds set by the vendor of the pile-of-crap
application, even if it's terrible and nonsensical. (I am making the
assumption here that Palooka's essentially a contractor hired by the
customer to set up the environment for some vendor's pile-of-crap
application)
Good luck, Palooka...
--
"Care must be exorcised when handring Opiticar System as it is apts to
be sticked by dusts and hand-fat." --Japanese Translators
"Keep your fingers off the lens." --Elton Byington, English Translator
sybr...@hccnet.nl
<ry...@gatech.rmv.this.part.edu> wrote:
>In any case, the customer made their decision, and Palooka should
>probably stick within the bounds set by the vendor of the pile-of-crap
>application, even if it's terrible and nonsensical. (I am making the
>assumption here that Palooka's essentially a contractor hired by the
>customer to set up the environment for some vendor's pile-of-crap
>application)
That may all be true, but the strange thing is
a) vendors always manage to put the blame somewhere else
b) bean-counters at end-users still continue to purchase that crap.
joel garry
> joel garry wrote:
> > On Sep 8, 3:51 pm, Palooka <nob...@nowhere.com> wrote:
> >> So the client decides on an application, and we are brought in as
> >> integrators for a fee of around £2m. We are supposed to turn this down,
> >> are we, because the client may not have made the best choice?
>
> >> As I said, some of us live in the real world.
>
> >> Palooka
>
> > £2m to bring in someone who asks for a cookbook??? And RAC is too
> > expensive? I tend to come down on the side of "real world," but that
> > just seems an alternate universe.
>
> > I don't know if I should say I'm in the wrong business or be glad I'm
> > not in the right business. Sybrand seems to be understating the
> > case.
>
> No, I am a reasonably competent DBA, but without experience of HACMP. I
> have been tasked with implementing the chosen solution in an IBM shop,
> which is why I requested some guidance, and which some posters were kind
> enough to provide.
>
Apologies, my rant is with the management that created your issues.
It appears to have all the red flags of a project doomed to failure.
One time I signed on as a contractor to implement one installation of
such a multi$M project, and wound up supporting the successful one
that was hacked out by a couple of guys. The IBM box gathered dust in
the warehouse.
jg
--
@home.com is bogus.
"This stop is Portland. Just kidding! Welcome to Irvine." - train
announcement this morning.
Palooka
> In any case, the customer made their decision, and Palooka should
> probably stick within the bounds set by the vendor of the pile-of-crap
> application, even if it's terrible and nonsensical. (I am making the
> assumption here that Palooka's essentially a contractor hired by the
> customer to set up the environment for some vendor's pile-of-crap
> application)
>
> Good luck, Palooka...
>
Thanks. And your assumption is not far off.
Palooka
Palooka
> Apologies, my rant is with the management that created your issues.
> It appears to have all the red flags of a project doomed to failure.
> One time I signed on as a contractor to implement one installation of
> such a multi$M project, and wound up supporting the successful one
> that was hacked out by a couple of guys. The IBM box gathered dust in
> the warehouse.
>
This IBM "box" (actually a pair of frames) is unlikely to gather dust in
the warehouse though; it has cost the client $$$ and is running a number
of applications on umpteen LPARs.
For what it's worth, AIX would not be my first choice *nix as a platform
for Oracle; I would much rather see it running on hpux, Solaris or
Linux. But that isn't up to me.
But just to annoy Morgan, there is some advantage in running HACMP. The
passive node can have almost nothing allocated to it in terms of memory
and processors. These can be dynamically allocated in the event of the
need for failover. Yes, we sacrifice the transparent failover which
DataGuard can provide, but other components of the stack will lose
uncommitted transactions, and/or require a minute or so of downtime,
should they fail. There is no significant business advantage in having
the Oracle layer any more available than the other components in the stack.
Palooka
DA Morgan
And DBAs will continue to get paid to keep the ship from sinking.
What a world.
DA Morgan
> joel garry wrote:
>> Apologies, my rant is with the management that created your issues.
>> It appears to have all the red flags of a project doomed to failure.
>> One time I signed on as a contractor to implement one installation of
>> such a multi$M project, and wound up supporting the successful one
>> that was hacked out by a couple of guys. The IBM box gathered dust in
>> the warehouse.
>>
> Accepted.
>
> This IBM "box" (actually a pair of frames) is unlikely to gather dust in
> the warehouse though; it has cost the client $$$ and is running a number
> of applications on umpteen LPARs.
If it is a z10 please contact me off-line.
The Boss
> Palooka wrote:
>> joel garry wrote:
>>> Apologies, my rant is with the management that created your issues.
>>> It appears to have all the red flags of a project doomed to failure.
>>> One time I signed on as a contractor to implement one installation
>>> of such a multi$M project, and wound up supporting the successful
>>> one that was hacked out by a couple of guys. The IBM box gathered
>>> dust in the warehouse.
>>>
>> Accepted.
>>
>> This IBM "box" (actually a pair of frames) is unlikely to gather
>> dust in the warehouse though; it has cost the client $$$ and is
>> running a number of applications on umpteen LPARs.
>
> If it is a z10 please contact me off-line.
A z10 doesn't run AIX nor HACMP.
Are you alluding to IBM and Oracle's strategy for a Virtualized Data Center,
combining IBM's hypervisor z/VM and Linux (RHEL or SLES) with Oracle's
Maximum Availability Architecture build on DataGuard and (optionally) RAC?
Although we are still on z9, I would be very interested in any Oracle
related z10 info [or z10 related Oracle info ;)]
--
Jeroen
DA Morgan
> A z10 doesn't run AIX nor HACMP.
No but the use of the term LPAR was an indication that some zSeries
might be there somewhere in the mix and I am looking for Oracle on
zLinux sites for a project I am working on.
> Although we are still on z9, I would be very interested in any Oracle
> related z10 info [or z10 related Oracle info ;)]
Shoot me an email requesting it and you will get what I have and
can release.