ADSM-L

Re: Recovery log filling up quickly, too quickly. Ideas?

2005-05-05 12:21:35
Subject: Re: Recovery log filling up quickly, too quickly. Ideas?
From: Richard Sims <rbs AT BU DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 5 May 2005 12:20:00 -0400
John -

You need to check recent ANE summary stats or dsmaccnt records for
the clients and compare against past records, to see if there is
actually an increase in client activity. Examining numbers for the
server store inventory is rather pointless, as churn is what affects
the Recovery Log. That is, a client may, per retention policies,
always have 8 versions of a file in server storage, but if they're
now re-sending it in every backup, there you have transaction
activity and protracted Expirations.

This is a classic administration challenge, wherein you may need to
redistribute client backups over the day, or schedule incremental
backups of your db. You can also perform periodic session queries
from the server to see how backups are performing. And make sure your
DBBackuptrigger is nicely configured, to avoid an ugly server problem.

   Richard Sims

On May 5, 2005, at 10:58 AM, John C Dury wrote:

I have v5311 AIX server installed. The DB is not in roll forward mode.
There isn't anything that has changed recently that would be
causing this.
It seems it might be a  bug in v5311 that doesn't let the recovery log
empty as it happens sporadically. Expiration which runs daily is
suddenly
taking a much longer time to run also but also sporadically.   I
checked
the number of objects per node in the DB to see if any have
increased a
significant amount which would cause expiration to run longer, but
everything looks normal.  My recovery log is 12296 MB(90% full) and
my DB
is 56480 MB (38.3% full). Any clues on what is going on here? How
about a
way to empty the recovery log?
J.