| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Moving db to linux
> 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_at_optusnet.com.au
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Sat Feb 28 2004 - 06:30:39 CST
 |
 |