RE: default striping for redo logs in asm

Thanks!

So if I wanted to come up to speed on disk technologies and how the rhel
+ oracle handles i/o, would there be someplace in particular I should go
looking or do I just need to go searching and read everything I can
find.  

-----Original Message-----
From: Mark W. Farnham [mailto:mwf@xxxxxxxx] 
Sent: Wednesday, November 26, 2008 2:39 PM
To: kaygopal@xxxxxxxxx; Stephens, Chris
Cc: oracle-l@xxxxxxxxxxxxx
Subject: RE: default striping for redo logs in asm

While this might be the reasoning (and I suspect Gopal might know from
direct conversations with folks doing the reasoning), I believe it
represents flawed thinking (quite rare in the area of Oracle
recoverability).

Short writes under 512 bytes do indeed cause wastage, but do not force a
new
seek to write another 512 bytes. (Of course Oracle is forced to write on
commit, which drives whatever constitutes the change vectors from the
log
buffer.) For OLTP operations that means 128kb is probably always large
enough to avoid extraneous seeks on write. For batch operations running
against nothing, write can often bump up against the artificial limit of
1
MB, and even in batch operations running against nothing the time event
or
the log buffer being one third full is likely to limit the write size so
there cannot much of a penalty due to limiting the maximum write to 1
MB.
However if you do write 1 MB against 128K stiping then you'll likely
have
extraneous seeks and rotational delay unless you're allowing the write
cache
to be considered a completed write.

Worse, in the eventuality that you are doing recovery (or more likely
using
some variety of standby recovery, including Oracle's own Dataguard), or
some
variety of log mining, it would be ideal to optimize the striping to
facilitate very large sequential reads so that some layer of cache can
be
filled as quickly as possible. If you make sure the archived log
destination
operates on its own, you can minimize this overhead as well. Of course
that
implies you are willing to pierce the veil and look at the actual
storage
through all the layers down to the "spinning rust." In the alternative
(and
please only go to this extra work and cost if you have a measured delay
you
want to eliminate or you are constructing a system template to
preemptively
avoid these possibilities) you could stage online redolog and archives
on
diskgroups built on SSD or flash. (See all of Kevin Closson's very fine
analyses on the limits of this in increasing throughput. But also don't
ignore the value of untangling logs and archives from the rest of your
disk
farm (and its cache) and as the cost of SSD and flash drop the potential
to
isolate online logs and avoid logwriter fighting with archiver cheaper
than
consuming whole spindles or sets of spindles.)

Gopal's point about wastage does bring an interesting thing to mind.
With
the advent of disks built on a sector size of 4K instead of 512 bytes, I
wonder if "wastage" will dramatically rise on such devices, or if Oracle
has
to figure out how to write and re-write the 8 pieces. Ugggg. I don't see
a
win in there anywhere.

Regards,

mwf

-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of K Gopalakrishnan
Sent: Tuesday, November 25, 2008 5:50 PM
To: chris_stephens@xxxxxxxxxxxx
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: default striping for redo logs in asm

Because redo writes are smaller in nature and  the maximum possible
write size of redo is 1MB.  Though the writes are sequential the size
of individial writes are probably less than 512 bytes (that is why you
see 'redo wastage' ).

-Gopal




On Tue, Nov 25, 2008 at 12:41 PM, Stephens, Chris
<chris_stephens@xxxxxxxxxxxx> wrote:
> While reading through the documentation on asm, I noticed the
onlinelogs
are
> striped in 128kb chunks while datafiles are striped in 1mb chunks.
Maybe
> I'm missing something here but given the fact that redologs are
written to
> sequentially, what would be the benefit of doing that?
>
>
>
> Thanks,
>
> Chris
>
>
> CONFIDENTIALITY NOTICE:
> This message is intended for the use of the individual or entity to
which
it
> is addressed and may contain information that is privileged,
> confidential and exempt from disclosure under applicable law. If the
reader
> of this message is not the intended recipient or the employee or agent
> responsible for delivering this message to the intended recipient, you
are
> hereby notified that any dissemination, distribution or copying of
this
> communication is strictly prohibited. If you have received this
> communication in error, please notify us immediately by email reply.
>
>
>
--
http://www.freelists.org/webpage/oracle-l





CONFIDENTIALITY NOTICE: 
        This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is privileged,
confidential and exempt from disclosure under applicable law.  If the reader of 
this message is not the intended recipient or the employee or agent responsible 
for delivering this message to the intended recipient, you are hereby notified 
that any dissemination, distribution or copying of this communication is 
strictly prohibited.  If you have received this
communication in error, please notify us immediately by email reply.



--
http://www.freelists.org/webpage/oracle-l


Other related posts: