|
Re: [ADSM-L] TDP for SQL gui takes 20 min to display inactive
2012-12-28 11:59:12
Hi, Steve. If restoring a file takes multiple small volumes in one
pool, but only one large volume in another pool, TSM will choose the
pool with the fewest volumes/mounts required, even if the smaller
volumes are significantly faster. This causes some problems with
restores choosing real tape over small file or VTL volumes. Well, I say
that as if it's fact, but while I haven't seen that documented anywhere,
that's what I've observed. I've also received hearsay confirmation from
various IBM sources that it is this way. YMMV :-) I think this might
have been addressed with the libtype=vtl, and I'd like to see
confirmation on that, but that wouldn't help you much with file class
volumes.
I recommend you check your actlog for the sessions in question to see if
they've been getting tape mounts during restores. If so, try setting
your copypool unavailable to see if that alleviates the problem.
update stgpool copypool access=unavailable
The other question is, why would the copypool volumes still be
available? Is this only happening in the window between "backup
stgpool" and "move drmedia"?
On 12/27/2012 5:36 AM, Schaub, Steve wrote:
Thanks, Steve.
I checked, and the node does have backdel=y. it almost acts like it is going
to the copypool rather than the diskpool for the meta data, but that makes no
sense.
-steve s
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Steven Harris
Sent: Saturday, December 22, 2012 1:39 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] TDP for SQL gui takes 20 min to display inactive
Hi Steve.
Check to make sure that the node has backdel=yes specified. I had one SQL
server that was on a legal hold for 4 years and the restore screen took that
long to come up because of the large number of objects. If backdel is set to
no, the logs won't be getting deleted and that may account for the large number
of objects you are seeing.
Regards
Steve
Steven Harris
TSM Admin
Canberra Australia.
On 22/12/2012 12:26 AM, Schaub, Steve wrote:
Tsm server 6.2.4.0
Tsm client 6.2.3.0
Tdp client 6.3.0.1
Windows 2003EE x64
Our DBA's are complaining that when they have to use the TDP gui to restore older
databases by selecting "active/inactive", it sometimes takes 20+ minutes for
the list of databases to refresh.
My first suspicion was that the meta data had somehow gotten off to tape, but I
have confirmed the primary data is all on disk (ST03_DISK_P04), only copypool
(ST03_TAPE_C04) is on tape.
Any ideas what would cause this behavior?
tsm: TSMBCP01>q occ archer_sql ARCHER\COMPOUND\meta*
Node Name Type Filespace FSID Storage Number of Physical Logical
Name Pool Name Files Space Space
Occupied Occupied
(MB) (MB)
---------- ---- ---------- ----- ---------- --------- --------- ---------
ARCHER_SQL Bkup ARCHER\CO- 12 ST03_DISK- 142,148 555.27 662.44
MPOUND\m- _P04
eta\0000
ARCHER_SQL Bkup ARCHER\CO- 12 ST03_TAPE- 141,452 374.17 374.17
MPOUND\m- _C04
eta\0000
tsm: TSMBCP01>q stg st03_disk_p04
Storage Device Estimated Pct Pct High Low Next Stora-
Pool Name Class Name Capacity Util Migr Mig Mig ge Pool
Pct Pct
----------- ---------- ---------- ----- ----- ---- --- -----------
ST03_DISK_- DISK 100 G 2.5 2.5 70 50 ST03_TAPE_-
P04 P04
Steve Schaub
Systems Engineer II, Windows Backup/Recovery BlueCross BlueShield of
Tennessee
-----------------------------------------------------
Please see the following link for the BlueCross BlueShield of
Tennessee E-mail disclaimer:
http://www.bcbst.com/email_disclaimer.shtm
-----------------------------------------------------
Please see the following link for the BlueCross BlueShield of Tennessee E-mail
disclaimer: http://www.bcbst.com/email_disclaimer.shtm
|
|
|
