RE: stipe size

Dang. I meant k=2,3,4,...


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@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Cary Millsap
Sent: Sunday, February 29, 2004 6:52 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: stipe size

...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@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Connor McDonald
Sent: Sunday, February 29, 2004 8:02 AM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: stipe size

Pretty much...

Its the floor of

a) block_size * multiread
b) SSTIOMAX (a constant in Oracle - typically 1m)
c) what the OS can handle (typically 256k or 1m)

hth
connor

 --- k.sriramkumar@xxxxxxxxxxxxxxxxxx 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@xxxxxxxxxx] 
> Sent: Thursday, February 26, 2004 10:02 AM
> To: oracle-l@xxxxxxxxxxxxx
> 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@xxxxxxxxxxxxx
> [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of
> k.sriramkumar@xxxxxxxxxxxxxxxxxx
> Sent: Wednesday, February 25, 2004 10:15 PM
> To: oracle-l@xxxxxxxxxxxxx
> 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@xxxxxxxxxx] 
> Sent: Tuesday, February 24, 2004 5:06 AM
> To: 'oracle-l@xxxxxxxxxxxxx'
> 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@xxxxxxxxxxxxxxx]
> > Sent:       Tuesday, February 24, 2004 8:34 AM
> > To: oracle-l@xxxxxxxxxxxxx
> > 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@xxxxxxxxxxxxx
> >   [mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Paul Drake
> >   Sent: Friday, February 20, 2004 3:09 PM
> >   To: oracle-l@xxxxxxxxxxxxx
> >   Subject: Re: stipe size
> > 
> > 
> >   --- Ruth Gramolini <rgramolini@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxx
> >   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@xxxxxxxxxxxxx
> > 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@xxxxxxxxxxxxx
> 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@xxxxxxxxxxxxx
> 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@xxxxxxxxxxxxx
> 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@xxxxxxxxxxxxx
> 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@xxxxxxxxx

"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@xxxxxxxxxxxxx
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@xxxxxxxxxxxxx
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@xxxxxxxxxxxxx
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
-----------------------------------------------------------------

Other related posts: