Re: Large discrepancy between 'log file parallel write' and 'db file parallel write' times
Date: Sat, 12 Jan 2013 21:49:55 +0200
Message-ID: <CAMHX9J+t3wHenMQtHwd=+aCymmykpDN5wG9ojnbz9_uLbqQbUA_at_mail.gmail.com>
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_at_hotmail.com> wrote:Received on Sat Jan 12 2013 - 20:49:55 CET
> 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_at_tanelpoder.com
> To: john.clarke_at_centroid.com
> CC: puravc_at_gmail.com; mccmx_at_hotmail.com; oracle-l_at_freelists.org
>
>
> 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_at_centroid.com>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.
>
>
-- http://www.freelists.org/webpage/oracle-l