RE: comments on forcedirectio
- From: "VIVEK_SHARMA" <VIVEK_SHARMA@xxxxxxxxxxx>
- To: <geraldine_2@xxxxxxxxxxx>, <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 4 May 2005 10:15:53 +0530
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@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of
geraldine_2@xxxxxxxxxxx
Sent: Monday, May 02, 2005 8:18 PM
To: oracle-l@xxxxxxxxxxxxx
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@xxxxxxxxxxxxx
> > [mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of
> > geraldine_2@xxxxxxxxxxx
> > 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@xxxxxxxxxxx (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
> --
> //www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
