Message-ID: <4E3A1808.3050300@postnewspapers.com.au>
Date: Thu, 04 Aug 2011 11:54:48 +0800
From: Craig Ringer <craig@postnewspapers.com.au>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.15) Gecko/20110307 Thunderbird/3.1.9
MIME-Version: 1.0
To: Jayadevan M <Jayadevan.Maymala@ibsplc.com>
CC: Merlin Moncure <mmoncure@gmail.com>,
 pgsql-performance@postgresql.org
Subject: Re: Parameters for PostgreSQL
References: 
 <OF4401A47F.8A79A9ED-ON652578DF.00422697-652578DF.0042CB3B@ibsplc.com>
	<4E373D76.9020800@postnewspapers.com.au>
	<OFB5D52348.1A6D34E9-ON652578E2.00137B30-652578E2.001450FD@ibsplc.com>
In-Reply-To: 
 <OFB5D52348.1A6D34E9-ON652578E2.00137B30-652578E2.001450FD@ibsplc.com>
Content-Type: multipart/alternative;
	boundary="------------080604080702050403070000"

This is a multi-part message in MIME format.
--------------080604080702050403070000
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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.


--------------080604080702050403070000
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    On 04/08/11 11:42, Jayadevan M wrote:
    <blockquote
cite="mid:OFB5D52348.1A6D34E9-ON652578E2.00137B30-652578E2.001450FD@ibsplc.com"
      type="cite">
      <meta http-equiv="Context-Type" content="text/html;
        charset=US-ASCII">
      <tt> Hello, </tt>
      <br>
      <tt> <br>
        &gt;The most important spec has been omitted. What's the storage
        subsystem? </tt>
      <br>
      <tt> We have storage on SAN, RAID 5.</tt><br>
    </blockquote>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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?<br>
    <br>
    <blockquote
cite="mid:OFB5D52348.1A6D34E9-ON652578E2.00137B30-652578E2.001450FD@ibsplc.com"
      type="cite"><tt> &nbsp;<br>
        &gt; &gt; We are suing weblogic.<br>
        &gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ^^^^^<br>
        &gt; Best. Typo. Ever.<br>
        &gt; <br>
        &gt; I hear most people who use it want to, you're just brave
        enough to
        do it :-P<br>
        I wish I could make a few millions that way. </tt>
      <br>
      <br>
      <br>
      <tt> 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. </tt> <br>
    </blockquote>
    <br>
  </body>
</html>

--------------080604080702050403070000--