> '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