You discovered my miracle cure for my problem! I was able to extend the log
another 72mb and get the server up. After it was up I changed the log mode
to normal and the server was as happy as a pig in mud! I think I'm sticking
with normal mode too for the time being anyway! Thanks for the response.
Mark
-----Original Message-----
From: Roger Deschner [mailto:rogerd AT UIC DOT EDU]
Sent: Wednesday, February 05, 2003 6:48 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Over extended log
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 rogerd AT uic DOT edu
On Tue, 4 Feb 2003, Stapleton, Mark wrote:
>>From: Remeta, Mark [mailto:MRemeta AT SELIGMANDATA DOT COM]
>>>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 (stapleton AT berbee DOT com)
>
Confidentiality Note: The information transmitted is intended only for the
person or entity to whom or which it is addressed and may contain
confidential and/or privileged material. Any review, retransmission,
dissemination or other use of this information by persons or entities other
than the intended recipient is prohibited. If you receive this in error,
please delete this material immediately.
|
