RE: New Sun/Oracle Blueprint available

From: Mohan, Ross <MohanR_at_STARS-SMI.com>
Date: Thu, 25 Jan 2001 12:57:39 -0500
Message-Id: <10752.127520@fatcity.com>

This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible.

------_=_NextPart_001_01C086F8.4EC0E650
Content-Type: text/plain;

charset="iso-8859-1"

Dave,

The doc looks useful, so thanks for posting this URL. There is plenty in the document to recommend it.

But, here is this gem from the document itself:

#########################################################################

"An AIO problem has often been perceived when truss is used to observe
Oracle I/O operations. With AIO on filesystems, a kaio(2) call can be observed to routinely return ENOTSUP results, and the mistaken conclusion is drawn that AIO is 'broken'. Actually, the kaio(2) system call is not an exposed interface. That is, only the library functions aioread(3) and kin are published as supported by Sun, and kaio(2) is one of the secrets to the libaio.so implementation underlying the AIO API. In other words, this is not a bug - it's a feature!"

#########################################################################

Huh? An OS call returns an Error, but is really OK? The real AIO is a hidden
"secret" that Sun customers cannot track or read up on, so it's not a bug,
but
a "feature"?. Sequent ( now IBM ) has had Async IO since 1995, and the calls never threw exceptions when viewed with truss.

Much later, in the footnotes, the author acknowledges that "Certain Oracle 8.1 releases suppress AIO use on ordinary filesystem files ". Suppress? How? And, why? Presumably, the "certain releases" referred to are on Solaris, and
since there aren't that many "8.1" releases on Solaris, couldn't a specific version be cited? There appears to be a fair bit of work put into this document, and this kind of sentence, which has more the feeling of an unspecified assertion than a hard-won technical observation, does not do it credit.

Overall, the document has a good intention, but in my humble and hope-to-be-noninflammatory opinion, there is less meat on these bones than the author set out to provide. In particular, there is virtually no explicit evidence of the consensus approach to "Best Practices" that he wants us to redefine. Nor are there any Oracle employees cited, which -- given the supposedly extremely close
coordination between Sun and Oracle -- is a disappointment. Rather than a blueprint, the document is more like a series of cool technical tidbits, flying in close formation.

On balance, I hope the author keeps this document going, and continues to track and add the little tidbits of information and "how-to" sketches that make it a good "version 1.0" technical note.

Ross

-----Original Message-----
From: David Miller [mailto:djm_at_oregon.West.Sun.COM] Sent: Thursday, January 25, 2001 12:07 PM To: Multiple recipients of list ORACLE-L Subject: New Sun/Oracle Blueprint available

Hi Listers,

Sun has just published a new Blueprint on Sun/Oracle Best Practices. This is
a technical document and covers a lot of topics I see on this list all the time. I know that several of them have been subjects of religious wars, but thought people would be interested anyway. I hope this information is useful.

http://www.sun.com/blueprints/0101/SunOracle.html

Dave Miller
Sun Microsystems, Inc.

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: David Miller
  INET: djm_at_oregon.West.Sun.COM

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

------_=_NextPart_001_01C086F8.4EC0E650
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: New Sun/Oracle Blueprint available</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Dave, </FONT>
</P>

<P><FONT SIZE=3D2>The doc looks useful, so thanks for posting this URL. =
There is plenty in the document to recommend it. </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>But, here is this gem from the document =
itself:</FONT>
<BR><FONT =
SIZE=3D2>###############################################################=
##########</FONT>
<BR><FONT SIZE=3D2>&quot;An AIO problem has often been perceived when =
truss is used to observe Oracle I/O operations. With AIO on =
filesystems, a kaio(2) call can be observed to routinely return ENOTSUP =
results, and the mistaken conclusion is drawn that AIO is 'broken'. =
Actually, the kaio(2) system call is not an exposed interface. That is, =
only the library functions aioread(3) and kin are published as =
supported by Sun, and kaio(2) is one of the secrets to the libaio.so =
implementation underlying the AIO API. In other words, this is not a =
bug - it's a feature!&quot;</FONT></P>

<P><FONT =
SIZE=3D2>###############################################################=
##########</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Huh?&nbsp; An OS call returns an Error, but is really =
OK? The real AIO is a hidden</FONT>
<BR><FONT SIZE=3D2>&quot;secret&quot; that Sun customers cannot track =
or read up on, so it's not a bug, but </FONT>
<BR><FONT SIZE=3D2>a &quot;feature&quot;?. Sequent ( now IBM ) has had =
Async IO since 1995, and the calls never threw exceptions when viewed =
with truss. </FONT></P>

<P><FONT SIZE=3D2>Much later, in the footnotes, the author acknowledges =
that &quot;Certain Oracle 8.1 releases suppress AIO use on ordinary =
filesystem files &quot;. Suppress? How?</FONT></P>

