ADSM-L

Re: UNLOAD/RELOAD DB

2003-04-09 11:57:15
Subject: Re: UNLOAD/RELOAD DB
From: bbullock <bbullock AT MICRON DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 9 Apr 2003 09:56:45 -0600
        True, if your expire inventory is not working, things get ugly very 
quickly.

        I believe her question was that she is running expiration with the 
"duration=" option. She believes that this is keeping her expire inventory from 
running to completion. I'm saying that running "expire inventory duration=" 
will not keep the expire inventory from running to completion, but it may take 
multiple days to go through one complete cycle of the database.

        If she's not sure if the expire inventory process is getting completely 
through the TSM database, here's what she can do.

        - Run "q auditocc". The order that the nodes are listed is the same 
order that the TSM "expire inventory" will expire data.

        - Run "q act sear=anr4391". The output will show you how the expire 
inventory is progressing and which node it is currently on. (you may need to 
put a "-begint=" on the command if it is processing a large filespace.

        Put the data from these 2 commands together (and going back multiple 
days in the activity log) and she track the progress of the expire inventory 
and can see if the whole DB is getting processed or if it is getting stuck 
somewhere.

Ben


-----Original Message-----
From: Rushforth, Tim [mailto:TRushforth AT WINNIPEG DOT CA]
Sent: Wednesday, April 09, 2003 9:32 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: UNLOAD/RELOAD DB


Sure it could be the problem!  If expiration is never finishing it is not
expiring objects that will lead to DB growth.

Try expire inventory skipdirs=yes  or as others have mentioned - upgrade.
We just upgraded from 4.2.0 to 5.1.6.1 and expiration flies now.  We had
times where it ran for days at a time (with skipdirs it would get past those
quickly but we would run a normal expiration after that.)

-----Original Message-----
From: bbullock [mailto:bbullock AT MICRON DOT COM]
Sent: Wednesday, April 09, 2003 10:26 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: UNLOAD/RELOAD DB


        No, that should not be the problem. If you cancel the expire
inventory, the next time you run the expire, it will start at the place it
left off.

        I believe that in older versions of TSM, the "can proc", the "cancel
expiration" and " duration=??" gave different results. If you killed the
expiration process in some ways, it would start at the beginning of the
inventory rather than at the place it left off.

        At version 5, I have done it various ways, and they all seem to
restart the expire inventory at the place where it left off.

Ben


-----Original Message-----
From: Joni Moyer [mailto:joni.moyer AT HIGHMARK DOT COM]
Sent: Wednesday, April 09, 2003 9:10 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: UNLOAD/RELOAD DB


Another of my problems is that expiration hasn't been able to run from
beginning to end, I set a duration of approximately 7 hours.  Could this
also be causing performance/DB growth?  Thanks!

Available Space (MB): 60,456
        Assigned Capacity (MB): 60,456
        Maximum Extension (MB): 0
        Maximum Reduction (MB): 8,044
             Page Size (bytes): 4,096
            Total Usable Pages: 15,476,736
                    Used Pages: 12,913,875
                      Pct Util: 83.4
                 Max. Pct Util: 83.5
              Physical Volumes: 26
             Buffer Pool Pages: 24,576
         Total Buffer Requests: 4,229,185
                Cache Hit Pct.: 98.30
               Cache Wait Pct.: 0.00
           Backup in Progress?: No
    Type of Backup In Progress:
  Incrementals Since Last Full: 9
Changed Since Last Backup (MB): 149.34
            Percentage Changed: 0.30
Last Complete Backup Date/Time: 04/09/2003 09:32:43


Joni Moyer
Systems Programmer
joni.moyer AT highmark DOT com
(717)975-8338



                      "Loon, E.J. van -
                      SPLXM"                   To:
ADSM-L AT VM.MARIST DOT EDU
                      <Eric-van.Loon@KL        cc:
                      M.COM>                   Subject:  Re: UNLOAD/RELOAD
DB
                      Sent by: "ADSM:
                      Dist Stor
                      Manager"
                      <[email protected]
                      .EDU>


                      04/09/2003 09:54
                      AM
                      Please respond to
                      "ADSM: Dist Stor
                      Manager"






Hi Joni!
Please send us the output form the command q db f=d so we can calculate if
your database indeed is heavily fragmented.
I haven't done a unload/load myself but I read some stories in this list:
it
can be a rather lengthy process
Kindest regards,
Eric van Loon
KLM Royal Dutch Airlines

-----Original Message-----
From: Joni Moyer [mailto:joni.moyer AT HIGHMARK DOT COM]
Sent: Wednesday, April 09, 2003 14:22
To: ADSM-L AT VM.MARIST DOT EDU
Subject: UNLOAD/RELOAD DB


Hello All!

I was talking to TSM support yesterday about several issues concerning
expiration and the tsm database in my environment.  I am on 4.1.5 on os/390
2.10 and I have a db that is 60GB with 83% utilized.  It was suggested to
try to unloaddb and reload it, but I have been receiving mixed
feelings/messages from many users and co-workers.  If anyone has done this
process, what are the pros/cons?   Does this help with DB growth and
performance?  I would appreciate any opinions or suggestions you may have!
Thank you in advance!

Joni Moyer
Systems Programmer
joni.moyer AT highmark DOT com
(717)975-8338


**********************************************************************
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain confidential
and privileged material intended for the addressee only. If you are not the
addressee, you are notified that no part of the e-mail or any attachment
may be disclosed, copied or distributed, and that any other action related
to this e-mail or attachment is strictly prohibited, and may be unlawful.
If you have received this e-mail by error, please notify the sender
immediately by return e-mail, and delete this message. Koninklijke
Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees
shall not be liable for the incorrect or incomplete transmission of this
e-mail or any attachments, nor responsible for any delay in receipt.
**********************************************************************

<Prev in Thread] Current Thread [Next in Thread>