What is the value of your "filesystemio_options" parameter?
Most likely, it isn't set to SETALL. If you were trying
to have many simultaneous users, it would be a pain.
On 02/26/2004 01:37:41 PM, Jared.Still_at_radisys.com wrote:
> I've have 8i,9i and now 10g on RH 7.2 using all ext3 filesystems.
>
> This box has been in service for 2+ years. The only problems
> with ext3 have been compatibility with Veritas NetBackup.
>
> Jared
>
>
>
>
>
>
> Mladen Gogala <mgogala_at_adelphia.net>
> Sent by: oracle-l-bounce_at_freelists.org
> 02/25/2004 08:07 PM
> Please respond to oracle-l
>
>
> To: oracle-l_at_freelists.org
> cc:
> Subject: Re: Moving db to linux
>
>
> Oracle supports Ext2 and OCFS, not Ext3. Ext3 has occasional problems
> with corruption. As for OCFS, I'll give it a second look it on Saturday,
> but it didn't look like it is capable of working without cluster. I should
> be capable of linking it into my 2.4.25 kernel. As for async I/O, that is
> not
> a problem. I can always start a bunch of database writers instead of just
> one. The problem with direct I/O is that without it, Linux is going to
> put each and every block of the database in your buffer cache expanding
> it, as necessary to accommodate such big demand. As PC's with infinite RAM
> are pretty hard to find, that means that the RAM on your PC will be finite
> in quantity and that Linux kernel will start throwing out other things
> like
> samba, network daemons, cupsd, nautilus and gdm to accommodate the
> increased
> demand for networking. Then someone approaches the keyboard and presses
> enter or NE key. Linux will page nautilus, gdm, panels and related stuff
> right back in, shrinking the buffer pool. Then oracle tries to do
> transaction, Linux expands buffer pool....We've got what's known as
> "circulus viciosus" or "vicious circle". To the buyers of the IBM
> equipment from few decades ago, it is also known as "the spiral of
> death". The funny thing is that all that buffering is completely
> unnecessary because oracle does its own buffering in SGA, so the Linux
> buffering is redundant and inefficient. It does improve BCHR, though,
> which is of paramount importance, as is well known on this group.
> The only way to avoid costly, and unnecessary double buffering is to make
> Linux read and write database files bypassing the buffer cache. That is
> the very definition of direct I/O. Now, we're back to square 2.
>
>
> On 02/25/2004 10:22:09 PM, zhu chao wrote:
> > Isn't ext3 good enough? It provide JFS recovery performance and AIO/DIO
> on
> > redhat linux.(On redhat 3, aio seems still have problems, but seems
> mature
> > on 2.1)
> >
> > Oracle metalink only support ext3/ocfs etc. Seems no jfs support.
> >
> > Regards
> > Zhu Chao.
> >
> > ----- Original Message -----
> > From: "Mladen Gogala" <mladen_at_wangtrading.com>
> > To: <oracle-l_at_freelists.org>
> > Sent: Thursday, February 26, 2004 3:12 AM
> > Subject: Re: Moving db to linux
> >
> >
> > > It should already be in the distribution. Type "rpm -qa|grep jfsutils"
> and
> > > you should get an answer like this:
> > > Yogi> rpm -qa|grep jfs
> > > jfsutils-1.0.17-6
> > > Yogi>
> > >
> > > JFS is a standard part of the kernel. The "utils" package contains all
> > > you need for for checking it, making it and alike. Here is contents of
> the
> > > standard distribution on RH-9:
> > >
> > > Yogi> rpm -ql jfsutils-1.0.17-6
> > > /sbin/defragfs
> > > /sbin/extendfs
> > > /sbin/fsck.jfs
> > > /sbin/logdump
> > > /sbin/logredo
> > > /sbin/mkfs.jfs
> > > /sbin/xchkdmp
> > > /sbin/xchklog
> > > /sbin/xpeek
> > > /usr/share/doc/jfsutils-1.0.17
> > > /usr/share/doc/jfsutils-1.0.17/AUTHORS
> > > /usr/share/doc/jfsutils-1.0.17/COPYING
> > > /usr/share/doc/jfsutils-1.0.17/ChangeLog
> > > /usr/share/doc/jfsutils-1.0.17/INSTALL
> > > /usr/share/doc/jfsutils-1.0.17/NEWS
> > > /usr/share/doc/jfsutils-1.0.17/README
> > > /usr/share/man/man8/fsck.jfs.8.gz
> > > /usr/share/man/man8/logdump.8.gz
> > > /usr/share/man/man8/logredo.8.gz
> > > /usr/share/man/man8/mkfs.jfs.8.gz
> > > /usr/share/man/man8/xchkdmp.8.gz
> > > /usr/share/man/man8/xchklog.8.gz
> > > /usr/share/man/man8/xpeek.8.gz
> > > Yogi>
> > >
> > > Can you please check that you have it? I'm very eager to learn,
> because
> > that's
> > > precisely the problem I reported to oracle with 10g. The result is
> bug#
> > 3446411
> > > (public) and I'm in the process of disembowelling my existing RH-9 box
> and
> > > turning it into ES 3.0, because oracle told me that the ES 3.0 kernel
> may
> > contain
> > > the necessary ingredients to make it work.
> > >
> > >
> > > On 02/25/2004 01:54:50 PM, "Nelson, Allan" wrote:
> > > > Really, do you know where I can get JFS for RH AS 3.0? I can work
> from
> > > > tarballs as well.
> > > >
> > > > Thanks
> > > >
> > > > -----Original Message-----
> > > > From: oracle-l-bounce_at_freelists.org
> > > > [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Mladen Gogala
> > > > Sent: Wednesday, February 25, 2004 12:05 PM
> > > > To: oracle-l_at_freelists.org
> > > > Subject: Re: Moving db to linux
> > > >
> > > >
> > > > My advice is to use JFS for database files because on 9.2.0.4, you
> can
> > > > use direct I/O, which is supported by JFS. As far as the big files
> are
> > > > concerned, JFS supports them without any problem.
> > > >
> > > > On 02/25/2004 12:22:58 PM, "Nelson, Allan" wrote:
> > > > > Im, going to be moving a 220 GB 8.1.7.4 database from HP-UX to Red
> Hat
> > > > > AS 3.0 running 9.2.0.4.0. I'm told that we have to use
> export/import
> > > > to
> > > > > get that job done. I plan to work through pipes and use split to
> keep
> > > > > the file sizes to 2 GB or less to aviod large file issues between
> the
> > > > > platforms. Does anyone know of other issues that may trip me up?
> > > > >
> > > > > Thanks In Advance
> > > > >
> > > > > > Allan L. Nelson
> > > > > > Oracle DBA
> > > > > > M-I L.L.C.
> > > > > > (832) 295-2238 office
> > > > > > (832) 351-4180 fax
> > > > > > anelson_at_midf.com <mailto:anelson_at_midf.com>
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> ________________________________________________________________________
> > > > ______
> > > > > This email is intended solely for the person or entity to which it
> is
> > > > addressed and may contain confidential and/or privileged
> information.
> > > > Copying, forwarding or distributing this message by persons or
> entities
> > > > other than the addressee is prohibited. If
> > > > >
> > > > >
> > > > ----------------------------------------------------------------
> > > > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > > > ----------------------------------------------------------------
> > > > To unsubscribe send email to: oracle-l-request_at_freelists.org
> > > > 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
> > > > -----------------------------------------------------------------
> > > >
> > > >
> > > >
> >
> ____________________________________________________________________________
> > __
> > > > This email is intended solely for the person or entity to which it
> is
> > addressed and may contain confidential and/or privileged information.
> > Copying, forwarding or distributing this message by persons or entities
> > other than the addressee is prohibited. If you have received this email
> in
> > error, please contact the sender immediately and delete the material
> from
> > any computer. This email may have been monitored for policy compliance.
> > [021216]
> > > >
> > > > ----------------------------------------------------------------
> > > > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > > > ----------------------------------------------------------------
> > > > To unsubscribe send email to: oracle-l-request_at_freelists.org
> > > > 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
> > > > -----------------------------------------------------------------
> > > >
> > > ----------------------------------------------------------------
> > > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > > ----------------------------------------------------------------
> > > To unsubscribe send email to: oracle-l-request_at_freelists.org
> > > 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
> > > -----------------------------------------------------------------
> > >
> > >
> >
> > ----------------------------------------------------------------
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > ----------------------------------------------------------------
> > To unsubscribe send email to: oracle-l-request_at_freelists.org
> > 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
> > -----------------------------------------------------------------
> >
>
> --
> Mladen Gogala
> Oracle DBA
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to: oracle-l-request_at_freelists.org
> 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
> -----------------------------------------------------------------
>
>
>
Please see the official ORACLE-L FAQ:
http://www.orafaq.com
To unsubscribe send email to: oracle-l-request_at_freelists.org
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
-----------------------------------------------------------------
Received on Thu Feb 26 2004 - 12:45:51 CST
