Агрегатная хэш-функция средствами стандартного SQL. Есть ли варианты, лучшие, чем SUM?

Задача
Требуется периодически синхронизировать данные в двух больших таблицах, расположенных на разных SQL-серверах. Таблица-источник расположена на SQL-сервере IBM DB2, таблица-приёмник – на MS SQL 2000. В момент каждой синхронизации отличия между таблицами весьма небольшие. Необходимо провести синхронизацию, не перекачивая полностью все данные. Узким местом является именно передача данных. Оба SQL-сервера работают достаточно шустро. Таблица-источник не имеет уникального ключа/индекса, изменить её структуру нельзя. Изменения в данных источника могут касаться любого поля таблицы, предсказать их заранее также практически невозможно.

Предполагаемый способ решения
Синхронизация производится путём применения SQL-запроса на MS SQL 2000, содержащего обращение к связанному SQL-серверу DB2. Данные в запросе к таблице могут быть сгруппированы по какому-нибудь полю, например - дате. Требуется вычислить хэш для каждого подмножества строк, относящегося к каждой дате на источнике и приёмнике и сравнить хэши. Если хэши различаются – то обновляются только записи, касающиеся только этой даты.

Проблема
Как вычислить качественный агрегатный хэш средствами стандартного SQL так, чтобы его значения для одинаковых входных подмножеств совпадали на DB2 и MS SQL? Пока я использую простое суммирование функцией SUM (с переполнением) для некоторых числовых полей. Это работает (и притом довольно быстро), хотя и не выглядит в моих глазах достаточно надёжным.

Для страховки я собираюсь после синхронизации выполнять в обеих таблицах суммирование по одному из числовых полей и, если суммы не сойдутся, – выполнять полное копирование.

Дополнение
Я знаю о семействе функций CHECKSUM_AGG, CHECKSUM и BINARY_CHECKSUM на MS SQL 2000. К сожалению, мне не известны аналоги в DB2, да и само их качество (в частности CHECKSUM_AGG) представляется недостаточным. Слишком часто возвращаются одинаковые хэши для разных входных множеств.

Данные меняются только в одной таблице-источнике на сервере DB2. Ничего настроить или тем более стирать на сервере DB2 нельзя. Можно только читать.

Весь огород городится для того, чтобы не перекачивать все данные из таблицы-источника при синхронизации.
Для того чтобы определить изменившееся подмножество(а) в источнике считаем по ним хэши и сравниваем на источнике и приёмнике.
Вопрос был об агрегатной хэш-функции реализуемой стандартными средствами SQL DB2 непосредственно в строке запроса. Без применения пользовательских переменных, функций и процедур.
Далее. Аналог этой хэш-функции должен быть реализуем на MS SQL 2000. Какими угодно средствами - COM, T-SQL, расширенные ХП и т.п.

xze321) Данные параллельно меняются в 2 системах?
2) Если нет то зачем городить огород.
например в DB2 есть таблица X
настраиваем репликацию из таблицы X в таблицу XR. Реплицируем только измененные данные.
периодически забираем из таблицы XR данные в MS-SQL X
после того как забрали данные удаляем все из таблицы XR
Предложенный Вами вариант конечно здравый, спасибо за ответ. К сожалению, он неприменим в настоящее время в моей ситуации.

Кстати, будет ли отслеживаться при репликации изменений удаление записей в таблице-источнике? Каким образом?
Количество записей в таблице-источнике не фиксировано. Страрые удаляются, новые добавляются.

