| Seeking recommendations on server/Oracle setup [message #456797] |
Wed, 19 May 2010 09:06  |
dignarn
Messages: 1
Registered: April 2008
|
Junior Member |
|
|
I am seeking recommendations on server/Oracle setup for our environment.
We currently are running 4 seperate servers for Oracle and are looking to streamline our setup to reduce overhead as well as furture growth.
Our current setup consists of Oracle 10gR2 Standard Edition running on the following platforms as the backend db for 3rd party apps. OEM is also colocated with the db.
RP5470, HPUX 11i (64bit OS and Oracle) - servers IBM Clearquest user dbs, @ 120 users
DL580 - Win 2003R2 (64bit OS and Oracle) - production db for BMC Remedy. @ 500 users
DL320 - Win 2003R2 (64bit OS and 32bit Oracle) - dev db for BMC Remedy. @ 5 users
DL320 - Win 2003 (32bit OS and Oracle) - test db for BMC Remedy. @ 3 users
We are also planning to support additonal dbs for applications such as IBM DOORS in the near future.
Any and all feedback welcome.
|
|
|
|
| Re: Seeking recommendations on server/Oracle setup [message #456805 is a reply to message #456797] |
Wed, 19 May 2010 09:37  |
 |
Mahesh Rajendran
Messages: 10708
Registered: March 2002
Location: oracleDocoVille
|
Senior Member
Account Moderator |
|
|
Not sure in which specific context you are looking into and not sure how you define "overhead".
If you want to put all databases in one server, I just do not prefer to put Production and Dev/Test databases together.
Ideally, you want Production and Test servers to be exactly same.
Are you also concerned about costing? Talk to your local Oracle Rep and
see if CPU or Named users will work for you.
[Updated on: Wed, 19 May 2010 09:42] Report message to a moderator |
|
|
|
| Re: Seeking recommendations on server/Oracle setup [message #456981 is a reply to message #456805] |
Thu, 20 May 2010 10:10 |
 |
Kevin Meade
Messages: 2103
Registered: December 1999
Location: Connecticut USA
|
Senior Member |
|
|
Server and Instance consolidation is a hot topic these days. Seems many companies want to save money by reducing both.
The answer to me is you should have a plan and then work to the plan. The plan should focus around what your needs are from a solution delivery perspective.
What process do you use to develope and deliver software? You need environments to support that process.
This is not a simple question because many competing issues surface. For example, how do you want to handle third party software? How many environments do you take software you develope through (most people have at least four DEV/TI/QA/ROD)? How willing are you to take risk to reduce your hardware and software installs? How will you handle upgrade issues when your Oracle DBMS must be upgraded? How willing are you to put different applications onto the same server and oracle instance?
AS you can see, the more you consider the harder it gets.
Personally I am in favor of more aggressive reductions which include the following:
1) using one server DEV/TI/QA environments with three seperate instances
2) putting multiple apps into the same oracle instances under different schemas
But many object. It all comes down to how badly you want to reduce. You will be required to harden your processes for database development to be successful in combining systems. For examples, you will need to tune every application before it joins a "CONSOLIDATED ENVIRONMENT". You want to make sure the sql workload is behaved and that the application's database observes various rules. This may require application changes. You see how it snowballs. There may even be cases where you find out some specific application is actually written so badly that it will be too expensive to move to a consoidated environment. As as aside, if you have an application that is so bad that you are not willing to spend the money to get it into shape so that is can join a consolidated environment, then it seems to me this application is a high risk system and should be targeted for sunsetting and replacement.
Consider this example: You are a new company startup and you are going to build two (2) fabulous new applications so what do you buy for new hardware and software. Well.. we need four (4)environments DEV/TI/QA/PROD for two (2) apps so we buy eight ( 8 ) server machines and do an oracle install on each and create a database on each.
eight pieces of hardware
eight oracle installs
eight oracle instances
eight application schemas
It works, but you have to ask could we have done better. I think so, yet this solution of one machine/one install/one instance/one schema -- per application is where most IT shops end up for one reason of another. Now consider a more aggressive less costly approach. We want some kind of seperation of systems and data but we are willing to assume some amout of risk too, so we buy/create
1) 1 machine w/oracle and three database instances each with two core application schemas (our DEV/TI/QA environments)
2) 1 machine w/oracle and one database instance with two core schemas (for production)
Now we have:
two pieces of hardware
two oracle installs
four database instances
eight application schemas
So lets us ask a few questions:
What happens when we need to upgrade oracle from 10gR2 to 11gR2?
What happens when one application has a runaway query?
What happens when our concurrent connections doubles for each app?
What happens when you have app#3 you want to build?
As you can see there are benefits and risks. It is all about tradeoffs and trying to be better without being stupid. Consider question #4 (we want to build app#3), what happens in scenario#1? We have to buy a new machine, install oracle again (of course we will install the latest version so it is likely our oracle databases install are now different versions), we create four new oracle instances and an application schema in each.
But what happens in scenario#2. We create four new application schemas in existing database instances and move on. We avoid the six month hardware acquisition and system setup that we need for procurment... nice. As long as we are comfortable that the machines can handle the expected workload we avoid spending money on more hardware. We also reduce the work of our support staff. Indeed, there my be no involvement if we let our application area manage its own oracle schemas. Of course someone can make arguments the other way too, but you get the idea.
As one who has lived on both sides of the fence I am definitely in favor of hardware/software reduction efforts. But you must have goals: know how much risk you will assume, understand how your internal process of software delivery works, and be willing to spend some money to protect your CONSOLIDATED ENVIRONMENTS every time you consolidate.
Consider that every company that uses Oracle has many oracle instances. Indeed Oracle instances in the thousands is common for medium and large companies. These companies are spending hundreds of millions of dollars for their IT each year. A company with 3000+ oracle installs has much to gain with a good reduction plan. Here is a case where the Bean Counters can be you friends. Let them show the possible savings. Then you step in and put realistic limits and expectations on it. You can save your company lots of money, and create a better IT environment in the process. That means better software you create in the end.
Ah well... Good luck. Kevin
[Updated on: Thu, 20 May 2010 11:40] Report message to a moderator |
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
