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