Re: Moving db to linux
- From: Mladen Gogala <mgogala@xxxxxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Sat, 28 Feb 2004 09:07:56 -0500
Journalling for files is a concept similar to redo in the world
of oracle. With JFS, you get the process called jfsCommit running,
which "commits" buffer operations. Each filehandle operation like
"flush" or "close" is a "commit". Basically, journalled FS guarantees
that the data written down synchronously will really written down
to the disk device(s). If you can do DIO, your data is a little bit
safer. What a journalling FS protects you against is a huge data loss
of blocks that were in the buffer cache.
On 02/28/2004 07:27:38 AM, Nuno Souto wrote:
> ----- 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
Alter database datafile '/dir/myfile.dbf' autoextend on next 16384M maxsize
unlimited;
> 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 //www.freelists.org/archives/oracle-l/
> FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
>
--
Mladen Gogala
Oracle DBA
----------------------------------------------------------------
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:
