RE: comments on forcedirectio

From: VIVEK_SHARMA <VIVEK_SHARMA_at_infosys.com>
Date: Wed, 4 May 2005 10:15:53 +0530
Message-ID: <B5587533FCBD4344ADB8290B3EDDA1220494EAC6@kecmsg14.ad.infosys.com>

We experienced significant database wide slowdown for a High Transaction volume Hybrid(OLTP+Batch) type database on setting forcedirectio(Solaris OS) on datafile's partitions with Oracle 8i. Performance returned to normal on removal of the same.

HTH -----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of geraldine_2_at_comcast.net
Sent: Monday, May 02, 2005 8:18 PM
To: oracle-l_at_freelists.org
Subject: RE: comments on forcedirectio

Steve,
Thanks for your response.=20

This is the article I'm referring to -
http://www.netapp.com/tech_library/ftp/3322.pdf

In section 5.2.1 NFS Mount Options on page 20: "In general, DirectIO should always be enabled for Oracle Redo Logs. The Oracle=20
Log Writer process issues I/Os larger than the system page size, so enabling=20
DirectIO allows the Log Writer to efficiently transmit the data to storage=20
without the latency associated with splitting I/O into page size transfers. Most=20
database deployments separate the Redo Logfiles onto different file systems from=20
the datafiles. This makes enabling forcedirectio on Redo Logs simple. Even if=20
the Redo Logs are on the same file system as the data files, multiple mount=20
points can be used to access the same file system, one without the DirectIO=20
option (for datafiles) and one with DirectIO (for the logs)."

It appears that the authors implied the use of forcedirectio only on redo logs.=20
It was not clear to me why. So far the responses I've got from this list are=20
database files are written asynchronously so it does not matter if the directio=20
option is used and using forcedirectio option on netapps might cause corruption. =20

I can't remember if the other article I read is also on NetApp. =20

Thanks everyone for your responses.

Geraldine

>=20
> I can't comment on forcedirectio sideeffects on NetApp but I don't
think
> I've ever seen any recommendation to avoid fdio on datafiles. While
> looking for this paper (www.sun.com/blueprints/0101/SunOracle.pdf)
which
> I'm sure commented on forcedirectio I found this one, "Understanding
the
> Benefits of Implementing Oracle RAC on Sun"
> (www.sun.com/blueprints/0105/819-1466.pdf). Don't let the RAC label
scare
> you off, there's a couple of interesting tidbits I didn't know.
>=20
> "By default, Solaris file systems break synchronous writes into
8-kilobyte
> units, so a single 64-kilobyte write will be performed as eight
8-kilobyte
> synchronous writes. Therefore, regardless of the size of the Oracle
I/O,
> logs are written to as individual 8-kilobyte transactions, indirectly
> limiting the log throughput to the number of synchronous I/Os the
> underlying device can perform.

>=20

> The direct I/O feature eliminates this
> behavior, allowing large writes to complete as a single I/O. Enabling
> direct I/O for the transaction log allows the Oracle log writer to
> efficiently batch log file writes, eliminating the log file as a
> bottleneck and allowing scalable throughput. As of the release of the
> Solaris 8 1/01 OS, direct I/O eliminates single writer locks on entire
> files, referred to as concurrent direct I/O."
>=20
> Beyond the redo log, it looks like this has benefits for the db writer
if
> you're using > 8k block sizes.

>=20

> Later the same paper addresses single writer locks on "cooked" file
> systems:

>=20
> "Direct I/O that eliminates the single writer lock (known as
concurrent
> direct I/O) was available in the Solaris 8 1/01 OS. This allows the
UFS to
> perform nearly as well as raw disks when used with the Oracle
database."

>=20

> It looks to me like by not using forcedirectio on datafiles and redo,
> you're missing out on a lot. Maybe the author of the article didn't
have
> a big enough buffer cache and saw a big performance hit when the
double
> buffering was removed?

>=20

> S-

>=20
>=20
>=20

> On Fri, 29 Apr 2005, Reidy, Ron wrote:
>=20
> > Not sure on this one, but I think using this on NetApp will corrupt
your =3D
> > datafiles (worst case) or just cause your instance to crash at
random =3D
> > times (best case).
> >
> > -----Original Message-----
> > From: oracle-l-bounce_at_freelists.org
> > [mailto:oracle-l-bounce_at_freelists.org]On Behalf Of
> > geraldine_2_at_comcast.net
> > Sent: Friday, April 29, 2005 4:48 PM
> >
> > I've read articles that encourages the use of forcedirectio on redo
logs =3D
> > but discourages on oracle datafiles. With my limited understanding
on =3D
> > the forcedirectio option, I believe it should be used on Oracle =3D
> > datafiles to eliminate double buffering. The use of forcedirectio
should =3D
> > improve database performance.=3D20
> > Are there any reasons why the option should not be used on Oracle =
=3D
> > datafiles? Does the use of the option depends on the type of storage
=3D
> > array? We have 9.2.0.4 databases on SUN StorEdge T4 and NetApp.

>=20


> --=20

> Stephen Rospo        Principal Software Architect

> Vallent Corporation (formerly Watchmark-Comnitel)

> Stephen.Rospo_at_vallent.com           (425)564-8145

>=20

> This email may contain confidential information. If you received this
in
> error, please notify the sender immediately by return email and delete
this
> message and any attachments. Thank you.

>=20

> --
> http://www.freelists.org/webpage/oracle-l

--
http://www.freelists.org/webpage/oracle-l
--
http://www.freelists.org/webpage/oracle-l

Received on Wed May 04 2005 - 00:50:54 CDT