RE: Moving db to linux
- From: "Jesse, Rich" <Rich.Jesse@xxxxxxxxxxxxxxxxx>
- To: "'oracle-l@xxxxxxxxxxxxx'" <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 27 Feb 2004 10:21:43 -0600
I have to question using a non-journaled FS like ext2 on a production box,
unless downtime and loss of data is not a factor. The time to fsck several
GB after a crash (or even after a simple reboot, depending on FS settings)
can take hours. And that's provided there isn't a problem with the FS. If
there is, the most likely avenue of recovery is to go back to tape and roll
forward. And if you're archived logs were ext2 as well, you may be staring
at yourself in the mirror to see your boss' boot print on your backside.
What FS benchmark site? Why is it flawed? Is there a "good" benchmark
site?
Rich
Rich Jesse System/Database Administrator
rich.jesse@xxxxxxxxxxxxxxxxx QuadTech, Sussex, WI USA
> -----Original Message-----
> From: Nuno Souto [mailto:dbvision@xxxxxxxxxxxxxxx]
> Sent: Friday, February 27, 2004 7:21 AM
> To: oracle-l@xxxxxxxxxxxxx
> Subject: Re: Moving db to linux
>
>
> ----- Original Message -----
> From: "Jesse, Rich" <Rich.Jesse@xxxxxxxxxxxxxxxxx>
>
> > I haven't yet, but I'm getting the feeling that ext3 is not
> preferred. If
> > not, then what? I've already had ext2 trash my entire "/",
> even though I
> > was doing a mke2fs on a separate RAID MP, so that's not an option.
> >
> > JFS? XFS? FAT? WHY one over the other?
> >
>
> This is one of those situations I feel you should consider the "need"
> versus the "standard". There is no point whatsoever with Linux in
> "standardising" on a file system. It is counter to the
> ENTIRE philosophy
> of Unix and Linux.
>
> First of all, consider the requirements.
>
> Condition:
> "/" (and other "system" file systems) are where you load the
> system software
> and where you'll store mostly many short files of either text
> or binary
> (compiled code) data. It needs to cope well with volatility as the OS
> dynamically allocates and drops files and new space to existing files.
> Ie, the file system internal structures CHANGE, so you need
> journaling to
> avoid errors on sudden system stoppage.
>
> Solution:
> Therefore, you need to protect yourself using at the very least a
> journalised
> file system. ext3, JFS, Reiser (and PLEASE nobody mention
> the f/s benchmark
> site,I am FULLY aware how wrong it is!). Chose one geared
> for fast delivery
> on
> small to medium sized files. reiserfs is a good choice, so is JFS.
>
> Condition:
> With the Oracle data and assuming you want to use file
> systems to store
> the datafiles, what you have is VERY LARGE files that are not
> often created,
> dropped or added to IN SIZE. Which means the file system structures
> themselves do NOT need to be journalised, they hardly ever change.
> Note: I said the file system internal structures, NOT your data.
> Yes, there is a HUGE difference!
>
> Solution:
> So, for your data either use raw or a simple, no frills file system
> with sufficient features to give you performance: noatime, asynch I/O
> if you can find it, otherwise at the very least direct I/O. ext2
> will do the job, so will ext3 with journal turned off, etcetc. Do NOT
> use a file system geared for small file server, like
> reiserfs, FAT, etcetc.
>
> And that's it in a nutshell. Do NOT look for a one-size-fits-all
> file system: there is NO such animal.
>
> Cheers
> Nuno Souto
>
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
