Paul,
Thanks, I see what you mean about expire inventory - and we do have a
vulnerability there. Right from the start we have done expiration on a
Saturday (and it finishes then too now - wheras it used to last until
Monday (so some things have got better!), and without any scheduled
sessions o
At 11:46 AM 6/5/2001 +0100, Sheelagh Treweek wrote:
>What I think you are saying is that for the log (in roll-forward)
>to fill implies that the head has circled round to catch up the
>tail because a transaction is still uncompleted? Some of the
>examples you cite are very clear and plausible : a
Paul,
Thankyou for the excellent write-up of your understanding of how
the recovery log works and what steps you take to avoid a pinned
logtail.
What I think you are saying is that for the log (in roll-forward)
to fill implies that the head has circled round to catch up the
tail because a transa
> Thanks Paul, this is very useful into.
5. We have a monitor that checks the log utilization every 5 minutes (among
other things). If the log utilization gets above 82%, the monitor sends
pager alerts to the TSM oncall staff. The oncall staff then logs on to the
server to try to identify
} expire inventory
fi
fi
Jeff Bach
Home Office Open Systems Engineering
Wal-Mart Stores, Inc.
WAL-MART CONFIDENTIAL
-Original Message-
From: Paul Zarnowski [SMTP:[EMAIL PROTECTED]]
Sent: Monday, June 04, 2001 10:03 AM
To: [EMAIL PROTECTED]
it was suggested
>I put in a design change request (so it must be working as designed now).
>
>Regards, Sheelagh
>--
>
> >X-Sender: [EMAIL PROTECTED] (Unverified)
> >Mime-Version: 1.0
> >Date: Thu, 31 May 2001 12:19:33 -0400
> >From: Paul Zarnowski <[EMAIL P
Paul Zarnowski <[EMAIL PROTECTED]>
>Subject: Re: Recovery log utilization does not drop after DB backup
>To: [EMAIL PROTECTED]
>
>We run into this problem a lot. I believe there are a couple of issues
>here. One issue, that Gerhard mentioned, is that the log utilization does
>
We run into this problem a lot. I believe there are a couple of issues
here. One issue, that Gerhard mentioned, is that the log utilization does
not drop quickly when the db backup apparently finishes. The other issue
is that a thread can have the log "pinned", preventing the log utilization
fr
If the log utilization gets to 100%, it will not only shut down sessions, it
will crash the server.
-Original Message-
From: Suad Musovich [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 30, 2001 2:29 AM
To: [EMAIL PROTECTED]
Subject: Re: Recovery log utilization does not drop after DB
When your recovery log hits 100%, basically one of two things happens.
1. If there is "Available Space" greater than "Assigned Capacity" then log will
acquire some of this additional space.
2. When all space is consumed - TSM server crashes! I have had this happen with
3.7.4.0 server on AIX
This problem can also be eliminated by performing a
full DB backup daily which I've always done and if the
environment is very large with a lot of activity you
can perform incremental DB backups with the DB trigger
option throughout the day.
Thanks,
Angela
--- David Longo <[EMAIL PROTECTED]> wrot
: Suad Musovich [SMTP:[EMAIL PROTECTED]]
Sent: Wednesday, May 30, 2001 1:29 AM
To: [EMAIL PROTECTED]
Subject:Re: Recovery log utilization does not drop after DB
backup
> some time ago I complained in a mail to this list that the
recovery
> some time ago I complained in a mail to this list that the recovery log
> utilization is not reset after a database backup. APAR IC30181 was generated
> for this problem. Its status is "open".
I complained about the problem too. The response I got was, when the system was
too busy it took a whi
Hi,
some time ago I complained in a mail to this list that the recovery log
utilization is not reset after a database backup. APAR IC30181 was generated
for this problem. Its status is "open".
Best regards
Gerhard
---
Gerhard Rentschleremail:[EMAIL PROTECTED]
Regional Computing Center
14 matches
Mail list logo
