f00Gass, если имеется строгий запрет на обработку одинаковых файлов, то, помимо CRC или хеша в качестве ключа, нужен дополнительный анализ данных. Если в самих данных есть такая уникальная часть, то ее и нужно делать характеризующим файлы ключем.
Вариант простой - делаешь разделяемую между процессами таблицу с характеризующим ключем, полем, информирующем о стадиях обработки и поле с планируемым временем завершения обработки.
Кто их процессов первый начинает транзакцию вставкой записи с ключем, тот и обрабатывает(если быстро, то можно в той же транзакции, тогда кроме ключа может и не понадобиться других полей).
Нужно еще предусмотреть сбойные ситуации, когда данные длительной обработки, и процесс, который вставил запись, аварийно завершен. Тогда периодическая чистка должна проверять окончание обработок по стадии и времени обработки.
Если все обработки выполняется внутри одного сервера MSSQL, то можно использовать sp_getapplock...sp_releaseapplock для замыкания по характеризующему файлы ключу вместо "родных" транзакций

f00Gass, конкурирующая логика работы всегда такая, что проще обработать исключение уникальности или таймаута, чем городить свою "логику". Хотя бы платформу уточни, и на скольки серверах должна выполняться

f00GassXDiaBLo,
С каждой страницы берётся только нужная информация, совпадение получается стопроцентным.
Фактически, это задача поиска дубликатов, а там наибольшая обработка-то как раз заключается в получении слепка (например, подсчет к-нибудь хеша для характеризующего ключа + размер файлов в Вашем случае) чтобы сравнивать сущности. Но здесь всегда были подводные камни при отбрасывании несущественных изменений (например, лишние пробелы в тексте, комментарии MP3 тегах) - в Вашем случае, судя по цитате, этим спайдеры занимаются