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 [EMAIL PROTECTED] 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. >