It's not our largest node by a long shot.  We have several DB2 nodes that
are holding upwards of 15TB apiece, and a couple more in the 10TB range.

On 6/19/07, Richard Sims <rbs AT bu DOT edu> wrote:

On Jun 19, 2007, at 11:20 AM, Andrew Carlson wrote:

> I would like to move about 6TB of data for a node from Random
> Access disk to
> sequential accesss.  Since move nodedata doesn't work on random access
> pools, I was wondering if there is an easy way to do it.  The data is
> archive data, and the only plan I could come up with was moving
> data from
> individual volumes to a staging area, a sequential access pool,
> then moving
> nodedata from there to the final destination sequential access
> pool.  Anyone
> have any better ideas?  Thanks for any input.

Andy -

I would expect that amount of data to represent the largest quantity
in the disk storage pool.  If that is the case, then allowing the
data to migrate down to a node-collocated sequential pool, with
MIGPRocess=1 in effect and migration levels lowered, would cause that
dominant node's data to be handled first.  You could then do Query
PRocess periodically to estimate when the data is just about all
moved, and then be ready to cancel the process and reset the
migration levels once all the node's data is moved.  With the
destination being a tape pool, the node transition would be apparent,
as a partially filled tape would be left as the single process then
went on to mount a fresh tape for the next node.  In any case, any
"overshoot" would be on a separate tape, whereupon you could Move
Data that node's data back to the disk stgpool, or wherever.

   Richard Sims

--
Andy Carlson
---------------------------------------------------------------------------
Gamecube:$150,PSO:$50,Broadband Adapter: $35, Hunters License: $8.95/month,
The feeling of seeing the red box with the item you want in it:Priceless.