This will give you the BACKUP stats from the summary table:

select cast(activity as char(7)) as "Action",    left(entity,16) as
"Client"      ,        cast(month(start_time) as varchar(2))|| '-' ||
cast(day(start_time) as varchar(2)) as "Date",
left(cast(time(start_time) as varchar(8) ),5)  as "Start",  cast
((end_time-start_time) minutes as decimal(4,0))    as "Min", cast(cast(bytes
as decimal(15,1)) /1024/1024/1024 as decimal(6,1)) as "GB", cast(processes
as decimal(2)) as  "Pr", cast(mediaw as decimal(5)) as MWsec, cast(comm_wait
as decimal(6)) as CWsec  from summary  where activity IN ( 'BACKUP',
'RESTORE')

That will prove how much data is coming daily per node, but not by
filespace.  As km says, the only way to get exactly what you asked for is
probably to do a Q OCC before and after.

FWIW, you are getting >30 MB/sec for the BACKUP STGPOOL process.  If, as the
names imply, your copy pool is on LTO2, that's about the best you can get.
Easy solution is to throw another pair of drives into that process, if
you've got them.



On Mon, Jan 12, 2009 at 10:30 AM, km <km AT grogg DOT org> wrote:

> On 12/01, Kauffman, Tom wrote:
> > > On Fri, Jan 9, 2009 at 3:45 PM, Kauffman, Tom <KauffmanT AT nibco DOT 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.
>