Re: Multiple databases - best performance scenario

From: hpuxrac <>
Date: Fri, 11 Apr 2008 08:51:55 -0700 (PDT)
Message-ID: <>

On Apr 11, 11:28 am, Paul <> wrote:
> Hi
> My company has the need to manage data for multiple customers. High
> volume concurrent read and write access will be required to these
> databases, so I'm trying to determine what hardware scenario is best
> to support this requirement. Each database will be approx 0.5Tb in
> size, and there are around 10 customers, meaning an overall size of
> approx 5Tb.
> The scenarios I'm considering are:
> 1) One large physical server with local RAID storage, or poss external
> 2) Multiple small physical servers (prob blades) connected to SAN
> 3) Multiple small virtual servers connected to SAN
> The OS will be Linux (prob RHEL). When I'm using the word database
> above I'm meaning a set of data tables for a particular customer - I
> understand that this may have a different technical interpretation for
> Oracle.
> Any suggestions or pointers to further information would be
> appreciated. Please post further questions if I've missed important
> information.
> Many thanks
> Paul

I guess one thing to start with is that "high volume concurrent read and write" access is rather vague. What some shops think of as high volume is going to be ridiculously small to others.

Are these OLTP or Data Warehouse apps? What applications are going to access the database and what tools/technologies are used?

One oracle database can support multiple schemas ( each of which can hold a set of data tables ) so one possible scenarios would be one oracle database with 10 sets of tables in different schemas. What kind of recovery scenarios and responsibilities exist in the business requirements and do those conflict with possibly using just 1 database?

It is also possible to run multiple database instances on 1 server. Many people don't like this but it is very common. Machines like a sun T2000 have 8 cores and 32 processing threads although these can be sluggish for single threaded ( batch intensive ) apps they scale out pretty well and some people put a bunch of instances on systems like these.

Until you can drill down somemore to specific business requirements ( including capacity, security, availability, recoverability, auditability etc ) and how those types of requirements might impact the high level choices you originally noted you have a pretty wide variety of possible solutions. Is your company going to host the servers or are you going to contract out?

Don't start heading down any specific paths until you firm up specifications. Hardware vendors will want to know things like transactions per minute, IOPS, data transfer rates necessary, etc. Received on Fri Apr 11 2008 - 10:51:55 CDT

Original text of this message