As far as Log sizing, I think the only log size that makes any sense is
exactly 12gb. Why make it smaller, when disks are so cheap? And you
cannot make it larger, because as you say, you've got to leave yourself
someplace to go when it fills up.

However, what you are doing with archive-delete sounds dangerous, even
with the log in rollforward mode. I would never complete the delete part
of an archive-delete without some kind of safety mechanism, such as
delaying the delete by one day. I know TSM is good, but you are well
aware of the risk because you refuse to run in Normal mode. I would go
farther, and not delete the file from the original system until I knew
it has been migrated from the disk storage pool to the tape storage
pool, and also copied to the backup copy storage pool.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu



On Thu, 6 Feb 2003, Lisa Cabanas wrote:

>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).