<P><FONT SIZE=3D2>And, why?&nbsp; Presumably, the &quot;certain =
releases&quot; referred to are on Solaris, and </FONT>
<BR><FONT SIZE=3D2>since there aren't that many &quot;8.1&quot; =
releases on Solaris, couldn't a specific </FONT>
<BR><FONT SIZE=3D2>version be cited? There appears to be a fair bit of =
work put into this </FONT>
<BR><FONT SIZE=3D2>document, and this kind of sentence, which has more =
the feeling of an </FONT>
<BR><FONT SIZE=3D2>unspecified assertion than a hard-won technical =
observation, does not do it </FONT>
<BR><FONT SIZE=3D2>credit. </FONT>
</P>

<P><FONT SIZE=3D2>Overall, the document has a good intention, but in my =
humble and hope-to-be-noninflammatory opinion, there is less meat on =
these bones than the author set out to provide. In particular, there is =
virtually no explicit evidence of the consensus approach to &quot;Best =
Practices&quot; that he wants us to redefine. Nor are there any Oracle =
employees cited, which -- given the supposedly extremely close =
</FONT></P>

<P><FONT SIZE=3D2>coordination between Sun and Oracle -- is a =
disappointment. Rather than a </FONT>
<BR><FONT SIZE=3D2>blueprint, the document is more like a series of =
cool technical tidbits, </FONT>
<BR><FONT SIZE=3D2>flying in close formation.</FONT>
</P>

<P><FONT SIZE=3D2>On balance, I hope the author keeps this document =
going, and continues</FONT>
<BR><FONT SIZE=3D2>to track and add the little tidbits of information =
and &quot;how-to&quot; sketches</FONT>
<BR><FONT SIZE=3D2>that make it a good &quot;version 1.0&quot; =
technical note.</FONT>
</P>

<P><FONT SIZE=3D2>Ross</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: David Miller [<A =
HREF=3D"mailto:djm_at_oregon.West.Sun.COM">mailto:djm_at_oregon.West.Sun.COM</=
A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, January 25, 2001 12:07 PM</FONT>
<BR><FONT SIZE=3D2>To: Multiple recipients of list ORACLE-L</FONT>
<BR><FONT SIZE=3D2>Subject: New Sun/Oracle Blueprint available</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi Listers,</FONT>
</P>

<P><FONT SIZE=3D2>Sun has just published a new Blueprint on Sun/Oracle =
Best Practices.&nbsp; This is</FONT>
<BR><FONT SIZE=3D2>a technical document and covers a lot of topics I =
see on this list all the</FONT>
<BR><FONT SIZE=3D2>time.&nbsp; I know that several of them have been =
subjects of religious wars, but</FONT>
<BR><FONT SIZE=3D2>thought people would be interested anyway.&nbsp; I =
hope this information is useful.</FONT>
</P>

<P><FONT SIZE=3D2><A =
HREF=3D"http://www.sun.com/blueprints/0101/SunOracle.html" =
TARGET=3D"_blank">http://www.sun.com/blueprints/0101/SunOracle.html</A><=
/FONT>
</P>

<P><FONT SIZE=3D2>Dave Miller</FONT>
<BR><FONT SIZE=3D2>Sun Microsystems, Inc.</FONT>
</P>

<P><FONT SIZE=3D2>-- </FONT>
<BR><FONT SIZE=3D2>Please see the official ORACLE-L FAQ: <A =
HREF=3D"http://www.orafaq.com" =
TARGET=3D"_blank">http://www.orafaq.com</A></FONT>
<BR><FONT SIZE=3D2>-- </FONT>
<BR><FONT SIZE=3D2>Author: David Miller</FONT>
<BR><FONT SIZE=3D2>&nbsp; INET: djm_at_oregon.West.Sun.COM</FONT>
</P>

<P><FONT SIZE=3D2>Fat City Network Services&nbsp;&nbsp;&nbsp; -- (858) =
538-5051&nbsp; FAX: (858) 538-5051</FONT>
<BR><FONT SIZE=3D2>San Diego, =
California&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; -- Public Internet =
access / Mailing Lists</FONT>
<BR><FONT =
SIZE=3D2>---------------------------------------------------------------=
-----</FONT>
<BR><FONT SIZE=3D2>To REMOVE yourself from this mailing list, send an =
E-Mail message</FONT>
<BR><FONT SIZE=3D2>to: ListGuru_at_fatcity.com (note EXACT spelling of =
'ListGuru') and in</FONT>
<BR><FONT SIZE=3D2>the message BODY, include a line containing: UNSUB =
ORACLE-L</FONT>
<BR><FONT SIZE=3D2>(or the name of mailing list you want to be removed =

Received on Thu Jan 25 2001 - 11:57:39 CST