Could you look at your job logs at the last log before this failure, and see if it ran a compact? I’m currently looking at a problem where the newest fileset (0) gets this problem, but while looking I saw some suspect code that possibly could do damage to the File table which might cause a problem in some older filesets.
For any developers who know the database, does it seem right to delete a File row based on MetadataID? Maybe code meant to map MetadataID to a BlocksetID, then use BlocksetID for cleanup (like other lines)? Different handling of different table deletions might cause the unexpected difference (haven’t proven it yet).
Introduction of the MetadataID code was done here as part of a fix, but was it right? Note I’m not an expert.