I've successfully used roll-forward, and I never *yes, never* extend the
log to its fullest, so I will be able to do an emergency extend.  I guess
that's the most important consideration-- leaving yourself someplace to go.

Not using roll-forward is a gothca in an environment where archive-deletes
are done.  If you do an archive-delete and the server goes down and you
need to get it back-- you'll only be able to go as far as the last
dbbackup-- and your archived files are gone (database has no record of
them) and they are deleted on the client box (it didn't go back in time).





                    "Stapleton,
                    Mark"                To:     ADSM-L AT VM.MARIST DOT EDU
                    <stapleto@BERB       cc:
                    EE.COM>              Subject:     Re: Over extended log
                    Sent by:
                    "ADSM: Dist
                    Stor Manager"
                    <ADSM-L AT VM DOT MAR
                    IST.EDU>


                    02/06/2003
                    08:42 AM
                    Please respond
                    to "ADSM: Dist
                    Stor Manager"





From: Roger Deschner [mailto:rogerd AT UIC DOT EDU]
> Preventing log fillups is a delicate balancing process,
> especially if you run in ROLLFORWARD mode.
>
> But right now you're in a jam - you've got to extend your
> log, but you cannot because it is as large as it can be
> (13gb). Call Tivoli support. Then shrink your log back down
> to 12gb, so you can do an emergency log extention on the next
> Dark and Stormy Night.

I was once an Advocate for rollforward log mode, because I liked the
idea of being able to restore a TSM system to the moment of failure.
However, after dealing with more than a few  customers' systems that
came down hard because the log filled to capacity, I have ceased all
hostility in this advocacy war. As nice as rollforward can be, I have
yet to see anyone actually make use of its utility.

I now set all customers' logs to normal mode, and I make sure that all
db volumes are hardware mirrored on separate disks. This seems to be all
the redundancy necessary for continuous operations.

--
Mark Stapleton (stapleton AT berbee DOT com)