Re: Migration did not occur
Out of curiosity where does a *sm db backup fall in. I've seen some processes preempted by a db backup before. -Original Message- From: Sam Moore [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 07, 2001 2:55 PM To: [EMAIL PROTECTED] Subject: Re: Migration did not occur Restore is at the top of the list, then migration and reclamation Sam Moore [EMAIL PROTECTED] Information Services 716 888-3683 >>> [EMAIL PROTECTED] 2/7/01 5:00:00 AM >>> Hello ADSM co-workers I am running ADSM 3.1.2.2 on a NSM C00. We have a disk storage pool called INCDISK with the high threshold set to 70 and the low set to 30. Our main clients are SQL servers. All clients backup to the SQLFLAT backup copy group which is tied to the INCDISK storage pool. The INCDISK storage pool will migrate to the INCTAPE storage pool when necessary. The issue that I have observed is that when the %utilised went over the 70% high threshold then migration did not kick in. I waited until the %utilised reached 92% and still migration did not occur. Query mount showed all drives had tapes mounted, but when I queried the activity log to try and understand what had mounted these volumes I could not come to and solid conclusion. However I do suspect that restore operations where the culprit. This was further backed up by entries informing me that earlier migration processes had been pre-empted. I eventually dismounted the volumes half expecting migration to kick in, but it didn't. I eventually got migration to work by lowering both thresholds to 0. What I am not too sure about is whether migration is actually pre-empted by a restore operation. If this is the case then surly this is wrong. Surely migration is more important as this is the safety valve before the storage pool reaches 100%. Does anybody know the order of precedence for pre-emption? Can anybody confirm or add to me conclusions. Thanks for your time. Neil Sharp Merrill Lynch ADSM/TSM Administrator Work : 020-7573-0469 Mobile : 07769-741612 Pager : 01893-038277 e-mail : [EMAIL PROTECTED]
Re: Migration did not occur
Restore is at the top of the list, then migration and reclamation Sam Moore [EMAIL PROTECTED] Information Services 716 888-3683 >>> [EMAIL PROTECTED] 2/7/01 5:00:00 AM >>> Hello ADSM co-workers I am running ADSM 3.1.2.2 on a NSM C00. We have a disk storage pool called INCDISK with the high threshold set to 70 and the low set to 30. Our main clients are SQL servers. All clients backup to the SQLFLAT backup copy group which is tied to the INCDISK storage pool. The INCDISK storage pool will migrate to the INCTAPE storage pool when necessary. The issue that I have observed is that when the %utilised went over the 70% high threshold then migration did not kick in. I waited until the %utilised reached 92% and still migration did not occur. Query mount showed all drives had tapes mounted, but when I queried the activity log to try and understand what had mounted these volumes I could not come to and solid conclusion. However I do suspect that restore operations where the culprit. This was further backed up by entries informing me that earlier migration processes had been pre-empted. I eventually dismounted the volumes half expecting migration to kick in, but it didn't. I eventually got migration to work by lowering both thresholds to 0. What I am not too sure about is whether migration is actually pre-empted by a restore operation. If this is the case then surly this is wrong. Surely migration is more important as this is the safety valve before the storage pool reaches 100%. Does anybody know the order of precedence for pre-emption? Can anybody confirm or add to me conclusions. Thanks for your time. Neil Sharp Merrill Lynch ADSM/TSM Administrator Work : 020-7573-0469 Mobile : 07769-741612 Pager : 01893-038277 e-mail : [EMAIL PROTECTED]
Re: Migration did not occur
> The issue that I have observed is that when the %utilised went over the > 70% high threshold then migration did not kick in. Neil - Per the Admin Guide manual: "Pct Migr Specifies the percentage of data in each storge pool that can be migrated. This value is used to determine when to start or stop migration." Have a look at that value for your storage pool, rather than Pct Util. The Admin Guide explains the distinction between the values. Richard Sims, BU
Re: Migration did not occur
Thanks for your comments Joerg Yes we did have enough scratch tapes available at the time and yes we did have a next migration storage pool. Even though migration threshold exceeded 70% query process did not show any migration occurring. Definitely a weird one. Thanks for your help > -Original Message- > From: Joerg Nouvertne [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, February 07, 2001 12:01 PM > To: [EMAIL PROTECTED] > Subject: Re: Migration did not occur > > On Wednesday 07 February 2001 11:00, you wrote: > > Hello ADSM co-workers > > Hello Neil, > > > I am running ADSM 3.1.2.2 on a NSM C00. We have a disk storage pool > called > > INCDISK with the high threshold set to 70 and the low set to 30. Our > main > > clients are SQL servers. All clients backup to the SQLFLAT backup copy > > group which is tied to the INCDISK storage pool. The INCDISK storage > pool > > will migrate to the INCTAPE storage pool when necessary. > > > > The issue that I have observed is that when the %utilised went over the > 70% > > high threshold then migration did not kick in. I waited until the > %utilised > > reached 92% and still migration did not occur. Query mount showed all > > drives had tapes mounted, but when I queried the activity log to try and > > understand what had mounted these volumes I could not come to and solid > > conclusion. > > What is the activity log telling you? Maybe you should lower the HI > migration > threshold to force migration and have a look to the actlog afterwards. > Possible reasons why the migration does not kick in are e.g. Not enough > scratch tapes available in the destination pool, no migration pool at all, > etc. > > > However I do suspect that restore operations where the culprit. > > This was further backed up by entries informing me that earlier > migration > > processes had been pre-empted. I eventually dismounted the volumes half > > expecting migration to kick in, but it didn't. > > Even if all tape drives are in use by other processes, migration should > kick > in, but would wait for a mount device, and you should see it in the > process > list. > > > I eventually got migration > > to work by lowering both thresholds to 0. > > This would force it. You can also move the data manually via "move data > DISKPOOL stgpool=MIGRATIONPOOL wait=no". > > > > > What I am not too sure about is whether migration is actually pre-empted > by > > a restore operation. If this is the case then surly this is wrong. > Surely > > migration is more important as this is the safety valve before the > storage > > pool reaches 100%. Does anybody know the order of precedence for > > pre-emption? > > > > Can anybody confirm or add to me conclusions. Thanks for your time. > > > > Neil Sharp > > Merrill Lynch ADSM/TSM Administrator > > Work : 020-7573-0469 > > Mobile : 07769-741612 > > Pager : 01893-038277 > > e-mail : [EMAIL PROTECTED] > > Regards > > -- > Joerg Nouvertne > ... who still runs ADSM 3.1, but who will take the new adventure TSM 4.1 > soon.
Re: Migration did not occur
On Wednesday 07 February 2001 11:00, you wrote: > Hello ADSM co-workers Hello Neil, > I am running ADSM 3.1.2.2 on a NSM C00. We have a disk storage pool called > INCDISK with the high threshold set to 70 and the low set to 30. Our main > clients are SQL servers. All clients backup to the SQLFLAT backup copy > group which is tied to the INCDISK storage pool. The INCDISK storage pool > will migrate to the INCTAPE storage pool when necessary. > > The issue that I have observed is that when the %utilised went over the 70% > high threshold then migration did not kick in. I waited until the %utilised > reached 92% and still migration did not occur. Query mount showed all > drives had tapes mounted, but when I queried the activity log to try and > understand what had mounted these volumes I could not come to and solid > conclusion. What is the activity log telling you? Maybe you should lower the HI migration threshold to force migration and have a look to the actlog afterwards. Possible reasons why the migration does not kick in are e.g. Not enough scratch tapes available in the destination pool, no migration pool at all, etc. > However I do suspect that restore operations where the culprit. > This was further backed up by entries informing me that earlier migration > processes had been pre-empted. I eventually dismounted the volumes half > expecting migration to kick in, but it didn't. Even if all tape drives are in use by other processes, migration should kick in, but would wait for a mount device, and you should see it in the process list. > I eventually got migration > to work by lowering both thresholds to 0. This would force it. You can also move the data manually via "move data DISKPOOL stgpool=MIGRATIONPOOL wait=no". > > What I am not too sure about is whether migration is actually pre-empted by > a restore operation. If this is the case then surly this is wrong. Surely > migration is more important as this is the safety valve before the storage > pool reaches 100%. Does anybody know the order of precedence for > pre-emption? > > Can anybody confirm or add to me conclusions. Thanks for your time. > > Neil Sharp > Merrill Lynch ADSM/TSM Administrator > Work : 020-7573-0469 > Mobile : 07769-741612 > Pager : 01893-038277 > e-mail : [EMAIL PROTECTED] Regards -- Joerg Nouvertne ... who still runs ADSM 3.1, but who will take the new adventure TSM 4.1 soon.
Migration did not occur
Hello ADSM co-workers I am running ADSM 3.1.2.2 on a NSM C00. We have a disk storage pool called INCDISK with the high threshold set to 70 and the low set to 30. Our main clients are SQL servers. All clients backup to the SQLFLAT backup copy group which is tied to the INCDISK storage pool. The INCDISK storage pool will migrate to the INCTAPE storage pool when necessary. The issue that I have observed is that when the %utilised went over the 70% high threshold then migration did not kick in. I waited until the %utilised reached 92% and still migration did not occur. Query mount showed all drives had tapes mounted, but when I queried the activity log to try and understand what had mounted these volumes I could not come to and solid conclusion. However I do suspect that restore operations where the culprit. This was further backed up by entries informing me that earlier migration processes had been pre-empted. I eventually dismounted the volumes half expecting migration to kick in, but it didn't. I eventually got migration to work by lowering both thresholds to 0. What I am not too sure about is whether migration is actually pre-empted by a restore operation. If this is the case then surly this is wrong. Surely migration is more important as this is the safety valve before the storage pool reaches 100%. Does anybody know the order of precedence for pre-emption? Can anybody confirm or add to me conclusions. Thanks for your time. Neil Sharp Merrill Lynch ADSM/TSM Administrator Work : 020-7573-0469 Mobile : 07769-741612 Pager : 01893-038277 e-mail : [EMAIL PROTECTED]
