Does Linux filesystem undermine Oracle's recovery mechanism?

Question

I've been an Oracle DBA for 10 years and have been using Oracle
on Linux for several months, but am not a Linux expert by any
means. A client told me something about the filesystem Linux uses
(x2?) that I find hard to believe. Can anyone shed some light on
this?
The claim is that the Linux filesystem does not implement
synchronous writes correctly. The implication is that when a user
commits a transaction and Oracle flushes the redo log to disk,
Oracle may think the redo information has been successfully
written when in fact its still sitting in a buffer somewhere
waiting to write. If a drive failure occurs, the redo might never
get written, but meanwhile the user has already been informed
their transaction has been committed.
Oracle does not flush data block buffers to disk when you commit
a transaction. Only the redo is flushed. If the instance were to
fail, Oracle reads the redo when you restart the instance and
performs instance recovery automatically.
If the Linux filesystem does not implement synchronous writes
legitimately, then the recovery mechanisms in Oracle are
compromised--indeed a successful commit is not a guarantee of
data permanence.
Its hard to believe that this could be true; I don't see how
Oracle Corporation could put so much effort into porting their
flagship products to Linux if data permanence cannot be
guaranteed.
Is my client mistaken in their understanding of the Linux
filesystem? Any insights from the Linux gurus out there would be
gratefully appreciated!
Regards,
Roger Schrag
Database Specialists, Inc.
null

Answer 1

Roger Schrag (guest) wrote:
: I've been an Oracle DBA for 10 years and have been using
: Oracle on Linux for several months, but am not a Linux expert
: by any means. A client told me something about the filesystem
: Linux uses (x2?) that I find hard to believe. Can anyone shed
: some light on this?
: The claim is that the Linux filesystem does not implement
: synchronous writes correctly. The implication is that when a
: user commits a transaction and Oracle flushes the redo log to
: disk, Oracle may think the redo information has been
: successfully written when in fact its still sitting in a
: buffer somewhere waiting to write. If a drive failure occurs,
: the redo might never get written, but meanwhile the user has
: already been informed their transaction has been committed.
The problem doesn't lie with Linux - fsync() and O_SYNC are
supported and, AFAIK, behave correctly.
The problem is that Oracle doesn't appear to use them. The redo
logs arnt fsync'ed on commit, nor do they appear to be opened
with O_SYNC.
Data loss will result, as you point out, if the RDBMS doesn't
tell the operating system to save the data synchronously.
Play with strace()ing the RDBMS background processes and confirm
this for yourself.
I'm not in a position to progress this with Oracle. Someone,
obviously, should, otherwise the next article on ZDNet could be
"Linux causes massive Oracle dataloss"..
null