1. I note you are backlevel. There are some known bugs which have been
fixed, relating to failing to reset the log pointer after an incremental
backup. Update yourself! Back when I had this problem, the circumvention
was to restart the server.
2. Consider carefully what the message and its help file are saying;
they are probably right. Now that the cost of a gigabyte of disk space
has dropped to way below the cost of a pint of beer, there is no reason
not to enlarge your log and raise your trigger as suggested in the help
file. How often do triggered backups occur? If it's more than daily,
you've got a log that wants to be larger. In any case, a 40% trigger
just sounds too low. Any trigger 50% or lower has the potential to
produce this message.
HOW TO CALCULATE THE TRIGGER: How much can possibly be added to the log
while a full database backup is underway? This will involve simply
watching the log max util number after each FULL backup. (Then reset it
with RESET LOGMAXUTILIZATION for next time.) Add a fudge factor and that
is how much less than 100% you should set the trigger.
There have been many debates here about whether or not rollforward is a
good idea. On a smaller system such as yours, rollforward works well, so
use it. On huge systems such as mine with its 50gb database, it does not
scale well, so I've stopped using it.
Back to your case, here's one quick way to calculate the fix for this.
Presently your log is 3gb, and the trigger is 40%. This means you are
keeping 1.8gb as a cushion for log use during a full backup. Leave that
at 1.8gb, while you double the log size to 6gb. 1.8gb is 30% of 6gb, so
set the trigger at 70% of a 6gb log, and you are still just as safe from
log fillups as before. This WILL work much more smoothly, and you will
not get these error messages.
It is also possible that your log is too large. If you had set the
trigger this low to force a backup to tape frequently enough for you to
feel safe, consider changing from triggered backups to scheduled
backups. (But, always leave a trigger set somewhere high just in case,
when in rollforward mode.)
Roger Deschner University of Illinois at Chicago rogerd AT uic DOT edu
Academic Computing & Communications Center
On Mon, 3 Mar 2003, Henrik Wahlstedt wrote:
>Good morning!
>
>First of all things.. I use 4.1.3.0 on w2k.
>Second, I have my log (3GB) in roll forward mode and use a dbbackup
>trigger which kicks off at log full percentage=40.
>I belived that an incremental dbbackup would lower my logs pct. utilized,
>but I might be wrong? After an incremantal dbbackup I get an anr4556.
>
>How high must I update my log full percentage to reset log pct.utilization?
>
>
>
>
>ANR4556W Attention: the database backup operation did not
> free sufficient recovery log space to lower utilization
> below the database backup trigger. The recovery log size
> may need to be increased.
>
>Help 4556,
>....
>User Response: If a database backup operation does not free up enough
>recovery log space to reset utilization below the database backup trigger,
>the recovery log needs to be extended or the database backup trigger
>updated
>to a higher log full percentage.
>
>
>
>-------------------------------------------------------------------
>The information contained in this message may be CONFIDENTIAL and is
>intended for the addressee only. Any unauthorised use, dissemination of the
>information or copying of this message is prohibited. If you are not the
>addressee, please notify the sender immediately by return e-mail and delete
>this message.
>Thank you.
>
|