gals, спасибо за ответ!
galsGhola
Вопрос был об агрегатной хэш-функции реализуемой стандартными средствами SQL DB2 непосредственно в строке запроса. Без применения пользовательских переменных, функций и процедур.
Далее. Аналог этой хэш-функции должен быть реализуем на MS SQL 2000. Какими угодно средствами - COM, T-SQL, расширенные ХП и т.п.
Интересно получается. На DB2 ничего своего делать нельзя, а на MS SQL можно.
Угу. Именно так.
galsПосмотрите статистические функции, типа AVG, STDDEV, CORRELATION.
Смотрел, они возвращают значения с плавающей точкой, которые, в отличие от SUM, часто не совпадают для MS SQL и DB2, при одинаковых входных множествах. Значения полей в таблице-источнике типов CHARACTER, NUMERIC и DECIMAL. Т.е. пригодные для целочисленной арифметики.

zz..zz..zzА поймать изменения capture-ом в CD-таблицы?
Поясните свою мысль, плиз. Мне это непонятно.

zz..zz..zz..zzтогда хэш будет select count(*) where data='data', из CD-таблицы. если count(*)
и select sum(0) from что - нибудь на Microsoft sql server
Скажите пожалуйста, что такое "CD-таблица"? Количество записей, относящихся к каждой дате я и так считаю и сравниваю, но считаю это недостаточным.

zz..zz..zz..zzGholazz..zz..zzА поймать изменения capture-ом в CD-таблицы?
Поясните свою мысль, плиз. Мне это непонятно.

ну есть же стандартный механизм в репликации в DB2, он работает примерно так

1 изменения пишутся в transaction log
2 программа capture читает transaction log и пишит изменения в так называемые CD-таблицы
3 программа apply читает CD-таблицы и применяет изменения где-нибудь на другой базе

потом CD-таблицы чистятся.

ничто же не мешает брать изменения прямо из CD-таблиц, а потом самому их чистить.
вот если в СD-таблицах что-то есть, значит это и нужно применять на Microsoft SQL Server
Спасибо за разъяснения, уже понятнее. Но не вполне. :) Уточните, это справедливо для какой платформы? (ОС). К тому же, Вы, вероятно, имеете в виду так или иначе механизм репликации, не так ли? Боюсь, что у нас он не настроен. И не будет настроен в обозримом будущем. Позволяет ли отслеживать такой механизм добавление и, самое главное, удаление, а не только изменение существующих записей в таблице-источнике?

Mark BarinsteinGhola,

Триггеры на db2-таблицу можно повесить, которые смогут в вашу служебную таблицу писАть?Увы-увы... Нельзя. На DB2 я могу только читать. Ни создавать триггеры ни процедуры ни функции. Ни переменные. К тому же триггеры понизят производительность БД при изменениях в таблице-источнике, а это крайне неприветствуется. Хотя замедление должно быть несущественно...

Mark Barinstein, Большое спасибо за Ваш совет! :) А экспрессия ни к чему. Впрочем, как я уже говорил, триггеры имеют для меня в данном контексте чисто академическое значение.

Возвращаясь к теме топика
При использовании в качестве агрегатного хэша функции SUM, в MS SQL 2000 возможно переполнение, которое приведёт к ошибке и, как следствие, - к невозможности синхронизации.

Опытным путём удалось выяснить, что в MS SQL 2000 функция SUM от целочисленного аргумента возвращает результат типа NUMERIC(38,0). (челое число с 38-ю значащими цифрами, максимальная константа 10^38 - 1)

Переполнение результата SUM в MS SQL наступает, если результат функции SUM превышает 10^39 - 1, см:
Судя по документации к IBM DB2 максимальная константа NUMERIC составляет там 10^31 -1, Эксперимент показал, что в случае переполнения результата функции SUM СУБД DB2 возвращает NULL (а не ошибку).

В общем, описанный мной в первом постинге способ решения задачи далеко не идеален, однако в конкретной ситуации, похоже, будет для меня единственно возможным. Судя по характеру данных, до переполнения мне очень далеко. Однако предполагавшееся после синхронизации контрольное суммирование по всей таблице я, пожалуй, заменю просто на подсчёт полей.

*(Сорри разумеется не подсчёт полей, а подсчёт и сравнение количества записей в источнике и приёмнике