General
cancel
Showing results for 
Search instead for 
Did you mean: 

Several Large DBs (26GB+ SGAs) on one OS FootPrint - DB Farming

SOLVED
Go to solution
Alzhy
Honored Contributor

Several Large DBs (26GB+ SGAs) on one OS FootPrint - DB Farming

Thoughts, ideas, gotchas needed.

I am toying with the idea of proposing an architecture in which 6 large DBs (~5TB per) -- 4 of whom would have SGAs of ~ 26GB) and 2 smaller but hyperactive DBs will be hosted on one OS FootPrint (HP-UX Of Course).

To ensure performance and separation of I/O Paths - I am planning to provision their storage on dedicated hostgroups (even dedicated SAN Arrays) and dedicated SAN (Fibre Channel) Connections.

The idea to Farm thse Databases is to reduce overhead from DBLINKS and increased performance as these Databases are inter-operative.

One pitfall of course is if this single OS FootPrint goes down -- so will all 6 Databases. But we have a proven and woring Poor Man's Clustering and so whatever downtime potential can I guess be factored in to the equation.

Crazy?

What about the separation of I/O as proposed? WIll this yield the expected defeat of I/O contentions? We're seeing the advantages and viability as we're doing exactly this on our clone-production -test environments where all these databases are housed on one mega server.

Hakuna Matata.
6 REPLIES
Steven E. Protter
Exalted Contributor
Solution

Re: Several Large DBs (26GB+ SGAs) on one OS FootPrint - DB Farming

Shalom,

Effort to keep the I/O of the two databases from interfering with each other are good.

Separate disk arrays in this matter will probably be the best way to go.

In all my investigations of slow database performance, I/O is the number one cause, followed by poor kernel tuning.

So the OS goes down the databases fail. Oh well, you picked the best OS.

You could with a cell based system go with active-passive clustering, using Serviceguard, that would defeat the problem.

Overall, I find your plan well thought out and viable.

SEP
Steven E Protter
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
Eric Antunes
Honored Contributor

Re: Several Large DBs (26GB+ SGAs) on one OS FootPrint - DB Farming

Hi,

SEP said it all about the best solution for you: a cell based system (nPars).

About dblinks, I recomend the reading of Metalink Note 780299.1 ("Create Table As Select (CTAS) / Remote Table with Lobs Can be Slow").

Best Regards,

Eric Antunes
Each and every day is a good day to learn.
Duncan Edmonstone
Honored Contributor

Re: Several Large DBs (26GB+ SGAs) on one OS FootPrint - DB Farming

You've considered IO seperation, but what about CPU/memory... have you looked at PRM?

http://h20338.www2.hp.com/hpux11i/downloads/PRM-Oracle_white_paper.pdf

Generally I use the CPU component of PRM, but let Oracle instances manage their own memory...

HTH

Duncan

HTH

Duncan
Turgay Cavdar
Honored Contributor

Re: Several Large DBs (26GB+ SGAs) on one OS FootPrint - DB Farming

You have 6 Databases and you plan to seperate all IO, so with redundant cards you need at least 6x2=12 slots for SAN connection. This means the smallest server is rx7640 for you(if you need same processing power for cluster you need 2 rx7640). As you seperate FC cards you will not get IOPS/IO througput bottlenecks on the FC card level.
I know you want to reduce overhead from DBLINKS but do you think about vpars? With this way you can better use your hardware, you may also decrease the costs and increase availability of the servers.
Wim Rombauts
Honored Contributor

Re: Several Large DBs (26GB+ SGAs) on one OS FootPrint - DB Farming

Here, we also consolidate multiple applications on 1 OS footprint, using HP-UX itself in fact as "hypervisor".

If you consolidate, you certainly need to look at high availability of the server because the impact of downtime is bigger.
You can turn to serviceguard and choose for a cold failover of the oracle databases, or you can donate your money to Oracle and by RAC licenses to have an active-active cluster, or do both as we do. (Or you can build a few scripts yourself).

I would further prefer WLM over PRM. PRM is to my opinion too limited to distirbute CPU resources over the databases. PRM only gives a priority without limiting the CPU resources a badly running database can request. So, one database can attempt to consume all CPU resources, slowing down other databases. With WLM you can effectively limit the CPU resources a database can get, or only allow it to use more CPU resources if there is sufficient free CPU time.

As for IO separation, to my opinion the storage infrastructure is of the most impact : use as many spindles as possible. I also have the impression that HP-UX (up to 11i v2 at least) has a per LUN IO queue, so split the LUN's is smaller parts, don't use one big LUN for the database. IO contention will happen on the disks itself, or on the LUN IO queue. I created volume groups with multiple LUN's, and created big LV's that were striped over the LUN's.

The IO-cards itself are less of a performance issue to my opinion. I think you can easily choose for combination IO cards (2xFC + 2xEthernet) if you have a server with limited IO expansion slots.

You have not told us how big (CPU/memory) that one server should be to handle the 6 large DB's. If you need rx7 or rx8 servers anyway, it doesn't matter, but if you are on the border between rx6 and rx7, I know the rx7 is much more expensive (price/performance) than the rx6 and you could be a lot better of with a cluster of 3 rx6600 machines than with 1 rx7... machine.
Alzhy
Honored Contributor

Re: Several Large DBs (26GB+ SGAs) on one OS FootPrint - DB Farming

Thanks for your inputs.

WLM costs money though and PRM in our experience works as designed and better than a free for all.

How big of a Box -- well possibly a last generation SuperDome PA8800 (32 cpus/64-way). Or maybe a Big Linux Iron (X86-64 64-128 way) since our recent tests show SMP (now up to 256 way) on the latest Enterprise Linux 2.6.18 kernel show remarkable stability.

Our client donates to Oracle so we're not concerned very much with CPU count. But does'nt mughty "Super-Stack" vendor Oracle "fairly" licenses CPUs anyway? Like a POWER6 would likely cost more than a DUnnighton or a PARISC-8800 or even a Nehalem?
Hakuna Matata.