Preventing log fillups is a delicate balancing process, especially if you run in ROLLFORWARD mode.
But right now you're in a jam - you've got to extend your log, but you cannot because it is as large as it can be (13gb). Call Tivoli support. Then shrink your log back down to 12gb, so you can do an emergency log extention on the next Dark and Stormy Night. I no longer run in rollforward mode, but when I did I found that the idea was to prevent TRIGGERED FULL BACKUPS, at all cost. The issue here is that if you set the backuptrigger too high, the log will fill up while a full backup is underway. If you set it too low, you'll be running more incremental backups than you need to, wasting tapes, and working your way towards a full backup that much faster. My best strategy for doing this was, once a week, do a Scheduled Incremental Backup to empty the log, so it would last for the longer duration of a full backup, and then several hours later, do a Scheduled Full Backup. Then after that completes, let it do Triggered Incremental Backups again. Another strategy would be to watch the incremental counter, and when it is about to do a full backup next time, lower the trigger. Then raise it again after the full backup. What we really need here is two trigger levels - one for when the next backup will be incremental, and another for when the next backup will be full; you'd simply set the fulldbbackuptrigger lower than the incrementaldbbackuptrigger to achieve much safer operation. The underlying problem with rollforward mode and triggered backups is that inevitably it will pop the trigger and decide it wants to do a database backup at the worst possible time, like when you really need all your tape drives for migration. Murphy's Law is at work here. This will leave you with a Hobson's Choice between a full Log, or a full Disk Storage Pool - a dilema that can be very easily avoided by planning and scheduling. It is for this reason that, even though it sounds like a good idea, I have stopped running in rollforward mode. Normal mode makes it a lot easier to plan and schedule, especially with a large and growing database. (Yes, I mirror my database.) Roger Deschner University of Illinois at Chicago [EMAIL PROTECTED] On Tue, 4 Feb 2003, Stapleton, Mark wrote: >>From: Remeta, Mark [mailto:[EMAIL PROTECTED]] >>>Ok I have a serious problem. My log is full and I'm at the >>>maximum as far as size goes. When the server starts I get a >>>ANR7837S Internal Error LOGSEG871 detected. Does anyone know >>>how to get around this. The tsm server is running but >>>unacessable via the command interface... >> >From: Stapleton, Mark >>A preliminary search of http://search.adsm.org brought up this email: >> >>http://msgs.adsm.org/cgi-bin/get/adsm0203/1312/2.html > >You should also doing db backups more often if you're filling up a maxed >out recovery log. You might also consider setting logmode to normal to >avoid this. > >-- >Mark Stapleton ([EMAIL PROTECTED]) >
