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_at_rsiz.com] Sent: Wednesday, November 26, 2008 2:39 PM To: kaygopal_at_gmail.com; Stephens, Chris
Cc: oracle-l_at_freelists.org
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_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]
On Behalf Of K Gopalakrishnan
Sent: Tuesday, November 25, 2008 5:50 PM To: chris_stephens_at_admworld.com
Cc: oracle-l_at_freelists.org
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_at_admworld.com> 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