Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: stipe size

RE: stipe size

From: Nelson Flores <nflores_at_expand.cl>
Date: Wed, 25 Feb 2004 20:39:21 -0800
Message-ID: <006401c3fc22$8883c310$cce8cd18@neltox>


LOL ;)
A little list with all the <what-would-Mladen-do> would be a riot...

-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Cary Millsap Sent: Wednesday, February 25, 2004 8:32 PM 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
-----------------------------------------------------------------

----------------------------------------------------------------
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 Wed Feb 25 2004 - 22:38:22 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US