From: Craig Ringer <craig@postnewspapers.com.au>
To: Jayadevan M <Jayadevan.Maymala@ibsplc.com>
Cc: Merlin Moncure <mmoncure@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Parameters for PostgreSQL
Date: Thu, 04 Aug 2011 11:54:48 +0800
Message-ID: <4E3A1808.3050300@postnewspapers.com.au> (raw)
In-Reply-To: <OFB5D52348.1A6D34E9-ON652578E2.00137B30-652578E2.001450FD@ibsplc.com>
References: <OF4401A47F.8A79A9ED-ON652578DF.00422697-652578DF.0042CB3B@ibsplc.com>
<4E373D76.9020800@postnewspapers.com.au>
<OFB5D52348.1A6D34E9-ON652578E2.00137B30-652578E2.001450FD@ibsplc.com>
On 04/08/11 11:42, Jayadevan M wrote:
> Hello,
>
> >The most important spec has been omitted. What's the storage subsystem?
> We have storage on SAN, RAID 5.
RAID 5? That's *really* not ideal for database workloads, either Pg or
Oracle, unless your RAID 5 storage backend has enough battery-backed
write cache to keep huge amounts of writes in RAM and reorder them
really effectively.
I hope each RAID 5 LUN is only across a few disks and is layered with
RAID 1, though. RAID 5 becomes less reliable than using a single disk
when used with too many HDDs, because the probability of a double-disk
failure becomes greater than that of a single standalone disk failing.
After being bitten by that a few times, these days I'm using RAID 6 in
most cases where RAID 10 isn't practical.
In any case, "SAN" can be anything from a Linux box running an iSCSI
target on top of a RAID 5 `md' software RAID volume on four 5400RPM
HDDs, right up to a giant hundreds-of-fast-disks monster filer full of
dedicated ASICs and great gobs of battery backed write cache DRAM. Are
you able to be any more specific about what you're dealing with?
>
> > > We are suing weblogic.
> > ^^^^^
> > Best. Typo. Ever.
> >
> > I hear most people who use it want to, you're just brave enough to
> do it :-P
> I wish I could make a few millions that way.
>
>
> Thank you for all the replies. The first step is, of course, to
> migrate the data. I am working with ora2pg for that. I assume creating
> files with 'COPY' to work as input for PostgreSQL is the right
> approach? We don't have many stored procedures or packages. So that
> part should be OK.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: craig@postnewspapers.com.au, Jayadevan.Maymala@ibsplc.com, mmoncure@gmail.com
Subject: Re: Parameters for PostgreSQL
In-Reply-To: <4E3A1808.3050300@postnewspapers.com.au>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox