RE: default striping for redo logs in asm
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <kaygopal@xxxxxxxxx>, <chris_stephens@xxxxxxxxxxxx>
- Date: Wed, 26 Nov 2008 15:38:58 -0500
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.
>
>
>
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
