Vijay,

Our system exhibited the same symptoms.  We eventually traced it to some Unix
clients that had links configured circularly.  For example "/linkA" in
"/folderA" pointed to "/folderB" that had a link back to "/folderA".

The result was that our archives would fill up with objects that had paths like:
/folderA/folderB/folderA/folderB/.../folderA/file
/folderA/folderB/folderA/folderB/.../folderA/folderB/file
...

When *SM support introduced the Follow Symbolic option that finally fixed the
problem.

Until then, archive jobs would fill up our 5 GB recovery log and crash the
server because it couldn't write an incremental backup of the DB fast enough to
recover.

Good luck.

Tab Trepagnier
Laitram Corporation







"<James> <healy>" <James.Healy2 AT AXACS DOT COM> on 12/11/2000 07:52:31 AM

Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>

To:   ADSM-L AT VM.MARIST DOT EDU
cc:    (bcc: Tab Trepagnier/Corporation/Laitram/US)
Subject:  Re: LOG usage over 100% - backups failing




Vijay,
     Sounds like you have some other problem with the transactions not
getting written to the database quick enough.
Can you tell us more about your environment. Sounds like you've made some
changes there recently? Whats your database backup trigger set at?
What are you db adn recovery log buffer pool stats like?
Jim




"Vijay Havaralu" <vhavaralu AT CHUBB DOT COM>@VM.MARIST.EDU> on 12/11/2000
08:36:26 AM

Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>

Sent by:  "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To:   ADSM-L AT VM.MARIST DOT EDU
cc:

Subject:  LOG usage over 100% - backups failing


Hello every one,
We are running tsm-server ver 3.7.20 on aix 4.3.2 with about 400 gb per day
backup.
Our adsm db-size is close to 100 gb and growing daily.
Almost each day log is overflowing with 100%, all backups fails, and server
recovers & continues
We are already using max 5.4 gb of log and can not increase any more on log
volume.

I appreciate, if anybody has any solutions this problem to reduce log usage
or extend log beyond 5.4gb.

Thanks, vijay.