On 12/01, Kauffman, Tom wrote: > > On Fri, Jan 9, 2009 at 3:45 PM, Kauffman, Tom <kauffm...@nibco.com> > > wrote: > > > > You can get that pretty easily from the SUMMARY table. You'll have > > to play with it though, to pick out specifically which stgpool > > process you want. > > Start here with: > > > > select * from summary where activity='STGPOOL BACKUP' > > > > This is close, but not what I need -- > > I've got a severe imbalance in one of my storage pools that I'm trying to > document, so I can get it fixed. To do that, I need a way to break down the > result I get here to a count by process: > START_TIME: 2009-01-08 04:49:12.000000 > END_TIME: 2009-01-08 08:27:48.000000 > ACTIVITY: STGPOOL BACKUP > NUMBER: 3194 > ENTITY: ARCH-LT4 -> ARCH-LT2-COPY > COMMMETH: > ADDRESS: > SCHEDULE_NAME: > EXAMINED: 50531 > AFFECTED: 50531 > FAILED: 0 > BYTES: 876242125091 > IDLE: 0 > MEDIAW: 188 > PROCESSES: 2 > SUCCESSFUL: YES > VOLUME_NAME: > DRIVE_NAME: > LIBRARY_NAME: > LAST_USE: > COMM_WAIT: 0 > NUM_OFFSITE_VOLS: > > I'm fairly certain that nearly 600 GB of this was from one node and one > filesystem (a VMWare virtualcenter proxy); I just need to be able to prove > it, so I can get the data split up better (we're supposed to have the > off-site copies and matching TSM database backups done by 07:30). >
Why not just do a Q OCC on the node before and after the STGPOOL BACKUP? That way you will see exactly how much the node has increased its storage.
