RE: looking for tool to help consolidate Oracle schemas within Or acle instances and Oracle instances on AIX servers

  • From: DENNIS WILLIAMS <DWILLIAMS@xxxxxxxxxxxxx>
  • To: "'oracle-l@xxxxxxxxxxxxx'" <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 21 Apr 2004 09:15:43 -0500

Jaco 
   Here is what I believe.
1. Overall there isn't much difference in hardware requirements whether all
workload goes through a single instance or multiple instances. I don't think
you will be able to detect a difference. If you have other test results,
please post them.
2. Once you've got an application installed, don't move it unless you have a
good reason. If it ain't broke, don't fix it. Yes, I did change my
philosophy, but I have only applied that changed philosophy to new
applications. I didn't go back and consolidate existing applications.
3. Managers are tending to look at the database to DBA ratio. This is
ridiculous, of course, but their responsibility is ensuring their DBA
resources are being well-utilized. Until we propose something better, they
will tend to look at this ratio. Just because your managers aren't looking
at this ratio today doesn't mean they won't look at it tomorrow. It would be
ironic that you go through an extensive consolidation effort only to have
management decide they have too many DBAs now that the ratio looks better.
4. I don't think there is a lot of difference between supporting X users on
one instance or across several instances. As you have outlined yourself,
there are factors both ways that tend to cancel each other out. By
consolidating instances you must examine resource usage more carefully.
5. I think that DBA effort is minimized by configuring an instance properly
when it is installed and then leaving it alone. Too many DBAs have the
"perfectionism" disease. A lot of problems are self-inflicted.
6. If making continual changes promotes your value to management and keeps
you employed, then I am in favor of continual changes, since I like a
regular paycheck. But I'm still hoping for that independently wealthy thing.

Dennis Williams
DBA
Lifetouch, Inc.
dwilliams@xxxxxxxxxxxxx 

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of J.Polet@xxxxxxxxx
Sent: Wednesday, April 21, 2004 5:52 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: looking for tool to help consolidate Oracle schemas within
Or acle instances and Oracle instances on AIX servers


Dennis,

It is very interesting to hear that you are tending to go the opposite
direction based on your experience.

The benefits we are hoping the achieve is easier database management and
less hardware resources.
We know that management will become complexer when consolidating  schemas
in instances but  we think we can handle that by using the right tools in
the right way.

In our envirmont we do have same vendor applications with specific Oracle
requirements but most of our application are just looking for a set of
tables to store their data without extra requirements about the oracle
version or oracle features. Even some vendor applications, as a result of
their database indepency,  are using the database for basic datastore.
That is the reason why we think that we can consolidate most of our
applications in a minimum number of instances.
We are  in fact already doing that in some instances for applications for
which there are no special requirements and for which there are no risks of
conflicts between application schema's as a result of for example usage of
public synonyms or  user definitions.

Our idea is to set up a consolidated database environment consisting of a
minimum number of instances running  two oracle versions. When an
application schema meets our requirements it can  be added to this
enviroment. If it doesn't meet our  requirements it will end up in a
dedicated instances and in some cases even on a dedicated UNIX server. The
costs for database management in the consolidated environment will be the
lowest.
This idea can only work when their is a management commitment on all
levels, Could that be the reason why this didn't work in your situation?

In order to create a stable consolidated database environment we need
tools voor monitoring en managing resource usage.

Jaco














                                                                           
                                                                           
                                                                           
 (Embedded image moved to                NL Telephone: +31 (0) 10 224 2045 
 file: pic05705.gif)                             E-mail: J.Polet@xxxxxxxxx 
 Jaco Polet                                                                
 Corporate ICT/BS DBA                                                      
                                                                           





 

                      DENNIS WILLIAMS

                      <DWILLIAMS@LIFETOU         To:
"'oracle-l@xxxxxxxxxxxxx'" <oracle-l@xxxxxxxxxxxxx>

                      CH.COM>                    cc:

                      Sent by:                   Subject: RE: looking for
tool to help consolidate Oracle schemas within Or acle         
                      oracle-l-bounce@fr         instances and Oracle
instances on AIX servers                                           
                      eelists.org

 

 

                      20-04-2004 15:58

                      Please respond to

                      oracle-l

 

 




Jaco
   What are the benefits you hope to achieve by consolidating schemas
within
an instance? I can see several potential problems, especially if these are
vendor-supported applications. It may be difficult to upgrade to new Oracle
versions because different vendors will provide support for a new Oracle
version at different times. Another issue is that each schema may support a
different group of users, and one group of users may be eager to move to a
new Oracle version while another group of users doesn't see this as a
priority. After years of trying to consolidate schemas as much as possible,
I've tended to go the opposite direction in recent years.

Dennis Williams
DBA
Lifetouch, Inc.
dwilliams@xxxxxxxxxxxxx

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of J.Polet@xxxxxxxxx
Sent: Tuesday, April 20, 2004 3:21 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: looking for tool to help consolidate Oracle schemas within
Oracle instances and Oracle instances on AIX servers


Hi all,

I am currently working on a consolidation project.
Within this project we want to consolidate Oracle schemas within Oracle
8.1.7.4/ 10g instances and Oracle instances on AIX 5.2 servers.

We see 3 potential problems:
1. How do we prevent instances and schema's influencing each others
performance?
2. How do we determine which schemas can be consolidated within the same
instance from a resource usage point of view?
3. How do we determine which instances can be consolidated on the same
server from a resource usage point of view?

To address our first problem we are looking at the Oracle Resource Manager
for controlling the resource usage of schemas within the same instance and
AIX Workload Manager to control resource usage of instances on the same
server.

For our second and third problem we want to create a shortlist of 3
(combination of) tools to evaluate which should be able to:
-  Measure the usage of instance resources like buffer cache, redo/undo
blocks, open cursors etc. on a schema level.
-  Measure the available instance resources within an instance
-  Measure the usage of server resources (CPU, Memory, Disk IO, Network IO)
on a schema level and on an instance level.
-  Measure the available server resources within a server

Does anyone has an idea of which (combination of) tools I should put on
this shortlist?

Thanks... Jaco


 --------------------------------------------------------------------------

 The information contained in this communication is confidential and may be

 legally privileged. It is intended solely for the use of the individual or

 entity to whom it is addressed and others authorised to receive it. If you

 are not the intended recipient you are hereby notified that any

 disclosure, copying, distribution or taking any action in relation to the

 contents of this information is strictly prohibited and may be unlawful.

 Neither the sender nor the represented institution are liable for the

 correct and complete transmission of the contents of an e-mail, or for its

 timely receipt.

 --------------------------------------------------------------------------





----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------





-- Binary/unsupported file stripped by Ecartis --
-- Type: image/gif
-- File: pic05705.gif


----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Other related posts: