Oracle on Red Hat best practices

Sun Nov 25 18:44:11 UTC 2007

Avoid raw devices if at all possible. Now days with vxfs and ext3, it
is very seldom needed, and it just makes backups and recovery more of
a pain in the ass. I would also avoid ASM if possible. You will be
lucky to gain a 5% performance bump moving to raw devices. You can
typically get the same gains by adding more drive spindles and moving
stuff around. I most definitely would avoid using raw files on
anything platform outside of AIX and Solaris. Linux is just to rapidly
changing to offer the platform stability that sun/aix have. I remember
having scores of issues on Red Hat 6.2 trying to use raw devices. (of
course nothing was supported back then, including the HBA drivers, so
things are a bit more stable today, I'm sure. However, I would still
avoid raw devices -- they are the bane of any SA)

-Cuhck

On Nov 9, 2007 4:40 PM, Geofrey Rainey <Geofrey.Rainey at tvnz.co.nz> wrote:
> Oh and another thing, our database server is flat out all the time and
> it runs sweet as on an ext3
> filesystem. I don't see any benefit in using ASM (Automatic Storage
> Manager) with raw partitions as yet
> Unless your talking about RAC (Real Application Cluster) on a large and
> busy system perhaps.
>
> -----Original Message-----
> From: redhat-list-bounces at redhat.com
>
> [mailto:redhat-list-bounces at redhat.com] On Behalf Of Geofrey Rainey
> Sent: Saturday, 10 November 2007 1:36 p.m.
> To: General Red Hat Linux discussion list
> Subject: RE: Oracle on Red Hat best practices
>
> 1. As another respondant has stated, multiplexing both your redo logs
> and control files Is best practice, this creates redundancy of those two
> file types as both are critical, And of course it is best to multiplex
> to different spindles else you're not compensating for a potential loss
> of data through media failure (disk). (though I don't multiplex to
> Different spindles, I rely on a standby database, see 3)
>
> 2. You have to determine if you're going to run in archive log mode or
> not. Archive logs Are copies of the redo logs which contain all the redo
> (changes made to the database).
> If you do not archive the logs, then you cannot roll forward to a point
> in time since your Last backup, so in most cases of failure you'll be
> facing significant data loss.
>
> 3. Backups are most critical, I higly recommend RMAN. It's the best tool
> for Oracle period.
>
> 4. Use a standby database. www.standbydatabase.com. This way if you get
> a failure, you can Switch to your standby with minimal downtime.
>
> Regards,
> Geofrey Rainey.
>
> -----Original Message-----
> From: redhat-list-bounces at redhat.com
> [mailto:redhat-list-bounces at redhat.com] On Behalf Of McDougall, Marshall
> (FSH)
> Sent: Saturday, 10 November 2007 3:12 a.m.
> To: General Red Hat Linux discussion list
> Subject: RE: Oracle on Red Hat best practices
>
>
>
>
> >-----Original Message-----
> >From: redhat-list-bounces at redhat.com
> >[mailto:redhat-list-bounces at redhat.com] On Behalf Of Herta Van den
> >Eynde
> >Sent: Thursday, November 08, 2007 2:16 PM
> >To: General Red Hat Linux discussion list
> >Subject: Re: Oracle on Red Hat best practices
> >
> >On 08/11/2007, Harry Johnson <hjohnson at keeneinfo.com> wrote:
> >> I could help you if it were Informix.  I have not done it
> >with Oracle.
> >>
> >>
> >>
> >> McDougall, Marshall (FSH) wrote:
> >>
> >> >I am being tasked with building an environment to run
> >Oracle.  I have
> >> >had little Oracle experience so I went looking on the web
> >for some best
> >> >practices for file system setup.  Of course there were
> >several million
> >> >hits and with variety comes confusion.  I would appreciate
> >it if someone
> >> >with some Oracle on Linux expertise would point me in the right
> >> >direction.  I believe that the hardware is going to be HP blades
> >> >connected to an EMC/Dell SAN.  Thanks for your consideration.
> >> >
> >> >Regards, Marshall
> >> >
> >> >
> >>
> >> --
> >> Harry Johnson
> >> Keene Information System, Inc.
> >>
> >> Ph:   281-579-0048
> >> Fax: 281-579-8497
> >>
> >Main rule: put your log files on different LUNs from your data files
> >reason: if your data files get corrupted for whatever reasons, at least
>
> >you can restore them again.
> >
> >Other important rules:
> >* if this database is important for the core business of your company,
> >ask for proper training
> >* multiplex (Oracle speak for mirror) your redo logs and control files,
>
> >again using different spindles
> >* unless you can restore your data from other sources, use archive
> >logging, and again multiplex them or at least make regular backups
> >(where the amount of data your company can afford to lose determines
> >what "regular" means)
> >* make backups and *test* them
> >
> >The rest is pretty much what people feel more comfortable with.
> >Oracle itself promotes ASM (automatic storage management, a kind of raw
>
> >device), which has the advantages that you can it extend it online, and
>
> >is cluster aware.  The disadvantages are that it cannot store all the
> >database files, and that you'll need to learn new tools:
> >asmcmd and rman.  asmcmd is used to manage the ASM volumes.  I once had
>
> >to clean up orphaned files, and I cannot say that it is my favourite
> >tool.  rman is a backup utility that you *must* use to backup your
> >database when it is stored in ASM (since regular linux commands don't
> >know about ASM), and that you *may* use with regular filesystems.  Main
>
> >advantage is that it is fast to backup *and* restore.  Personally, I
> >feel uncomfortable about backuping up a database to an rman 'database',
>
> >but I haven't heard about it getting corrupted yet.  (And yes, you can
> >use rman to backup to regular external files, but that basically
> >invalidates the backup/restore speeds that I perceive as its main
> >advantage.) I'm a systems person, and I prefer to use regular
> >filesystems, because I understand them better.  If the database isn't
> >too big, I'd still prefer to use non-rman backups.
> >
> >Hope this helps some.
> >
> >Kind regards,
> >
> >Herta
> >
> >--
> >redhat-list mailing list
> >unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
> >https://www.redhat.com/mailman/listinfo/redhat-list
> >
>
> Multiplex, ASM, SAME, asmcmd, rman........these are indeed the kinds of
> speak that I will need to familiarize myself with.  Thanks for this
> synopsis.
>
> Regards, Marshall
>
> --
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list
> ==========================================================
> For more information on the Television New Zealand Group, visit us
> online at tvnz.co.nz
> ==========================================================
> CAUTION:  This e-mail and any attachment(s) contain information that is
> intended to be read only by the named recipient(s).  This information is
> not to be used or stored by any other person and/or organisation.
>
> --
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list
> ==========================================================
> For more information on the Television New Zealand Group, visit us
> online at tvnz.co.nz
> ==========================================================
> CAUTION:  This e-mail and any attachment(s) contain information that
> is intended to be read only by the named recipient(s).  This information
> is not to be used or stored by any other person and/or organisation.
>
> --
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request at redhat.com?subject=unsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list
>