For Larry Sanders...


The recovery log currently is used to contain uncommitted
transactions.  Typically the recovery log size stabilizes (unlike
the database which can continue to grow as more and more
data is put into the server).

The log size is dependent on the number of concurrent transactions.
If you are running many backup sessions at the same time, you
may be growing your log unnecessarily.  There are practical limits
(eg, network bandwidth and server capacity) that determine how many
concurrent backup sessions you can efficiently run to your adsm server.

I would suggest checking how many concurrent backups you can run to your
server before your network and/or server swamp.  If this number is,
for example, 10-20....and your schedules are kicking off 50-100
concurrent backups....your recovery log will require more space than
needed.  Organize your schedules (and maybe the max sessions parameter
on the server) to limit the number of active sessions to around the
optimal number.

Another possibility could be that you have a hung transaction that
is hording recovery log space.  Q SESSIONS to check active sessions
and try issuing SHOW TXNT on the server console when you think the
server is idle. This will show transactions the server thinks are there.
If you suspect some problems, call service to get further assistance
from development...

Greg Tevis
ADSM Technical Support
gtevis AT vnet.ibm DOT com