...Times some integer k=1,2,3,...
It is a small probability that an I/O call will begin at a stripe
boundary. If an I/O call does begin with a block that is not the
beginning block of a stripe, and if your stripes are sized exactly the
same as your I/O calls, then a single read request will most often
require visits to two stripes.
Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
* Nullius in verba *
Upcoming events:
- Performance Diagnosis 101: 3/23 Park City, 4/6 Seattle
- Hotsos Symposium 2004: March 7-10 Dallas
- Visit www.hotsos.com for schedule details...
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Connor McDonald
Sent: Sunday, February 29, 2004 8:02 AM
To: oracle-l_at_freelists.org
Subject: RE: stipe size
Pretty much...
Its the floor of
- block_size * multiread
- SSTIOMAX (a constant in Oracle - typically 1m)
- what the OS can handle (typically 256k or 1m)
hth
connor
- k.sriramkumar_at_iflexsolutions.com wrote: > Hi Cary,
>
> Thank you for excellent explanation. I am guessing that "largest
I/O call" on a database could
> be DB_BLOCK_SIZE times DB_FILE_MUTLIBLOCK_READ_COUNT. Am I correct in
saying that?
>
> Best Regards
>
> Sriram Kumar
>
>
>
> -----Original Message-----
> From: Cary Millsap [mailto:cary.millsap_at_hotsos.com]
> Sent: Thursday, February 26, 2004 10:02 AM
> To: oracle-l_at_freelists.org
> Subject: RE: stipe size
>
> Beware small stripe sizes, even for TP systems. Don't make your stripe
> size any smaller than the largest I/O call size that your system will
> normally do. Striping is parallelism: the enemy of concurrency. If
your
> stripe size is so small that a single application read call can engage
> the service of two or more disks, it'll be great for a few-user
system.
> But pack on the users, and you're going to hit the wall hard and with
a
> big splat. You'll have I/O device queueing out your ears, and
depending
> on where your RAID code path resides, possibly it'll choke your whole
OS
> in the process.
>
> What is "small"? I think anything less than about 1MB is small, even
for
> TP. Since 7.3, the Oracle kernel does its very best to do large read
> calls. This is a Good Thing. Using stripe sizes that cut a single
large
> I/O call into multiple parts is a Bad Thing on a many-user system.
>
> <what-would-Mladen-do>
> ...However, if the original question is really about "stipe size," I
> believe that Michael Stipe is a little bitty devil, probably not more
> than about 5'4" at most. But this is really outside of my subject of
> expertise.
> </what-would-Mladen-do>
>
>
> Cary Millsap
> Hotsos Enterprises, Ltd.
> http://www.hotsos.com
> * Nullius in verba *
>
> Upcoming events:
> - Performance Diagnosis 101: 2/24 San Diego, 3/23 Park City, 4/6
Seattle
> - Hotsos Symposium 2004: March 7-10 Dallas
> - Visit www.hotsos.com for schedule details...
>
>
> -----Original Message-----
> From: oracle-l-bounce_at_freelists.org
> [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of
> k.sriramkumar_at_iflexsolutions.com
> Sent: Wednesday, February 25, 2004 10:15 PM
> To: oracle-l_at_freelists.org
> Subject: RE: stipe size
>
> Hi Lim,
>
> I am in also in the view that Smaller stripe is beneficial for a
> OTLP application. We normally suggest a 32K or a 64K stripe size for
> RAID. Can you pls shed more light on this statement
>
> <Quote>
>
> This is because smaller stripe sizes requires more stripes(spindles)
to
> spin, and when many other activities are going on, saturation point is
> reached rather quickly.
>
> </Unquote>
>
> Best Regards
>
> Sriram Kumar
>
> -----Original Message-----
> From: Lim, Binley [mailto:Binley.Lim_at_NBNZ.CO.NZ]
> Sent: Tuesday, February 24, 2004 5:06 AM
> To: 'oracle-l_at_freelists.org'
> Subject: RE: stipe size
>
>
> In general, the stripe size should be able to satisfy
> the periods of heavy loads (many, and larger queries)
> without being overwhelmed. As has been mentioned,
> batch jobs benefit from larger stripe sizes. This
> is because smaller stripe sizes requires more
> stripes(spindles) to spin, and when many other
> activities are going on, saturation point is reached
> rather quickly.
>
> Even for OLTP which generally benefits from a
> smaller stripe size, the existence of cache means
> you are likely to satisfy the read from cache
> anyway, so the effect becomes less obvious.
>
> Whichever way, you have a great opportunity to test
> out the various sizes and see what happens. In your
> testing, be sure to stress the cache. Below that point,
> you are un-likely to see the effects of stripe size. I would venture
a
> guess and say 64k is too small, try maybe 128k or 256k... but again,
> there
> is no substitute for testing.
>
>
> > -----Original Message-----
> > From: Ruth Gramolini [SMTP:rgramolini_at_tax.state.vt.us]
> > Sent: Tuesday, February 24, 2004 8:34 AM
> > To: oracle-l_at_freelists.org
> > Subject: RE: stipe size
> >
> > We are running AIX5.2 with Oracle 9.2.0.4, 64 bit. The DB block
size
> in
> > 8192. I am copying the specs my SA gave me to answer such
questions.
> > Thanks Paul! (I hear that you will be coming to my Birthday Bash in
> > October, I am so glad!)
> >
> > Ruth
> >
> > From my SA:
> >
> > And just to give you some the answers to some of the questions that
> poster
> > asked:
> > We have 1GB of cache and all logical devices are configured with
write
> > back
> > cache. The cache is also used for read ahead so every read request
> > actually
> > reads at least 64KB from disk and then keeps it in cache.
> > Our "weighted average" I/O size is in the 20-50KB range (depending
on
> what
> > LV you look at).
> >
> >
> > -----Original Message-----
> > From: oracle-l-bounce_at_freelists.org
> > [mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Paul Drake
> > Sent: Friday, February 20, 2004 3:09 PM
> > To: oracle-l_at_freelists.org
> > Subject: Re: stipe size
> >
> >
> > --- Ruth Gramolini <rgramolini_at_tax.state.vt.us> wrote:
> > > Good morning all,
> > > We just installed a new fast disk farm with fiber
> > > channels. For production
> > > we are using raid 10. My SA set in up with a stipe
> > > size of 64K based on the
> > > size of most of the transactions. He wants to know
> > > if this will be OK. I
> > > don't know so I told him I would ask the experts.
> > > What do you think?
> > >
> > > Thanks,
> > > Ruth Gramolini
> > > Oracle DBA
> > > Vermont Department of Taxes
> >
> > Hi Ruth.
> >
> > I'm not claiming to be an export, but I'll chime in
> > anyways. :)
> >
> > What operating system and version are you running
> > Oracle Server on?
> > What is the database block size?
> > What filesystem are you using, or are raw volumes in
> > use?
> > Does the storage unit have a cache that is used for
> > pre-fetching, and does it also support write-back
> > cacheing?
> > How many drives comprise the striped volume?
> >
> > In an average statspack report, what is the average
> > number of blocks fetched per request in your data,
> > index and temp tablespaces?
> >
> > If you're performing mostly single block accesses,
> > then a smaller stripe size will carry the least
> > overhead, but may make maintenance operations take
> > longer.
> >
> > It will be a tradeoff of optimizing performance of
> > daily oltp activity (single block requests), vs. your
> > monthly batch jobs which are likely more
> > batch-oriented, which may favor a largish stripe size,
> > say 512KB.
> >
> > I'd highly recommend that he short-stroke the drives,
> > and only throw a filesystem on the outer half of the
> > disks for datafiles, and throw a filesystem on the
> > inner half for storing backups, archlogs, etc.
> >
> > Paul
> >
> > token reference to Juan Loiza's paper on SAME up on
> > the BAARF.net site
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Mail SpamGuard - Read only the mail you want.
> > http://antispam.yahoo.com/tools
> > ----------------------------------------------------------------
> > 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
> > -----------------------------------------------------------------
>
> This communication is confidential and may contain privileged
material.
> If you are not the intended recipient you must not use, disclose, copy
> or retain it.
> If you have received it in error please immediately notify me by
return
> email
> and delete the emails.
> Thank you.
> ----------------------------------------------------------------
> 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
> -----------------------------------------------------------------
>
>
> DISCLAIMER:
> This message contains privileged and confidential information and is
> intended only for the individual named.If you are not the intended
> recipient you should not disseminate,distribute,store,print, copy or
> deliver this message.Please notify the sender immediately by e-mail if
> you have received this e-mail by mistake and delete this e-mail from
> your system.E-mail transmission cannot be guaranteed to be secure or
> error-free as information could be
> intercepted,corrupted,lost,destroyed,arrive late or incomplete or
> contain viruses.The sender therefore does not accept liability for any
> errors or omissions in the contents of this message which arise as a
> result of e-mail transmission. If verification is required please
> request a hard-copy version.
> ----------------------------------------------------------------
> 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
> -----------------------------------------------------------------
>
>
> DISCLAIMER:
> This message contains privileged and confidential information and is
intended only for the
> individual named.If you are not the intended recipient you should not
> disseminate,distribute,store,print, copy or deliver this
message.Please notify the sender
> immediately by e-mail if you have received this e-mail by mistake and
delete this e-mail from
> your system.E-mail transmission cannot be guaranteed to be secure or
error-free as information
> could be intercepted,corrupted,lost,destroyed,arrive late or
incomplete or contain viruses.The
> sender therefore does not accept liability for any errors or omissions
in the contents of this
> message which arise as a result of e-mail transmission. If
verification is required please
> request a hard-copy version.
> ----------------------------------------------------------------
> 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
> -----------------------------------------------------------------
Connor McDonald
Co-author: "Mastering Oracle PL/SQL - Practical Solutions" - available
now
web:
http://www.oracledba.co.uk
web:
http://www.oaktable.net
email: connor_mcdonald_at_yahoo.com
"GIVE a man a fish and he will eat for a day. But TEACH him how to fish,
and...he will sit in a boat and drink beer all day"
Yahoo! Messenger - Communicate instantly..."Ping"
your friends today! Download Messenger Now
http://uk.messenger.yahoo.com/download/index.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
-----------------------------------------------------------------
Received on Sun Feb 29 2004 - 18:51:15 CST
