Hi Richard.
First, thanks for the quick answer :-),
Thus I need to asume from my select results, that the real size of the
backups in the library is taken from the occupancy table?
which is a reasonable number 2.5TB, and if its the only way to know what is the real
size of
my library?
regards
Ofer. Ccc
Richard Sims wrote:
> > 'select node_name,sum(file_size) as sum_file_size from contents group
> > by node_name'
> >
> > 'select node_name,sum(PHYSICAL_MB) as sum_phys_mb from occupancy group
> > by node_name'
> >
> > and I got the following result
> >
> > 9,030,520 MB from the contents table
> >
> > 2,422,690 MB from the occupancy table
> >
> > From the occupancy table I have a reasonable number that I can live
> > with but the values from the contents are bigger then my library with
> > a 100% compression.
> >
> > what is the explanation for that number?.
>
> Ofer - From http://people.bu.edu/rbs/ADSM.QuickFacts :
>
> FILE_SIZE ADSMv3 SQL: A column in the CONTENTS
> table, supposedly reflecting the file
> size. Unfortunately this reports the
> size of the Aggregate (of small files),
> not the individual file, except when the
> file is very large and thus not
> aggregated (greater than the client
> TXNBytelimit setting).
>
> If you look at all the fields in a Contents listing, you will see a lot of files
> together in the listing with like "AGGREGATED: 3/9" and all 9 having the same
> FILE_SIZE - which is the size of the Aggregate in which they reside.
> Unfortunately, the customer's virtual view of the TSM database does not provide
> access to actual file sizes, as can be seen from the TSM clients.
>
> Richard Sims, BU
