Results 1 to 9 of 9
  1. #1
    Member
    Join Date
    Dec 2003
    Posts
    2
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default Multiple Migration Processes Ending Early

    I am running TSM 5.3.5.0 on Windows 2000 Server. I have a script that invokes migration with the command "MIGR STGP DISKPOOL LO=45 WAIT=YES" as one command. The source storage pool is disk and the destination storage pool is tape. My tape library has four LTO2 drives. I do not use colocation. Initially four processes are started. After running for a while there are three processes. Then two. Then one. The problem is that the last one (or two) migrate numerous files some of which are large. So I wonder why the other processes don't migrate these files allowing the migration to complete sooner.

  2. #2
    Senior Member ttrinh7975's Avatar
    Join Date
    Apr 2004
    Location
    West Coast...Beautiful California
    Posts
    485
    Thanks
    1
    Thanked 3 Times in 3 Posts

    Cool

    1. Why are migrate stg to LO=45 instead of LO=0?
    2. Is the disk storage pool empty down to 45% after all the migrate process ran?
    3. You may need to set your maxscratch up a little for that storage pool
    4. Any error in the activity logs indicating the migrate storage process stopped?
    5. Is there enough scratch in the library for this process?
    Systems Engineering (Storage Administration)

    "No matter how well we do something, there is always something we can do better" - Joel R.

  3. #3
    Moderator BBB's Avatar
    Join Date
    Feb 2007
    Location
    Brisbane, Australia
    Posts
    2,075
    Thanks
    0
    Thanked 5 Times in 5 Posts

    Default

    Migration moves data for 1 client's filespace at a time. So if you have 1 very large client filespace in the diskpool, and 5 small filespaces with not much data changed, the 5 small ones will finish quickly and leave the big migration running for quite a while after that.

    That is why you are seeing what you seeing.

  4. #4
    Member
    Join Date
    Dec 2003
    Posts
    2
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    Quote Originally Posted by BBB View Post
    Migration moves data for 1 client's filespace at a time. So if you have 1 very large client filespace in the diskpool, and 5 small filespaces with not much data changed, the 5 small ones will finish quickly and leave the big migration running for quite a while after that.

    That is why you are seeing what you seeing.
    Ah, yes, I imagine that's it as I've got desktops and database servers all intertwined ... those 50GB plus files that keep running likely belong to one database server.

    To answer an earlier question, I don't set LO=0 because I want to leave it on disk as it may expire or need to be retrieved within a day and the next storage pool is tape.

  5. #5
    Senior Member
    Join Date
    Dec 2006
    Location
    northern front-range Colorado, USA
    Posts
    600
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    If you're talking about a DISK devclass pool, you really should empty it. If it's big enough to do some of your retention, shrink it and make some FILE class space, then mig your DISK to 0 every day. Set the FILE with MIGContinue to "N" and run your MIGDelay at a level that doesn't cause unplanned migrations. You can make a lot of things live out their retentions on disk so they never touch tape, without fragmenting your DISK pool space.

  6. #6
    Moderator moon-buddy's Avatar
    Join Date
    Aug 2005
    Location
    Somewhere in the US
    Posts
    5,939
    Thanks
    4
    Thanked 234 Times in 229 Posts

    Default

    On one hand, if you would like to have some data saved on disk, why not set cache ON? Even if the data has been migrated to tape (a good practice) data will still be "cached" on disk and follow the FIFO rule.

  7. #7
    Senior Member
    Join Date
    Dec 2006
    Location
    northern front-range Colorado, USA
    Posts
    600
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Default

    moon-buddy: caching degrades performance.

  8. #8
    Moderator moon-buddy's Avatar
    Join Date
    Aug 2005
    Location
    Somewhere in the US
    Posts
    5,939
    Thanks
    4
    Thanked 234 Times in 229 Posts

    Default

    Quote Originally Posted by n9hmg View Post
    moon-buddy: caching degrades performance.
    I know it degrades but can it be noticed for fast access small partitioned disk? My test says it is negligible.

    This seems to be the only solution for his dilema.

  9. #9
    Senior Member
    Join Date
    Nov 2005
    Location
    LU Germany
    Posts
    1,066
    Thanks
    0
    Thanked 1 Time in 1 Post

    Default

    From my experience, caching is a killer unless you do it for stuff like redo logs, where all objects are more or less of the same size. I'd go for cascaded file pools with a size limit on the first one (unless the amount of disk is too small. In that case - well - just do it the "classic" way. And if performance isn't a concern at all, forget what I just said about caching )

    PJ

Similar Threads

  1. HELP! Migration processes hanging...
    By mricha08 in forum Backup / Archive Discussion
    Replies: 5
    Last Post: 03-26-2008, 12:27 AM
  2. Migration processes & drive utilization
    By scapegoat in forum Backup / Archive Discussion
    Replies: 6
    Last Post: 03-25-2008, 09:03 AM
  3. Storage Data Consultant Contract ending 01/31/2007
    By Leo.Perez in forum Storage Management Jobs
    Replies: 0
    Last Post: 01-18-2007, 10:53 AM
  4. Multiple Reclamation Processes per Storage Pool
    By davidago in forum Performance Tuning
    Replies: 5
    Last Post: 08-11-2003, 02:38 PM
  5. HSM - Multiple migration through multiple Servers
    By d2r2 in forum Hierarchical Storage Management
    Replies: 2
    Last Post: 04-29-2003, 04:31 AM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •