Your idea of using a script would seem the way to go; just use the same
admin. commands you're using today but monitor the migration processes (see
RedBook, Getting Started, for an example of a script that repeatedly
re-schedules itself based on a running process/session, until it finds the
conditions it likes or decides to quit.) You might prefer to write a shell
script that processes the results of a "SELECT" query, then sleeps for
awhile...
Don France
Technical Architect, P.A.C.E.
San Jose, CA
mailto:dfrance AT pacbell DOT net
PACE - http://www.pacepros.com
Bus-Ph: (408) 257-3037
> -----Original Message-----
> From: Andreas Buser [mailto:andreas.buser AT BASLER DOT CH]
> Sent: Thursday, May 25, 2000 12:38 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Antwort: Migration of Disk Pools Using MOVE DATA
>
>
> 1) No
> 2) Less
> 3) Yes, The MOVE DATA cmd can only be used against volumes of
> a pool not
> against the whole pool.
> _________________________________________________
>
> Kind Regards
> Andreas Buser
>
> Tel: ++41 61 285 73 21 Fax: ++41 61 285 70 98
>
> Email: Andreas.Buser AT Basler DOT ch
>
> Address:
> Basler Versicherungen
> Andreas Buser
> Abt. Informatik
> Aeschengraben 21
> 4002 Basel
> Switzerland
>
>
>
> Steven Chaba
> <Steven_Chaba An: ADSM-L AT VM.MARIST DOT EDU
> @RGE.COM> Kopie:
> Gesendet von: Thema: Migration of
> Disk Pools Using MOVE DATA
> "ADSM: Dist
> Stor Manager"
> <ADSM-L AT VM DOT MA
> RIST.EDU>
>
>
> 24.05.00
> 23:07
> Bitte
> antworten an
> "ADSM: Dist
> Stor Manager"
>
>
>
>
>
> I have four disk pools which I migrate to tape daily, using
> the HIGHM=0
> LOWM=0
> method, requiring four admin schedules to drop the
> thresholds, then four
> more to
> raise them, plus the issue of timing them so they don't
> overlap and utilize
> too
> many tape drives all at once.
>
> The thought occurred to me to do it this way, instead: Write
> a single macro
> or
> script a la:
>
> MOVE DATA <diskpoolA> <targettapepool> WAIT=YES
> MOVE DATA <diskpoolB> <targettapepool> WAIT=YES
> MOVE DATA <diskpoolC> <targettapepool> WAIT=YES
> MOVE DATA <diskpoolD> <targettapepool> WAIT=YES
>
> And the questions thus arose:
> 1) Would this work?
> 2) Is it more or less efficient than dropping the migration
> thresholds?
> 3) Are there considerations I'm missing?
>
> PS - The "why four disk pools" has a standard answer: Money -
> i.e. adding
> SSA
> drawer space and drives doesn't really qualify as "disk is
> cheap". The four
> disk
> pools are 1- Archive, 2 - Picky API client #1, 3 - Picky API
> client #2, 4 -
> All
> the other luckless backup clients. Pool #4 migrates during
> the backups.
>
> Regards, Steven
> Steven Chaba, (confused) Lead Analyst, ADSM/AIX/HACMP
> Rochester Gas & Electric Corporation
> Rochester, NY USA
>
|