Re: Moving db to linux

----- Original Message ----- 
From: "Jesse, Rich" <Rich.Jesse@xxxxxxxxxxxxxxxxx>

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

A journaled file system (JFS) does NOT protect you from loss of data.
Common misconception. The function of journaling in a file system
is to recover file system internal STRUCTURES (used to be called i-nodes
in the Unix days) if they hadn't been flushed to disk on a crash.
It does NOT recover its data.  It won't protect you from an incomplete
chained write on pre-allocated blocks, for example.  For that, you need
the normal after image recovery of databases.

A JFS basically stops you from having to wait for hours while the OS
starts a full "fsck": it's not needed (in theory) in a journaled file
system.

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

If you are running a non-journaled f/s on the Oracle datafiles and ONLY
on the Oracle datafiles and you do NOT have other files in that file system,
unless you have a very strange database I can guarantee you will NEVER lose
data on a fsck.  It's impossible.  A fsck ONLY recovers the "i-nodes".
These do NOT change for a normal Oracle datafile.  So, they can't need
recovery or be lost.

Oracle datafiles are pre-allocated and of a final size already.  They do not
shrink or expand or get deleted or re-created with anywhere near the
frequency
needed to cause harm to "i-nodes" in a crash.

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

I'd need to see proof of that. Like I said: it's all to do with the
type of usage.  If you mix Oracle datafiles with other volatile OS files
in your f/s, then you MUST ensure against f/s loss using a JFS.
If you don't, there is nothing in Oracle's normal use of files in a f/s
that will cause a fsck to fail.  Nothing.  A fsck "patches" stuffed up
allocations of blocks.  Oracle uses pre-allocated blocks.
Take away the root of the problem, you got no problem.

> What FS benchmark site?  Why is it flawed?  Is there a "good" benchmark
> site?

The Quest site with the Linux file system benchmarks.  All done without a
single description of what block size was used for the f/s, which one
for the database, which parameters were used for the f/s configs,
no testing of the impact of different write sizes (redo logs versus
datafiles),
etcetc.  Too many things wide open to be a reliable source for any
decisions.

Cheers
Nuno Souto
in sunny Sydney, Australia
dbvision@xxxxxxxxxxxxxxx

----------------------------------------------------------------
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 http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Other related posts: