Hi Zlatko! This is 'normal behavior'. When backups go to a 100% full diskpool TSM tries to allocate storage in the nextstgpool defined for your diskpool, which is probably your primary tapepool. So all backups are going to wait for mountpoint in the tapepool. That's why the client backups seem to 'hang'. Although migration kicks in and frees the diskpool, these clients will never switch back to the diskpool. You should always try to prevent a 100% full diskpool. I agree that this is not always possible, unless you have a very large one. I have run into this situation numerous times, which can result in very nasty problems (Oracle databases stop working, because the archive logfiles are not backed up). Kindest regards, Eric van Loon KLM Royal Dutch Airlines
-----Original Message----- From: Zlatko Krastev/ACIT [mailto:[EMAIL PROTECTED]] Sent: Monday, October 29, 2001 10:55 To: [EMAIL PROTECTED] Subject: Re: Spill processing please help - lowering LOWMIG On our test installation (TSM 4.1.4.1, AIX 4.3.3ML6) we've seen a strange behavior: 1. Client backups to disk pool 2. Migration starts after HIGHMIG limit is passed 3. Client fills the pool faster than migration frees it 4. Reaching disk pool 100% full client pauses indicating "waiting for mount of offline media" 5. Migration process commits a migration transaction freeing space in disk pool. Client does NOT resume. 6. Migration process finishes (it's a loooong process). Client wakes up and continues backup. 7. Administrator reduces disk pool deleting some volumes (to produce more pool fills) 8. Client fills the pool again and blocks 9. Migration finishes. Client again resumes. 8. ... 9. ... 8. ... 9. ... (many times) I do not know is this a bug in the release we are using or a feature of all releases but test this on your platform. If you lower significantly LOWMIG threshold and something like this happens you can see long waits and backup can go out the backup window. Zlatko Krastev IT Consultant Alan Davenport <[EMAIL PROTECTED]> on 26.10.2001 18:03:38 Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] cc: Subject: Re: Spill processing please help + -----Original Message----- + From: Doherty, John (ANFIS) [mailto:[EMAIL PROTECTED]] + Sent: Friday, October 26, 2001 10:21 AM + To: [EMAIL PROTECTED] + Subject: Re: Spill processing please help + + + Thanks Alan, this looks good. This is very similar to the + problem we have. + For example I run migration on our 3 disk pools to clear them + down at 18:00, + 21:00 and 22:00 respectively. they finish at 18:32, 21:30 and 22:30 + respectively. Can I assume any migration after 22:30 would + indicate spill + processing is occurring ?? Yes, that is exactly what I was trying to say. Any migration that you didn't trigger yourself is due to your pool hitting the HIGHMIGPCT limit. If your pool is filling up too often here is a little trick you may want to try. Set your LOW migration threshold to 10% or so but leave your high migration threshold at 90%. If tape contention with other users is not an issue this will nearly empty the pool if any unscheduled migration is to occur. (Setting low migration to ZERO during the backup window is not recommended because as SOON as a file hits the disc pool it will migrate causing lots of tape mounts!) + + Also I may utilize the 1 GB file limit, but I assume that + every time a file + is greater than 1 GB then a tape mount would be requested ??? Yes, it will. But if you are using collocation like I am the amount of tape mounts will be much less for the over sized files than if triggered migration were to occur. Setting a max file size on the disc pool is one way of reducing the frequency of triggered migration. In a perfect world our disc pools would be large enough to hold everything from a backup window but we all know that's not always possible. I'm afraid the DASD Czar would come after me with sharp objects if I were to try to get any more packs this month. (: Take care, Al Alan Davenport Senior Storage Administrator Selective Insurance [EMAIL PROTECTED] (973)948-1306 ********************************************************************** This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. **********************************************************************
