Re: how much cpu on a database rac cluster
Date: Mon, 10 Sep 2012 14:57:39 +0100
Message-ID: <MPG.2ab802327bf8052d989a0d_at_News.Individual.NET>
In article <pan.2012.09.07.20.38.10_at_gmail.com>, gogala.mladen_at_gmail.com says...
>
> On Fri, 07 Sep 2012 12:15:26 +0100, Jeremy wrote:
>
> > You have to consider the costs of the differnet resources. Hardware
> > resources are fixed price, commodity. Human resources are not. Without
> > knowledge of the differnet applications and the way the business runs,
> > you are not able to make the judgement as to whether it is "better" to
> > consolidate in a single database.
>
> Well, I don't see what would be gained by having several instances on the
> same box?
Suppose you were migrating from ultiple servers, different applications?
> The only argument that seemed even remotely compelling is the
> possibility of separate downtimes, but that doesn't stand up to scrutiny.
Applications upgrades as opposed to Oracle upgrades perhaps?
> The only operation that would force me to shut down the instance is
> patching. And patching applies to the ORACLE_HOME, not an instance. If I
> am patching one ORACLE_HOME, I have to shut down all instances living on
> that particular home address.
> Why would database separation be easier than the schema separation?
Supposing there are public synonyms which might clash? Slim chance I guess (cue a response about why public synonyms are a bad thing). But as I work for a SaaS provider I can see why you might want a separate instance for a particularly heavy usage customer - who might want to isolate themselves from the upgrade cycle of other SaaS customers on a shared instance. In addition, having a separate instance makes it easy to move that to a dedicated server if required.
Having reread what I have written above one might argue that the separate customer could simply placed into its own schema for apps upgrade isolation. And from there moving to its own dedicated instance on a separate server would be quite easy. So I could be having an argument with myself here.
> There are
> some simple rules that need to be enforced, in order to maintain the
> technological discipline:
>
> 1) Never allow the applications to log in as the table owner. Be very
> careful with the privileges and procedures. Use " AUTHID CURRENT_USER"
> wherever possible. Application users can own views, not tables.
> 2) Separate unrelated data in the different schemas.
> 3) Separate data by the storage requirements. Separating indexes and
> table data is no longer necessary
> 4) Have developers use DBMS_APPLICATION_INFO SET_CLIENT_INFO or
> SET_MODULE to identify the major portions of the code.
> 5) Use the application server pooling, not Oracle pooling. The latter is
> not ready yet.
> 6) Have any schema/application change properly reviewed and signed off by
> a (competent) DBA.
>
Sounds right.
> Without maintaining the proper technological discipline, the applications
> will be of very low quality and will inevitable be wasting the company
> money. The real question is whether the company stands to gain something
> by using low quality applications? If yes, then I am wrong. Not only am I
> wrong but I am also a wrong release of DBA. I am DBA 1.0. There is new
> and improved DBA 2.0 who would gladly create more than a single instance
> on a box. I would fight it tooth and nail.
Well this is irrelevant to the question of whether in some cases it is appropriate to run more than one Oracle instance on a single server.
-- jeremyReceived on Mon Sep 10 2012 - 08:57:39 CDT