Prev: TIMEOUT ON CONTROL FILE ENQUEUE
Next: ORA-12518 Listener could not hand off connection
From: Connor McDonald on 14 Sep 2005 09:58
Jonathan Lewis wrote:
>
[snip]
>
> It's interesting to note that your mreadtim is less
> than your sreadtim


In terms of mreadtim < sreadtim, we've encountered this on all databases
at our current site that SAN attached as opposed to JBOD. Haven't
really got the access to determine whether the SAN is *truly* yielding
better multiread IO times than singleread IO, but ultimately we've
resorted to

- collecting system stats
- tweaking mread to just above sread to enable mbrc inclusion for the
cbo


--
Connor McDonald
Co-author: "Mastering Oracle PL/SQL - Practical Solutions"
Co-author: "Oracle Insight - Tales of the OakTable"

web: http://www.oracledba.co.uk
web: http://www.oaktable.net
email: connor_mcdonald(a)yahoo.com


"Semper in excremento, sole profundum qui variat."

------------------------------------------------------------
From: Jonathan Lewis on 14 Sep 2005 11:01
"Connor McDonald" <connor_mcdonald(a)yahoo.com> wrote in message
news:43282C72.36FC(a)yahoo.com...
>
> In terms of mreadtim < sreadtim, we've encountered this on all databases
> at our current site that SAN attached as opposed to JBOD. Haven't
> really got the access to determine whether the SAN is *truly* yielding
> better multiread IO times than singleread IO, but ultimately we've
> resorted to
>
> - collecting system stats
> - tweaking mread to just above sread to enable mbrc inclusion for the cbo
>

That is an interesting tell-tale about what SANs
are probably good at, and bad at, doesn't it.

Don't share a SAN if you want to run a high
performance OLTP system - they're not very
good for small, highly randomised I/Os.




--
Regards

Jonathan Lewis

http://www.jlcomp.demon.co.uk/cbo_book/ind_book.html
Cost Based Oracle - Volume 1: Fundamentals
On-shelf date: Nov 2005

http://www.jlcomp.demon.co.uk/faq/ind_faq.html
The Co-operative Oracle Users' FAQ

http://www.jlcomp.demon.co.uk/appearances.html
Public Appearances - schedule updated 4th Sept 2005




From: VC on 14 Sep 2005 21:03

"Jonathan Lewis" <jonathan(a)jlcomp.demon.co.uk> wrote in message
news:dg9dve$5em$1(a)nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com...
> "Connor McDonald" <connor_mcdonald(a)yahoo.com> wrote in message
[...]>
> Don't share a SAN if you want to run a high
> performance OLTP system - they're not very
> good for small, highly randomised I/Os.
>

One can hardly not share a SAN nowadays, OLTP or otherwise, in an
enterprise environment that has nothing but a SAN. One can try not to share
a physical disk(s) in a SAN if one has access to a friendly SAN
administrator, though ;)


>
>
>
> --
> Regards
>
> Jonathan Lewis
>
> http://www.jlcomp.demon.co.uk/cbo_book/ind_book.html
> Cost Based Oracle - Volume 1: Fundamentals
> On-shelf date: Nov 2005
>
> http://www.jlcomp.demon.co.uk/faq/ind_faq.html
> The Co-operative Oracle Users' FAQ
>
> http://www.jlcomp.demon.co.uk/appearances.html
> Public Appearances - schedule updated 4th Sept 2005
>
>
>
>


From: DA Morgan on 14 Sep 2005 23:42
VC wrote:

> One can hardly not share a SAN nowadays, OLTP or otherwise, in an
> enterprise environment that has nothing but a SAN. One can try not to share
> a physical disk(s) in a SAN if one has access to a friendly SAN
> administrator, though ;)

If you are talking about storage administrators and their ability to
hoard resources. But maybe someday they will mellow out and learn to
create more than one LUN.
--
Daniel A. Morgan
http://www.psoug.org
damorgan(a)x.washington.edu
(replace x with u to respond)
From: Connor McDonald on 15 Sep 2005 09:07
Jonathan Lewis wrote:
>
> "Connor McDonald" <connor_mcdonald(a)yahoo.com> wrote in message
> news:43282C72.36FC(a)yahoo.com...
> >
> > In terms of mreadtim < sreadtim, we've encountered this on all databases
> > at our current site that SAN attached as opposed to JBOD. Haven't
> > really got the access to determine whether the SAN is *truly* yielding
> > better multiread IO times than singleread IO, but ultimately we've
> > resorted to
> >
> > - collecting system stats
> > - tweaking mread to just above sread to enable mbrc inclusion for the cbo
> >
>
> That is an interesting tell-tale about what SANs
> are probably good at, and bad at, doesn't it.
>
> Don't share a SAN if you want to run a high
> performance OLTP system - they're not very
> good for small, highly randomised I/Os.
>
> --
> Regards
>
> Jonathan Lewis
>
> http://www.jlcomp.demon.co.uk/cbo_book/ind_book.html
> Cost Based Oracle - Volume 1: Fundamentals
> On-shelf date: Nov 2005
>
> http://www.jlcomp.demon.co.uk/faq/ind_faq.html
> The Co-operative Oracle Users' FAQ
>
> http://www.jlcomp.demon.co.uk/appearances.html
> Public Appearances - schedule updated 4th Sept 2005

I would generalise to SAN's are not good at IO... period

:-)
--
Connor McDonald
Co-author: "Mastering Oracle PL/SQL - Practical Solutions"
Co-author: "Oracle Insight - Tales of the OakTable"

web: http://www.oracledba.co.uk
web: http://www.oaktable.net
email: connor_mcdonald(a)yahoo.com


"Semper in excremento, sole profundum qui variat."

------------------------------------------------------------
First  |  Prev  | 
Pages: 1 2 3 4
Prev: TIMEOUT ON CONTROL FILE ENQUEUE
Next: ORA-12518 Listener could not hand off connection