Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Red Hat Linux (http://www.linux-archive.org/red-hat-linux/)
-   -   Oracle on Red Hat best practices (http://www.linux-archive.org/red-hat-linux/4797-oracle-red-hat-best-practices.html)

Chuck 11-25-2007 05:39 PM

Oracle on Red Hat best practices
 
Try this site:
http://www.puschitz.com/

I have been using his guides for years. (even as an employee at Oracle
I found myself using his guides over the wordy/lengthy oracle docs)
You also wanna become familiar with the Oracle architecture. There are
various components you want to segregate onto different physical
spindles. Oracle has what they called the OFA - optimum Flexible
Architecture. This covers what components should go where. (ie: You
don't want 2 log groups on the same filesystems, not only are you
getting redundant I/O per every transaction but you have lost the
redundancy if that filesystem fails. You also don't want to store a
table's indexes on the same filesystem as the table itself -- so place
index tablespaces on separate spindles from the corresponding data
tablespaces. There are just a few examples)

Other than that, avoid raid 5 for OLTP databases if you can, and I
personally avoid using NFS for storing datafiles, although Oracle uses
NFS for datafiles for almost 90% of their databases. (10 years ago
Oracle documentation stated don't EVER mount datafiles accross NFS but
today, after being in bed with NetApp all these years, its apparently
ok to do)

Of course all this is based on your planned workload. It is possible
to store an entire database all in one filesystem but you won't be
able to scale much, nor will you be able to recover 100% of your
transactions (100% of the time) if that filesystem fails.

Hope this helps,
CC
On Nov 8, 2007 9:45 AM, McDougall, Marshall (FSH)
<Marshall.McDougall@gov.mb.ca> 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
> --
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request@redhat.com?subjectunsubscribe
> https://www.redhat.com/mailman/listinfo/redhat-list
>

--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list

Chuck 11-25-2007 05:44 PM

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

--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list

"Geofrey Rainey" 11-25-2007 06:45 PM

Oracle on Red Hat best practices
 
Unless you are implementing Oracle with ASM, which uses raw devices.

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

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

"Herta Van den Eynde" 11-25-2007 10:27 PM

Oracle on Red Hat best practices
 
On 25/11/2007, Geofrey Rainey <Geofrey.Rainey@tvnz.co.nz> wrote:
> Unless you are implementing Oracle with ASM, which uses raw devices.
>
> -----Original Message-----
> From: redhat-list-bounces@redhat.com
> [mailto:redhat-list-bounces@redhat.com] 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@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@redhat.com
> >
> > [mailto:redhat-list-bounces@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@redhat.com
> > [mailto:redhat-list-bounces@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@redhat.com
> > >[mailto:redhat-list-bounces@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@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@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@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@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@redhat.com?subject=unsubscribe
> > https://www.redhat.com/mailman/listinfo/redhat-list
> >
>
> --
> redhat-list mailing list
> unsubscribe mailto:redhat-list-request@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.
>

The OFA architecture that Chuck mentions is valid when you still have
LUNs on separate spindles. When you're on a centrally managed SAN,
you may not have much of a say in the matter. I've seen places where
all you could do was request SAN storage of a specific size. :-( If
you have local disks that are fast enough, it may be worth
multiplexing one set of your control file and redo/archive logs to the
local disks.

As to NFS, make sure to check the supported HW configurations. It's
not 'just NFS'.
And fwiiw, I once tried setting up a test Oracle RAC 10gR2 with NFS on
SLES 10. I never got it to work. (It *was* supported, so I'm sure
someone somewhere knows how to make this work. Just don't expect it
to be easy.)

Also, remember that while you may not be able to grow filesystems as
easily as ASM volumes, you can always add more datafiles to
tablespaces, and those datafiles need not reside on the same
filesystems.

Kind regards,

Herta

--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list


All times are GMT. The time now is 01:00 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.