After this switching between copy pool and primary pool, I changed the mount
retention on the device classes affected. This speeded up the restore and
ended the constant mount and dismount of the same tape volumes over and over
and over again.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Rick Saylor
Sent: Wednesday, February 04, 2015 7:28 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Availability of 7.1.1.200 server code
In our case the restore time increased substantially(2-3hours to >8
hours) but eventually finished. TSM seemed to prefer the copypool
data that was stored on virtual volumes on a remote TSM server. So,
this also increased network usage by quite a bit. Oddly, TSM would
mount the correct primary volume but not use it and immediately look
for a copypool volume. Also, our primary pool volume are colocated
but copypool volumes aren't. This had the effect of mounting many
more volumes than necessary on both the local and remote TSM servers.
If the copypool volumes aren't available then the restore did use the
primary pool volumes. But like you said how often do you get advanced
warning of restores? So, if you can wait, then install 7.1.1.200 when
it is released. However, if you have to upgrade for some reason, then
call IBM for the efix.
Rick Saylor
Austin Community College
At 08:27 AM 2/4/2015, you wrote:
>When the mounting of both primary and copypool volumes occurs, does
>the restore run successfully anyway, even if the copypool is nor
>marked Unavailable? Is the mounting of both primary pool and
>copypool volumes just a waste of tape drives, or does it crash the
>restore or export? Our client admins run their own restores. We are
>rarely notified before one is submitted.
>
>If additional bad effects happen, please describe them. I may be
>misisng the obvious.
>
>One of our TSM admins is going to retire later this year. We are
>being urged to upgrade the TSM servers to a stable version of 7.x
>before that happens. If I present the APAR in 7.1.1.100 to
>management as a reson to delay the upgrade, I will be asked what
>harm is caused by it. Again, client admins run their own restores,
>so we cannot take preemptive action to prevent undesirable side-effects.
>
>With many thanks,
>Keith Arbogast
>Indiana University
>
>
|