Inspect your server activity log; there's probably better info, there --
like a tape mount request that didn't get satisfied within the "mount wait"
time on the device class of the storage pool your
management-class/copy-group points to. I've seen this happen where the
max-scratch was set too low, or the TDP node name was trying to use multiple
mount-points (when the node was registered for less than the request)...
WAD.
Also, most backup agents (via the API) have gotten smart enough to send the
estimated "glob" size, which can easily be used to send the data to the
nextstg pool (usually, tape). We set max-size on most disk pools, and we
use scratch tapes in the tape library (maxscr=9999, rather than pre-defined
volumes which cause mount request time-outs), so any file or "glob" greater
than max-size goes to the nextstg pool.
Don France
EDS Infrastructure Engineering
San Jose, CA
mailto:[EMAIL PROTECTED]
PACE - http://www.pacepros.com
Bus-Ph: (408) 257-3037
-----Original Message-----
From: Stefan Holzwarth [mailto:[EMAIL PROTECTED]]
Sent: Friday, June 22, 2001 2:41 AM
To: [EMAIL PROTECTED]
Subject: AW: Disk pool size vs large file
We use TSM 3.7.3.8 @MVS with several 3590-tapes shared with OS390.
Our biggest files are 30GB (Exchange) and normally went direct to tape
by setting a sizelimit to the diskstorage pool.
What happened last week was an incredible short backuptime of the exchange
node
without any error. Looking through the dsmsched.log I found :
06/21/2001 02:33:46 ANS1312E Server media mount not possible
(due to no tape free at this moment?)
The TSM Client skipped the file and finished with the following summary:
06/21/2001 02:33:46 --- SCHEDULEREC STATUS BEGIN
06/21/2001 02:33:46 Total number of objects inspected: 8,565
06/21/2001 02:33:46 Total number of objects backed up: 246
06/21/2001 02:33:46 Total number of objects updated: 0
06/21/2001 02:33:46 Total number of objects rebound: 0
06/21/2001 02:33:46 Total number of objects deleted: 0
06/21/2001 02:33:46 Total number of objects expired: 26
06/21/2001 02:33:46 Total number of objects failed: 0
06/21/2001 02:33:46 Total number of bytes transferred: 138.73 MB
06/21/2001 02:33:46 Data transfer time: 74.62 sec
06/21/2001 02:33:46 Network data transfer rate: 1,903.68 KB/sec
06/21/2001 02:33:46 Aggregate data transfer rate: 1,067.74 KB/sec
06/21/2001 02:33:46 Objects compressed by: 0%
06/21/2001 02:33:46 Elapsed processing time: 00:02:13
06/21/2001 02:33:46 --- SCHEDULEREC STATUS END
The eventlog shows no exception for this schedule.
IBM's comment: "Works as designed"
Now I consider to do the backup of large files to the primary storagepool on
disk, because its very difficult to detect this error. (error.log shows no
errors)
With Regards, Stefan Holzwarth
> -----Ursprüngliche Nachricht-----
> Von: Sam Schrage [mailto:[EMAIL PROTECTED]]
> Gesendet am: Donnerstag, 21. Juni 2001 20:15
> An: [EMAIL PROTECTED]
> Betreff: Disk pool size vs large file
>
> I have a 56GB disk pool with the next pool to tape. I have a
> user, DB2
> Admin, that wants to back up a 125GB DB2 backup. What's the
> best way to
> handle this one user? If he/she backs up the file will it
> crash the system
> because it's bigger that the diskpool, or will it go right to tape?
>
> Sam Schrage
> TRW Systems
> [EMAIL PROTECTED]
>
