I agree with Paul, it is pretty rare - but it can happen.  You can't
guarantee to prevent software or hardware corruption : you just have
to plan the recovery path ...

The last corruption I had was on a (pretty large) test DB when trying
to see the impact of a problem I had at 3.7 (live) on the 4.1 (test)
DB.  Well, the 4.1 DB got corrupted, the server crashed and it wouldn't
restart - I won't bore you with the details.  The point is, I was able
to recover the DB using the last FULL, INCRs and recovery log.  This
level of protection is essential for us.

Like Paul, we have also had problems with the recovery log filling up
too quickly (as well as the occasional 'pinned' logtail).  Recently,
we have escaped by the skin of our teeth when the recovery log hit 99%
and the triggered INCR could not complete fast enough ( - trigger now
lowered and we split expire inventory into a twice weekly run).  I too
have reservations about the 13GB log (although we certainly intend to
use it) and I have been looking at timings for triggered INCRs; 13GB
may take rather a long time ...

Regards, Sheelagh
--
Sheelagh Treweek
Sheelagh Treweek
Oxford University Computing Services
Email: sheelagh.treweek AT oucs.ox.ac DOT uk
Phone: +44 (0)1865 273205 Fax:-273275
+---------------------------------------------------------------------+
|  http://tsm-symposium.oucs.ox.ac.uk/   OXFORD 20/21 September 2001  |
|  REQUIREMENTS http://tsm-symposium.oucs.ox.ac.uk/requirements.html  |
+---------------------------------------------------------------------+