Re: Large discrepancy between 'log file parallel write' and 'db file parallel write' times
- From: Tanel Poder <tanel@xxxxxxxxxxxxxx>
- To: Matt McClernon <mccmx@xxxxxxxxxxx>
- Date: Sat, 12 Jan 2013 21:49:55 +0200
Yep the disk heads may well need to seek back to the proper location for a
write. But I was talking in the context of a single "log file parallel
write" wait event vs a "db file parallel write" wait event.
A single log file parallel write operation which you were measuring (max
1MB) likely does not need to write into many different locations on a disk
(with mirroring there's a different disk serving each mirror write). But a
db file parallel write - a vector write, may write hundreds of buffers into
completely different locations within a single system call / wait event.
So, simplifying, let's assume we have only one disk -> the log file write
needs to seek back to the proper location and do 1 write. The db file
parallel write may need to seek around hundreds of times and do hundreds of
writes.
And in practice, when running on a storage array with proper write cache,
then it may well happen that multiple log file parallel writes arrive to
the array cache before the disk even seeks into right position - and once
it does, it may already have multiple MB worth of writes to destage from
cache to disk, so somewhat increasing the sequential nature of log file
write IO.
But yes, as long as there's other activity going on (like data file access
or reads for log archiving), there will be seeking. And even without disk
head seeking, there's still rotational latency to wait for, so write
caching is a must for achieving low-latency log file writes & commits.
--
Tanel Poder
Online Training! - http://blog.tanelpoder.com/seminar
The Voicee App - http://voic.ee
On Tue, Jan 8, 2013 at 11:15 AM, Matt McClernon <mccmx@xxxxxxxxxxx> wrote:
> Hi Tanel,
>
> I've always wondered whether log file writes are really sequential I/O.
> for example on an Exadata platform the redo logs are in the RECO disk
> group which is carved from the same set of disks as the DATA disk group.
> So when a log file parallel write hits a disk, wont the head have
> potentially moved to service a DBWR write (or a sort write) since the last
> log file write, effectively making them 'random writes'.
>
> Matt
>
>
> ------------------------------
> Date: Sun, 6 Jan 2013 12:43:54 +0800
>
> Subject: Re: Large discrepancy between 'log file parallel write' and 'db
> file parallel write' times
> From: tanel@xxxxxxxxxxxxxx
> To: john.clarke@xxxxxxxxxxxx
> CC: puravc@xxxxxxxxx; mccmx@xxxxxxxxxxx; oracle-l@xxxxxxxxxxxxx
>
>
> Also note that the "log file parallel write" is not really random IO,
> compared to a "db file parallel write" which may write hundred(s) of
> buffers into random locations in a single vector IO call. That makes a
> difference even on non-exadata without IORM too (especially if there's no
> write-cache for DBWR writes or the storage array cache destaging can't keep
> up with the write workload).
>
> --
> Tanel Poder
> New Online Training!
> http://blog.tanelpoder.com/seminar
>
>
>
>
> On Fri, Jan 4, 2013 at 12:31 AM, John Clarke <john.clarke@xxxxxxxxxxxx>wrote:
>
> The behavior I was describing was specific to IORM & Exadata I/Os. To my
> knowledge there isn't a direct parallel to this for ASM in general, but I'm
> open to be educated ...
> With ASM without Exadata, background I/O is queued according to your async
> I/O configuration (or synchronously depending on O/S and init.ora
> settings), but the operating system or Oracle wouldn't interject any
> prioritization algorithm for LGWR I/Os vs DBWR I/Os.
>
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
