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