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:[email protected]] On Behalf Of Steven Harris Sent: Saturday, December 22, 2012 1:39 AM To: [email protected] 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
