compare exported node data to originating node data

[ssaddison]

Hi - we are upgrading our TSM server to new hardware/version/methodology. I am exporting a node from the original server to the new server. The node in question is 100TB+ and uses diskxtend. We have exported multiple times to catch up, etc. while the exports are successful, it appears the data size transferred does not match up with what is on the target server. I have tried using auditocc (after audit license is run) and also by summing the values retrieved from query nodedata. the data always seems to be about 1TB off. Has anyone 1) experienced this before 2) have a good method for verifying the data between source/target servers? As I understand there is an overhead for transactions and that the data size may NOT match up, but 1TB seems excessive.

Thank your for your time =)

 

[inthesun]

Hi,

The Q Nodedata specifies the Physical Space Occupied. That is the amount of physical space that is occupied by the node's data. Physical space includes empty space within aggregates, from which files might be deleted or expired.

So, the exported data on the target is most likely reporting a smaller size as it has cleaned up the wasted space.

If you do a Q Occupancy for the same node filespace, it will provide the Logical Space Occupied. The amount of space that is occupied by logical files in the file space. Logical space is the space that is actually used to store files, excluding empty space within aggregates.

The reported amounts still may be off a bit as the two systems may round off the amount differently. So, the best way to check if both systems are in sync is the number of objects reported. You can get this from the following select command:

select stgpool_name, sum(num_files) as "Number of files" from occupancy group by stgpool_name

If the two systems match the number of files, then they are in sync.