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
