Oracle on Red Hat best practices

[McDougall, Marshall (FSH)]

>-----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