Oracle on Red Hat best practices

[Herta Van den Eynde]

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