RE: Oracle on Red Hat best practices

Unless you are implementing Oracle with ASM, which uses raw devices.

-----Original Message-----
From: redhat-list-bounces@xxxxxxxxxx
[mailto:redhat-list-bounces@xxxxxxxxxx] On Behalf Of Chuck
Sent: Monday, 26 November 2007 7:44 a.m.
To: General Red Hat Linux discussion list
Subject: Re: Oracle on Red Hat best practices

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

[mailto:redhat-list-bounces@xxxxxxxxxx] 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@xxxxxxxxxx
[mailto:redhat-list-bounces@xxxxxxxxxx] 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@xxxxxxxxxx
[mailto:redhat-list-bounces@xxxxxxxxxx] 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@xxxxxxxxxxxxx> 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@xxxxxxxxxx?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@xxxxxxxxxx?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@xxxxxxxxxx?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@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list


--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?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@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list

Relevant Pages

  • RE: Oracle on RHEL4 with ASM problem
    ... bounces@xxxxxxxxxx] On Behalf Of Tom Callahan ... Oracle on RHEL4 with ASM problem ... ASMLIB for Linux may not support System-based adding of raw devices, ... "When installed on raw devices or, as recommended by Oracle, on block ...
    (RedHat)
  • RE: Oracle on RHEL4 with ASM problem
    ... Oracle on RHEL4 with ASM problem ... "When installed on raw devices or, as recommended by Oracle, on block ... It clearly shows setting up ASM using block devices. ... I know that linux itself is 'phasing out' support for direct raw devices and using a call in the block device code instead, but that's not something I've read up on fully. ...
    (RedHat)
  • Re: Oracle on Red Hat best practices
    ... Avoid raw devices if at all possible. ... Oracle on Red Hat best practices ... Different spindles, I rely on a standby database, see 3) ... Backups are most critical, ...
    (RedHat)
  • Re: ASM Question - Best Practice
    ... I disagree with Frank. ... I haven't had any problems with ASM and I find it much more convenient then raw devices. ... My opinion is that for almost everything Oracle ... ...
    (comp.databases.oracle.server)
  • RE: Oracle on RHEL4 with ASM problem
    ... I think we'll stick with the block devices for now. ... I really need to setup ASM on a dev box and see what I can come up with. ... I realize it says you must use raw devices in the document that was ... This may require and Oracle TAR asking about ASM and Block ...
    (RedHat)