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




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