Given that this is one of the more comman FAQ style questions on
this listserv, I wonder if it's not time for someone to submit a
TSM requirement that the server behave better in a recovery log
full situation. This happens in other databases w/o causing a
SIGSEGV. Oracle, for example, simply prevents any database
changes, and only allows new administrative connections to the
database until the log full situation is cleared (by archiving
the online redo logs). It seems that TSM could behave similarly.

Certainly the server is not in a great state when the log
segments are full, but it would seem easier to recover, and
somewhat less confusing to administrators, if it could be done
online, rather than in the manner in which it is handled now.
We've all probably experienced a situation where we are close to
the limit on the log size, so we only extend the log a little
bit, and then there is a rush to see if our database backup is
going to finish and clear the log full condition before we use up
the additional log space--lest we find ourselves in the same
perilous condition, only *closer* to the seemingly arbitrary
maximum log size.

 -- Tom

Thomas A. La Porte
DreamWorks SKG
tlaporte AT dreamworks DOT com

On Wed, 1 May 2002, Sung Y Lee wrote:

>When log reaches 100%, just pray that TSM server process will not crash.
>
>
>I say the key is prevention.  Whatever you can do to prevent that from
>happening is the best answer.
>
>There are many things you can do to prevent from growing to 100%.
>One that works for me is I have LogMode set to Roll Forward mode with dbb
>trigger at 38% with incremental between at 3(q dbb)
>Log is also set to maximum allowed without going over limit plus room for
>extension should it ever reaches 100% and TSM crashes.  Have it set at 4.5
>GB(To be safe).  Max allowed recovery log for TSM 4.1 is 5.3 GB?? I can't
>recall exact value.
>
>
>If the TSM server is in Log mode than more than likely it will have dbb
>trigger set at certain point.   For example,
>adsm> q dbb
>
>Full           Incremental       Log Full         Incrementals
>Device         Device          Percentage  Between
>Class          Class                    Fulls
>----------     -----------     ----------     ------------
>IBM3590        IBM3590                 38                 3
>
>When the recovery log reaches 38%, an incremental database backup will kick
>off up to 3 threes before a full database backup performed.   The most of
>time TSM server will prevent other sessions from establishing when the
>recovery log reaches 100% but will allow the trigger database backup to
>complete and it will bring the recovery log down to 0.  Sometimes TSM will
>simply crash.  If it crashes then you will need to do an emergency recovery
>log extend and bring TSM backup.
>
>Sung Y. Lee
>E-mail sunglee AT us.ibm DOT com
>
>
>
>                      brian welsh
>                      <brianwelsh3@HOTM        To:       ADSM-L AT VM.MARIST 
> DOT EDU
>                      AIL.COM>                 cc:
>                      Sent by: "ADSM:          Subject:  Recovery Log almost 
> 100%
>                      Dist Stor
>                      Manager"
>                      <[email protected]
>                      .EDU>
>
>
>                      05/01/2002 01:23
>                      PM
>                      Please respond to
>                      "ADSM: Dist Stor
>                      Manager"
>
>
>
>
>
>Hello,
>
>AIX 4.3.3 and server 4.1.1.0.
>
>Last night two archive-schedules had a problem. On the clients there were
>files in a kind of loop and TSM tried to archive them. Result, recovery log
>almost 100%. This was the first time our log is that high. Problem on the
>client solved, but now I have the following question.
>
>I was wondering how other people prevent the log from growing to 100%, and
>how to handle after the log have reached 100%.
>
>Any tip is welcome.
>
>Brian.
>
>
>_________________________________________________________________
>MSN Foto's is de makkelijkste manier om je foto's te delen met anderen en
>af
>te drukken: http://photos.msn.nl/Support/WorldWide.aspx
>
>