Multiple Migration Processes Ending Early

[dwightmccann]

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.

 

[ttrinh7975]

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?

 

[BBB]

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.

 

[dwightmccann]

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.

 

[n9hmg]

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.

 

[moon-buddy]

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.

 

[n9hmg]

moon-buddy: caching degrades performance.

 

[moon-buddy]

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.

 

[PJ]

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