Aren't writes to the DB logged and journaled via the log volumes?


In my experience, the DB cache is mostly for read ahead and caching
often used DB pages. It reduces the number of times the ADSM has to go to
physical disks for information.

Without enough cache space, my system thrashed its DB disks with just
a low number of multiple simultaneous clients.  According to sar: 100%
busy disks with very long average request service times -- i.e.,
seeking all over the disk surface.

This came on as the DB size grew.  No amount of rearranging the disks,
stripping the disks, undoing mirroring, or changing the parallel read
options would fix it.


Netware clients suffered quite badly.  They only consider one
directory at a time (MEMORYEFFICIENTBACKUP hardwired as on).  They
forced the ADSM server to constantly consult the DB.  Watching the
backup run on a Netware console, the "files examined" messages came up
very, very slowly.




The rule of thumb for CPU caches is something like "1% cache miss,
factor of 10 performance hit".

For ADSM it felt like "1% cache miss, 10% performance hit".  So at 90%
I was getting 1/100th of the performance I was a few months before.


The cryptic words quoted earlier about the tuning of the cache contain
gold.


Russell
(can I stop rambling now?)


[Charset iso-8859-1 unsupported, filtering to ASCII...]
> |The database buffer pool provides cache storage, which allows
> |database pages
> |to remain in memory for longer periods of time. When database pages
> |remain in cache, the server can make continuous updates to the
> |pages without
> |requiring I/O operations to external storage.
>
> that's all very fine for performances.  but isn't it dangerous in case of
> crash?  everything that's in the cache will be lost, won't it?
>
> John O'Neall
> Centre de Calcul de l'IN2P3