| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: looking for tool to help consolidate Oracle schemas within Or acle instances and Oracle instances on AIX servers
Fair enough... My benchmark tends to be "you know that request we
submitted saying we're going to need more disk/ RAM/ CPU's in 3/6/9
months? If we spend x hours consolidating/ reallocating resources, you
can push that request out 1 or 2 quarters". You'll never pull resources
out of a box, but you may be able to say that you'll be able to make due
without already-requested bits of hardware, which has some tangible
benefits. Of course, there is a certain amount of diminishing returns--
consolidating 20 instances to 10 on a server is likely to have
significant benefits, consolidating 2 instances to 1 probably won't
provide a lot of benefits.
I'll certainly agree that DBA's tend to be afflicted with "perfectionitis" and don't do a good job of presenting the business case (as opposed to the technical case) for the changes they want to make, so ensuring that the business sees the benefit of a consolidation project is important.
Justin Cave
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of DENNIS WILLIAMS
Sent: Wednesday, April 21, 2004 10:10 AM
To: 'oracle-l_at_freelists.org'
Subject: RE: looking for tool to help consolidate Oracle schemas within
Or acle instances and Oracle instances on AIX servers
Justin
My benchmark for whether consolidation saves great amounts of
hardware resources is whether you pull some memory boards out of the
server afterward. Yes, I was baiting the poster a little to drive home a
point.
When you tell management you will save hardware resources with the
consolidation, they may expect some real savings. Or they may let you by
with claims that "everything is running faster."
I made the memory savings argument for consolidating instances for
years and only got dumb looks. Then this business of databases to DBAs
started getting discussed, and I suddenly said to myself "am I stupid or
what??"
(don't answer that Mladen). I suddenly realized that my best efforts to
be frugal with resources were making me look bad, giving me a bad ratio.
What we are talking about in saving hardware resources is in my view pretty minor. Maybe slightly better utilization of existing server resources. Maybe tuning the instance a little better. But we probably aren't talking about pulling two CPUs out of a 4-CPU server. Now THAT would be some real savings!! Reducing your Oracle license savings!=20
But as I pointed out, if this project will contribute to your continued employment, I'm in favor. Too often we DBAs have pitifully poor Public Relations. But just don't believe your own PR.=20
And keep in mind that there are many factors in both directions and these factors will vary depending on precisely which applications you are considering bunking together.
Dennis Williams
DBA
Lifetouch, Inc.
dwilliams_at_lifetouch.com=20
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Justin Cave (DDBC)
Sent: Wednesday, April 21, 2004 10:40 AM
To: oracle-l_at_freelists.org
Subject: RE: looking for tool to help consolidate Oracle schemas within
Or acle instances and Oracle instances on AIX servers
Can you clarify your assumptions in the statement that "there isn't much difference in hardware requirements", particularly regarding RAM? Are you assuming that the RAM allocated to the SGA's for each of the instances on a machine can be tuned such that it is roughly equivalent to the total RAM needed for a single integrated instance... That tends to be an unusual in my experience-- two instances on a machine generally require significantly more RAM than one instance would because of the redundant dictionary caches, background processes, etc. In the pathological cases (i.e. 20 instances on a single machine), that redundancy got pretty hefty... =3D20
In addition, you don't see the same degree of benefit to differently timed workloads-- one instance may do its heavy batch processing from 1-5am, where another does its processing from 4-7am. If they were integrated, the second could take advantage of the SGA that the other wasn't using from 5-7 (or 1-4). If they are separate instances, though, you need both SGA's around all the time.
Justin Cave
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of DENNIS WILLIAMS
Sent: Wednesday, April 21, 2004 8:16 AM
To: 'oracle-l_at_freelists.org'
Subject: RE: looking for tool to help consolidate Oracle schemas within
Or acle instances and Oracle instances on AIX servers
Jaco=3D20
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_at_lifetouch.com=3D20
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of J.Polet_at_Robeco.nl
Sent: Wednesday, April 21, 2004 5:52 AM
To: oracle-l_at_freelists.org
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
=3D20
=3D20
=3D20
(Embedded image moved to NL Telephone: +31 (0) 10 224 2045=3D20 file: pic05705.gif) E-mail:J.Polet_at_robeco.nl=3D20
Corporate ICT/BS DBA
=3D20
=3D20
DENNIS WILLIAMS
<DWILLIAMS_at_LIFETOU To:
"'oracle-l_at_freelists.org'" <oracle-l_at_freelists.org>
CH.COM> cc:
Sent by: Subject: RE: looking
for
tool to help consolidate Oracle schemas within Or acle =3D20
oracle-l-bounce_at_fr instances and Oracle
instances on AIX servers =3D20
eelists.org
=3D20
=3D20
20-04-2004 15:58
Please respond to
oracle-l
=3D20
=3D20
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_at_lifetouch.com
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of J.Polet_at_Robeco.nl
Sent: Tuesday, April 20, 2004 3:21 AM
To: oracle-l_at_freelists.org
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
=3D20
-- 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.Received on Wed Apr 21 2004 - 12:39:31 CDT
=3D20
------------------------------------------------------------------------ -- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://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_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://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_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://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_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://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_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://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_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://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_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------
 |
 |