RE: Single server vs multiple servers for multiple databases

  • From: "Goulet, Richard" <Richard.Goulet@xxxxxxxxxxx>
  • To: <veeeraman@xxxxxxxxx>, "ORACLE-L" <oracle-l@xxxxxxxxxxxxx>
  • Date: Wed, 27 Oct 2010 08:26:25 -0400

Ram,
 
    I believe your going to run into a lot of problems if you try to
split out different Peoplesoft modules into different databases.  The
reason is the core tables that PeopleSoft uses to maintain user login
data, panel versions, etc.. These tables can and will get out of sync
very easily (found that our with separate HR and business installs).
This turns an implementation into a nightmare as passwords get out of
sync, people get entered into the wrong system causing duplication of
effort, patch level differences which make upgrades a real mess, having
to install base application patches multiple times, etc.............
Recommendation is to follow Peoplesoft's instructions and put it all
into one massive db, possibly with RAC to increase cpu capacity as
needed or skip the LPAR's  all together.
 

Dick Goulet 
Senior Oracle DBA 

 

________________________________

From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Ram Raman
Sent: Tuesday, October 26, 2010 9:59 PM
To: ORACLE-L
Subject: Single server vs multiple servers for multiple databases


 
We are purchasing two physical boxes; we will be carving out several
LPARs out of those two boxes for some applications like Financials, HR,
etc. Downtime for these applications will not be liked. We plan to
cluster the LPARs. All the applications are Peoplesoft applications. The
database LPARs are to be licensed in bulk as far as Oracle goes; that
includes all the production and dev servers. This is so that CPU cycles
can be 'borrowed' if needed. So CPU is not an issue here. 
One of my colleagues suggests that we create one LPAR for all production
databases for all the applications and use different Oracle homes for
various databases. I see few shortcomings with this idea:
   
- Even though the applications may all start out same currently, in
future the applications may have to be patched differently which might
require different patching on the Operating system.
   
- If we have to do maintenance, including rebooting the server, that
will affect the availability of other databases too. 
   
- If there is a runaway process with one application, this will affect
other applications as well. Also monitoring and isolating problems might
be bit easier with separate servers. 
   
The pluses:
   
- Easier maintenance because of one server. 
   
- anything else?
   
Can the listers share their thoughts on this.
   
Thanks.

Other related posts: