Re: how much cpu on a database rac cluster

From: Mladen Gogala <gogala.mladen_at_gmail.com>
Date: Fri, 7 Sep 2012 20:38:55 +0000 (UTC)
Message-ID: <pan.2012.09.07.20.38.10_at_gmail.com>



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? The only argument that seemed even remotely compelling is the possibility of separate downtimes, but that doesn't stand up to scrutiny. 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? And what human resources are we talking about? A competent DBA? Why would it be any easier to maintain several instances on one box instead of maintaining only one? I really don't see any advantage to it. I am not sure that developers would even care. All they care about is a connect, string, schema and proper privileges to the underlying objects. 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.

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.

-- 
Mladen Gogala
The Oracle Whisperer
http://mgogala.freehostia.com
Received on Fri Sep 07 2012 - 15:38:55 CDT

Original text of this message