Re: More than one RAC instance/database on the same machine ?

We need N databases and not N schemas because we work for the state/government (not in France as my email suggests) and every db has nothing to do with each other (finance, police, social, etc)

So we really need to make them independent and be able to stop one without stopping the others.

We're getting 2 P690 ibm machines. (quite powerful)

Thanks

"Howard J. Rogers" <hjr_at_dizwell.com> wrote in message news:<41845390$0$22820$afc38c87_at_news.optusnet.com.au>...
> DA Morgan wrote:
>
> > Howard J. Rogers wrote:
> >
> >> DA Morgan wrote:
> >>
> >>
> >>>Le JeanMimi wrote:
> >>>
> >>>
> >>>>First, thank you for your answers.
> >>>>
> >>>>For us, the point is availability (and not scalability).
> >>>>
> >>>>Say we have two databases A and B and two machines.
> >>>>We put A and B in RAC configuration :
> >>>>- instance A1 and B1 on machine 1
> >>>>- instance A2 and B2 on machine 2
> >>>>(A1 and A2 for database A, B1 and B2 for database B)
> >>>>
> >>>>If the machine 1 crashes, then all the work being done by A1 and B1
> >>>>failover to machine 2 (TAF) and everything is very fast ... and
> >>>>transparent.
> >>>>
> >>>>Does it make sense ?
> >>>>Thanks (i'm rather new to this)
> >>
> >>
> >> [snip]
> >>
> >>
> >>>Makes no sense to me. Put one database on A, one on B and build two
> >>>schemas.
> >>
> >>
> >> Precision! Do you mean "database" or "instance"?
> >>
> >> "One database on [node] A and one on [node] B" means there isn't
> >> necessarily a RAC any more.
> >>
> >>
> >>>Now you have half as many things to go wrong. What do you
> >>>think you accomplish with 2 System tablespaces, 2 UNDO tablespaces, 2
> >>>SGAs? I mean accomplish as in desirable?
> >>
> >>
> >> Er, perhaps because you have two databases which behave quite
> >> differently, get backed up quite differently... why does any organisation
> >> ever need more than one database?
> >>
> >> The issue is not whether it's pure or not. Oracle's own tools quite
> >> happily let you add additional databases to an existing cluster, so they
> >> don't think the rule should always and forever be 'one cluster, one RAC
> >> database'. So it's do-able and it's acceptable.
> >>
> >> And if you've got a thumping great big hardware cluster, and one database
> >> isn't even getting close to stretching the thing; and you have a
> >> legitimate business or managerial reason for building a second database;
> >> why not put it on the slackly-used cluster, too?
> >>
> >> HJR
> >
> > This is RAC ... one instance per server. Sorry for the lack of languge
> > precision.
> >
> > Can you explain to me how two databases behave quite differently?
> > Databases don't behave on a node ... instances do. Thought I'd return
> > the favour. ;-)
>
>
> Well, in your eagerness to be smart, you stuffed up. Because of course
> databases behave differently from each other. What do you back up? A
> database or an instance? And if you have a read-mostly database, do you
> back that up at the same frequency you do a write-mostly one?
>
> And does it make sense to have a read-mostly database in archivelog mode?
> And the command to put a database into archivelog mode is indeed "alter
> DATABASE archivelog".
>
> Should my sales database also do duty as my employees pay records database?
> Is not a database a collection of *related* data?
>
> > I've heard that argument before ...
>
> Good, then deal with it.
>
> > but you are speculating
>
> That isn't dealing with it. That is hoping you can wish it away.
>
> > and from my
> > experience
>
> And that is an 'argument from anecdote'. Your experience isn't the be-all
> and the end-all, nor does it determine the argument adequately.
>
> > I've yet to see a "real" situation where a second instance,
> > rather than a second schema, was really required.
>
> You really are all over the place, aren't you? You, the avowed advocate of
> RAC, have a problem with anyone needing a second *instance* now??
>
> Sort your language out. Think properly about what it is that you're trying
> to say. And deal with the argument about why anyone would ever need more
> than one database in their organisation if what you claim is true.
>
> Once you acknowledge someone's need for multiple databases, and couple that
> with their desire to be able to quickly failover multiple databases, then
> the argument for putting instance A & B on one node, with backup instances
> on the other node, makes entire sense.
>
> But if you are going to continue to claim that multiple schemas are all we
> ever need, then let's not prolong the discussion, because in that case you
> are wrong.
>
> HJR
Received on Sun Oct 31 2004 - 02:45:53 CST