Thank you SO much!  The whole concept of rollforward is much clearer for me
now.  I think that with the environment that I am working in rollforward is
the way to go.

Joni Moyer
Associate Systems Programmer
joni.moyer AT highmark DOT com
(717)975-8338



                    "Prather, Wanda"
                    <Wanda.Prather@J       To:     ADSM-L AT VM.MARIST DOT EDU
                    HUAPL.EDU>             cc:
                    Sent by: "ADSM:        Subject:     Re: rollforward vs. 
normal mode
                    Dist Stor
                    Manager"
                    <[email protected]
                    T.EDU>


                    07/23/2002 09:20
                    AM
                    Please respond
                    to "ADSM: Dist
                    Stor Manager"






Hi Joni,

In my opinion, you should always use ROLLFORWARD, unless you run into a
performance or capacity limitation that prevents you from doing so.

If you use rollforward mode and you have a hardware crash or a software
crash that causes you to have to restore your DB, TSM will restore the DB,
roll forward from the logs, and you will be right back to where you
started,
with no loss of data.

If you use normal mode and you have a hardware crash or a software crash
that causes you to have to restore your DB, you can ONLY restore up to the
time of your last DB backup.  You WILL lose data.  You may not care if you
lose some backups, but if you also had a lot of tape activity since the
last
DB backup (migration, reclaim), you will spend MANY HOURS doing audits
trying to get your tapes and DB in sync again.

So rollforward DOES give you a lot of protection.
The tradeoff is that when you have a very busy system, in rollforward mode
the log gets much larger and it's harder to manage.

There are some sites that don't have too many clients; they can control
very
precisely when things like migration and reclaim occur, and they feel that
rollforward is unnecessary because all they would lose is one night's
backups.

On the other hand, if you are in an environment that runs HSM, you can't
afford to lose ANY DB data, you MUST run in rollforward mode.

If you have hundreds of clients and runs backups/reclaims 24 hours a day,
which means you have a zillion DB changes going on every hour, you really
NEED to run in rollforward mode.

On the third hand (everything in the distributed world is always
complex:>),
I have one system that is so busy we kept crashing BECAUSE we were in
rollfoward mode and kept filling up the logs.

So I think the appropriate rule of thumb is to ALWAYS run in ROLLFORWARD
mode, until your system is so busy you can no longer do so because of
capacity/performance limitations.

And the size of your logs is determined by the amount of activity (i.e.,
the
number of CHANGES to the DB) between DB backups, not the size of the DB.
SO
you just have to keep an eye on the log %util and keep adding space until
you have enough to get you from one DB backup to the next, based on YOUR
installation activity.  There isn't any way to calculate it ahead of time.

(When you switch to rollforward mode, set the DBBACKUPTRIGGER to fire an
INCREMENTAL DB backup when the DB gets to 70% full.  That will give you an
escape hatch if you guess wrong on sizing the logs...)

************************************************************************
Wanda Prather
The Johns Hopkins Applied Physics Lab
443-778-8769
wanda_prather AT jhuapl DOT edu

"Intelligence has much less practical application than you'd think" -
Scott Adams/Dilbert
************************************************************************