Suspicious delay of HDD activity after commit

Question

I know that after commit Oracle LGWR process writes the data
changies into the redo-log. And Oracle must return "Commited"
only after above is done. But when I do Commit, I don't see the
HDD LED blink. Only after 1-2 sec HDD LED blinks. Is it normal?
What people have?
null

Answer 1

To answer the question of caching and syncing:
Linux nearly caches all and does it on a high "level", means it
is one of the reason for the good I/O-performance of linux.
In order to make sure that data is directly written to the disks
you can mount your disks with the option sync.
An example: mount -o sync /dev/sdc1 /data_1
Note, that the performance will decrease. The other possibility
is a little tool called syncer, which is a daemon that causes
linux to clear its cache every xy seconds (any value you like). I
think (because I never used) it causes some overhead but is a
good compromise to the sync-option.
Deactivating caching in the kernel... I think this is not the
best solution if you are not familiar with kernel programming.
Also think of swapping and reads on the system-disk and so on.
Dietmar
p.s: I can't remember where I've found it, so I send it to your
personal account, because I can't add any files here
StE (guest) wrote:
: Mark Malakanov (guest) wrote:
: : I know that after commit Oracle LGWR process writes the data
: : changies into the redo-log. And Oracle must return "Commited"
: : only after above is done.
: Not quite true. Information is constantly flushed from the
: in-memory redo log buffer to disc while changes are taking
place
: to the database. When a transaction is committed the
: current contents of the redo-log buffer are flushed to disc,
: followed by a marker saying "SCN was committed" is written to
: disc - the changes themselves have already been written out.
: : But when I do Commit, I don't see the
: : HDD LED blink. Only after 1-2 sec HDD LED blinks.
: : Is it normal? What people have?
: That's probably normal, but that doesn't make it a good thing.
: The Linux buffer-cache does write-behind caching, so that dirty
: buffers arn't written out to disc immediately. If there were a
: failure the write of the commit or some of the preceeding redo
: log blocks might not make it to disc.
: I think you can tune the frequency with which bdflush wakes up
: and writes to disc. Setting it to a low value if you're worried
: about consistency over performance would be a good idea.
: I don't know whether there's an open() flag to perform writes
on
: a file synchronously or not under Linux. It's possible to
sync()
: an open filehandle, I think, so perhaps Oracle does a sync on
: the active redo log when it writes out the commit.
: Anyone know anything less vague and hand-waving?
: -michael
null