ADSM-L

Re: Recover log at 5120MB and full - Cannot start TSM

2001-12-19 00:35:24
Subject: Re: Recover log at 5120MB and full - Cannot start TSM
From: Pothula S Paparao <9pothula AT SG.IBM DOT COM>
Date: Wed, 19 Dec 2001 13:32:31 +0800
Hi,
here is some stuff.
i had a big problem couple of months ago. TSM server crashes at every
alternate day. this is due to db2 backup pinning the log tail. To overcome
this,I have changed my policy definitions to backup the database (db2)
directly to tape pool instead of migrating database objects from disk_pool
to tape_pool. Observed that the log is not filling beyond 12%. Log size
assigned is 4.9GB. backingup TSM DB (full ) twice a day. running expiration
and reclamation mannullay using crontab (to see that expiration or
reclamation may not pin log during backup).  I also have written a small
script which gives me a page alert whenever log reaches to 60% and above.

regards
sreekumar



                    Jeff Bach
                    <jdbach@WAL-MA       To:     ADSM-L AT VM.MARIST DOT EDU
                    RT.COM>              cc:
                    Sent by:             Subject:     Re: Recover log at 5120MB 
and full - Cannot start TSM
                    "ADSM: Dist
                    Stor Manager"
                    <ADSM-L AT VM DOT MAR
                    IST.EDU>


                    12/19/2001
                    01:02
                    Please respond
                    to "ADSM: Dist
                    Stor Manager"





Andy,

        This is not actually the oldest session, but the oldest uncommitted
transaction.  See page 29 of the document this link goes to for a better
explanation.  This is the same as happens to a SQL database, or others.

        http://www.share.org/proceedings/sh97/data/S5726.PDF
<http://www.share.org/proceedings/sh97/data/S5726.PDF>

Thanks for the link Paul Seay

Jeff Bach
Home Office Open Systems Engineering
Wal-Mart Stores, Inc.

WAL-MART CONFIDENTIAL


        -----Original Message-----
        From:   Andy Carlson [SMTP:andyc AT ANDYC.CARENET DOT ORG]
        Sent:   Tuesday, December 18, 2001 10:11 AM
        To:     ADSM-L AT VM.MARIST DOT EDU
        Subject:        Re: Recover log at 5120MB and full - Cannot start
TSM

        The other thing that has bitten us, is not the number of sessions,
but
        the oldest session.  We have had backup sessions running 10 hours
or
        more, pinning log data.  This pinned log data does not allow the
log
to
        shrink, even if you perform a database backup.

        Andy Carlson                             |\      _,,,---,,_
        andyc AT andyc.carenet DOT org            ZZZzz /,`.-'`'    -.  ;-;;,_
        BJC Health System                       |,4-  ) )-,_. ,\ (  `'-'
        St. Louis, Missouri                    '---''(_/--'  `-'\_)
        Cat Pics: http://andyc.dyndns.org/animal.html

        On Tue, 18 Dec 2001, Malbrough, Demetrius wrote:

        > One tip, John!
        >
        > Reset the LOGMAXUTILIZATION (RESet LOGMaxutilization) every day
        > to monitor the maximun utilization vs. the current utilization.
        > Set up a SCRIPT or ADMIN SCHEDULE to run a 'q session' & 'q
process'
        > every 30 mins at night during your backup window to see what &
how
        > many sessions/processes are running simultaneously.
        >
        > This is because the size of the recovery log depends on the # of
        > concurrent client sessions & the number of background processes
        > executing on the server.
        >
        > Also, check the MAXSESSIONS option & to make sure it is not set
too high!
        >
        > Regards,
        >
        > Demetrius Malbrough
        > UNIX/TSM administrator
        >
        > -----Original Message-----
        > From: Talafous, John G. [mailto:Talafous AT TIMKEN DOT COM]
        > Sent: Tuesday, December 18, 2001 8:51 AM
        > To: ADSM-L AT VM.MARIST DOT EDU
        > Subject: Re: Recover log at 5120MB and full - Cannot start TSM
        >
        >
        > Thanks to all who responded and helped get our server back up and
running.
        > Now comes the task of figuring out what caused the recovery log
to
fill up
        > in the first place and prevent it from happening again.  Does
anyone have
        > any tips and tricks on determining what/who is using recovery log
space?
        >
        > TIA,
        > John G. Talafous              IS Technical Principal
        > The Timken Company            Global Software Support
        > P.O. Box 6927                 Data Management
        > 1835 Dueber Ave. S.W.         Phone: (330)-471-3390
        > Canton, Ohio USA  44706-0927  Fax  : (330)-471-4034
        > talafous AT timken DOT com           http://www.timken.com
        >
        >
        > -----Original Message-----
        > From: Nancy Reeves [mailto:Nancy.Reeves AT WICHITA DOT EDU]
        > Sent: Monday, December 17, 2001 2:56 PM
        > To: ADSM-L AT vm.marist DOT edu
        > Subject: Re: Recover log at 5120MB and full - Cannot start TSM
        >
        >
        > Here is what I do when the recovery log fills, also on AIX. My
notes agree
        > with the person who said that the Extend size has to be a
multiple
of 4
        > and 1 less than the DSMFMT size. (What the other person said
about
max
        > size being 5G, might cause this to not work, though.)
        >
        > If server will not start because the recovery log is full:
        >   1) Find a location for an extra recovery log file
        >   2) DSMFMT -LOG <fullfn> <size1> -- where size1 = 4x+1, where x
=> 2
        >   3) DSMSERV EXTEND LOG <fullfn> <size2> -- where size2 = size1-1
        >   4) DSMSERV -- to start the server normally
        >   5) Solve the problem that caused the recovery log to fill.
        >   6) After the server is up, either create a mirror for this
recovery log
        > or preferably remove it from use.
        >
        > Nancy Reeves
        > Technical Support, Wichita State University
        > Nancy.Reeves AT wichita DOT edu          316-978-3860
        >
        >
        >
**********************************************************************
        > This message and any attachments are intended for the
        > individual or entity named above. If you are not the intended
        > recipient, please do not read, copy, use or disclose this
        > communication to others; also please notify the sender by
        > replying to this message, and then delete it from your system.
        >
        > The Timken Company
        >
**********************************************************************
        >


**********************************************************************
This email and any files transmitted with it are confidential
and intended solely for the individual or entity to
whom they are addressed.  If you have received this email
in error destroy it immediately.
**********************************************************************