RE: Raw Vs. File systems, your opinion?

I whole heartily agree..

I do want to clarify though that backup being more difficult is a little misleading. The Oracle backup methodology is the same. Hot's are still backed up the same, as is cold, as is export.. It's the tool that needs to possibly be changed. (Usually 'dd' instead of 'cp' or whatever the 3rd party tool uses.) IE: Put tablespace into backup, "copy" or "dd" the file(s), end backup. Etc.

I use 'dd' for both cooked and raw datafiles. It will back up both types of files. It's the same code for both so you don't have to keep track.

You need to plan. That is the most difficult part. And you need to strictly adhere to that plan once you've implemented it. However, if you mess it up, you can redesign it. dd the contents out to a cooked file. Rename them in the database. Re-structure the raw. dd the contents back. You can switch to and from raw<->cooked without rebuilding the database. So you can stagger parts if needed. I have done this many times w/o any problems. In fact it's documented. (at least for solaris, I think sequent too) This just requires twice as much disk. Not something you want to take lightly.

Shawn M Ferris
Oracle DBA - Time Warner Telecom

> -----Original Message-----
> From: Mark Teehan [mailto:mteehan_at_erggroup.com]
> Sent: Tuesday, December 05, 2000 5:25 PM
> To: Multiple recipients of list ORACLE-L
> Subject: Re: Raw Vs. File systems, your opinion?
>
>
> Hmmm dont you love a good religious war every now and again.
> Having administered about six oracle parallel server clusters
> for over a
> year now, Ive changed my opinion completely on raw devices -
> now I prefer
> them.
> It is easier to see file and volume layouts for databases with complex
> layouts using Veritas Volume manager's (very nifty) gui. I also get
> considerable peace of mind knowing that there are no database
> files that
> can be deleted at the filesystem level : in the past I've had
> several unix
> administrators screwing up my databases by overmounting a
> filesystem, or
> something similar.
> No such problems with raw partitions : you are less likely to get
> accidental or malicious damage to a critical database if it
> is raw, imho.
> Backups are more complex, but generally only larger sites consider raw
> partitions, and subsequently have purchased an enterprise
> level backup tool
> that handles raw partitions as easily as files.
>
> An aside : for sites that use dedicated redo disks, and put
> two or three
> redo log files on each dedicated disk pair : is there any
> reason not to
> create more redo groups (say 10) on the same two disk pairs,
> so that online
> recovery, if it is required, is less likely to need archive logs to be
> pulled from tape? It is a better use of the redo pairs than having an
> online archive log bucket filesystem. Since redo log files are not
> hot-backedup their total size doesnt matter. Comments?
>
> Regards
> Mark
> Perth, Australia
>
> ---------------------------- ERG Group --------------------------
> The contents of this email and any attachments are confidential
> and may only be read by the intended recipient.
> -----------------------------------------------------------------
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Mark Teehan
> INET: mteehan_at_erggroup.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
Received on Wed Dec 06 2000 - 17:32:59 CST