> There are different reasons for running your log in roll-forward or normal
> mode.
> Roll-Forward Mode:
> You have to assign more space for the recovery log; which in Brett's case,
> clearly indicated that his recovery log was not "big" enough to run in
> roll-forward mode. The good thing about running your log in roll-forward
> mode is that:
> - You can set an automatic ADSM DATABASE backup-trigger(If your log reaches
> a certain percentage utilization:e.g. 70%, an automatic database backup
> will be triggerred.) Which means that if you loose your ADSM DATABASE, you
> can restore to the latest database backup.

You can always restore to the latest database backup, no matter what log
mode one uses.  The difference with RollForward is that after restoring
from the last backup, you can then re-apply the recovery log transactions,
returning you to the time just before the failure.  In normal mode, you
would have to redo the work since the last backup.

I don't use Roll-Forward mode anymore because:
    - I needed more than 5GB to prevent a backup from being triggered, and
      the max. log file size is 5.3GB (if memory serves).  I do NOT want a
      DB Backup triggered during the wee hours when client backups are
      running.
    - If you are at the max filesize for the log, and it fills before the
      triggered DBBackup completes, you will have to do a restore DB.
      (If you are not at the max when the log fills during the triggered
       backup, then you can extend the log, start the server, and run the
       dbbackup).
    - If you want the full dbbackup to be scheduled, then you have to be
      carefull with the number-of-incrementals between full on the
      trigger, otherwise you might kick off a full on a weekday night
      during client backups, which probably means the log will fill and
      the server crash before the backup completes.
    - If you are mirroring your DB and LOG volumes, what does roll-forward
      actually protect you from?  Multiple disk failures that take out all
      copies of the same DBvol.

> Normal Mode:
> You don't need that much space for your recovery log, but you have to
> schedule full or incremental database backups. Which means that if you
> loose your ADSM DATABASE, you have to restore your database to a specific
> point-in-time

     The above statement seems to imply that "scheduled DB backups" are an
undesirable thing.  I think that DBBackups triggered at unpredictable
times are undesirable, and that scheduled ones are preferred.  Even when I
used RollForward mode, I still "scheduled" my backups by setting the
trigger to 1.  This ensured that my Full would run on Sunday, and not in
the middle of the week, unless some did get triggered, and then I had to
adjust the trigger to get a full on Sunday.  A bit of a pain, and meant I
had to keep close tabs on things.

     IMHO, the only thing RollForward gives you over NormalMode with
mirrored DB and LOGS is the ability to restore the DB to the last backup,
plus the log, and only if your recovery log is intact.  In NormalMode, you
would have to rerun all backups and tasks since the last DBBackup.  Due to
the operational issues with RollForward and it's size limitation, I do not
use it.  If I could have a 10GB recovery log so that a dbbackup will never
get triggered unless I want it to, then I might reconsider.  However, the
larger the recovery log, the more painfull other tasks become, like
processing after a crash, reformating the log, etc...

     If I was not mirroring my DB, then I would use RollForwardMode.

Steve (unVMix Systems Programmer/Dude) Roder
(tkssteve AT ubvm.cc.buffalo DOT edu | tkssteve AT acsu.buffalo DOT edu | 
(716)645-3564 ,
   | http://ubvm.cc.buffalo.edu/~tkssteve)