Oracle on Red Hat best practices

Roderick Derks redhat at r71.nl
Sat Nov 10 02:17:28 UTC 2007


For high performance on our (new) Dell-EMC SAN we always use raid 10 on 149GB 15.000rpm disks. Advised to us by different vendors and is indeed very fast.


----- Original Message -----
From: "Geofrey Rainey" <Geofrey.Rainey at tvnz.co.nz>
To: "General Red Hat Linux discussion list" <redhat-list at redhat.com>
Sent: Saturday, November 10, 2007 1:40:08 AM (GMT+0100) Europe/Berlin
Subject: RE: Oracle on Red Hat best practices

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




More information about the redhat-list mailing list