Why are you putting a 28GB database backup to a VTS? This is not a good use of the VTS. I can see the length of the backup just knowing how the VTS works internally. Your data is going to a 'cache' area in the VTS which is DISK. When you hit the end-of-voloume on a 3490 tape (logically as there is no real tape), the VTS assigns more are of the cache for the volume. If there isn't room and the cache is full, then through a LRU algorithm old data is purged off the cache. If that data hasn't been staged to 'real' 3590 tape volumes, you wait for that to happen. Depending on how large this cache disk area in in your VTS, you're probably filling a large portion of that just with your DB backup. Plus the data you send into the VTS needs to be staged to real 3590 volumes.
The VTS is good for smaller amounts of data, just a couple volumes worth of 3490 size that is mostly written once and then read. Appending to a virtual tape volume is not very effecient as the data needs to be re-staged back to cache (if it's not there already), data appended and then staged back to real tape, but in a different place. The original location of the data on the real 3590 is now invalid. You can see that you have both a performance hit while your data is staged back to cache, plus if you do a lot of appending, you're fragmenting the real 3590 volumes. The internal operation of the VTS is actually a form of TSM to handle the data migration from cache to tape, recalls and reclamation of the tape volumes when a threshold is reached. TSM, HSM and applications that like to completely fill a tape volume are not good candidates for a VTS. There's also the offsite vaulting out of a VTS to deal with... Bill Boyer DSS, Inc. -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Zoltan Forray/AC/VCU Sent: Tuesday, April 16, 2002 9:44 AM To: [EMAIL PROTECTED] Subject: Re: TSM DB Fullbackup 19GB takes 4 hours on OS/390 VTS FYI, I just checked my last full DB backup. Available Space (MB): 30,472 Assigned Capacity (MB): 28,128 Maximum Extension (MB): 2,344 Maximum Reduction (MB): 6,240 Page Size (bytes): 4,096 Total Usable Pages: 7,200,768 Used Pages: 4,846,635 Pct Util: 67.3 Max. Pct Util: 69.5 Physical Volumes: 13 If I do the backup to a fast 3590 drive/tape, it takes a little more than 1-hour and 1-tape. However, going to a 3490, it takes more that 3-hours and 13+ tapes. This is to a 3494 ATL. No VTS. ---------------------------------------------------------------------------- ------------------------ Zoltan Forray Virginia Commonwealth University - University Computing Center e-mail: [EMAIL PROTECTED] - voice: 804-828-4807 Schaub Joachim Paul ABX-PROD-ZH <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> 04/12/2002 04:48 AM Please respond to "ADSM: Dist Stor Manager" To: [EMAIL PROTECTED] cc: Subject: TSM DB Fullbackup 19GB takes 4 hours on OS/390 VTS Dear *SM Gurus The TSM DB Fullbackup (19GB) takes about 4 hours on OS/390 with VTS. I haven't found any descriptions for parallelisation, eg. maxpr or mountp. Is it in the tec. nature, the DB will be backed up in sequenz? tia Joachim ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Joachim Paul Schaub Abraxas Informatik AG Beckenhofstrasse 23 CH-8090 Z|rich Schweiz / Switzerland Telefon: +41 (01) 259 34 41 Telefax: +41 (01) 259 42 82 E-Mail: mailto:[EMAIL PROTECTED] Internet: http://www.abraxas.ch ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
