CHECK_SUM
Содержание раздела
Запрос позволяет рассчитать контрольную сумму изменений в указанной дельте. Под изменениями понимаются записи, загруженные и обновленные в дельте. Дельта может быть закрытой или открытой (горячей).
Контрольную сумму можно рассчитать по следующим данным:
- отдельным столбцам логической таблицы или материализованного представления,
- всем столбцам логической таблицы или материализованного представления,
- всем логическим таблицам логической базы данных.
Контрольная сумма рассчитывается по каждой СУБД хранилища, которая хранит данные проверяемой логической сущности. Порядок расчета описан ниже.
При расчете контрольной суммы по отдельным столбцам рекомендуется добавлять первичный ключ в список столбцов. Это повысит уникальность контрольных сумм, рассчитываемых по разным данных.
Чтобы рассчитать контрольную сумму по актуальным данным, а не изменениям данных, используйте запрос CHECK_SUM_SNAPSHOT.
В ответе возвращается:
- объект ResultSet с контрольной суммой при успешном выполнении запроса и отсутствии расхождений между СУБД хранилища;
- исключение при наличии расхождений или неуспешном выполнении запроса.
Если контрольные суммы различаются между СУБД хранилища, система возвращает исключение Consistency breach detected for <entity_name>
. Исключение содержит список контрольных сумм по всем проверенным СУБД. При расчете контрольной суммы по логической базе данных система возвращает исключение по первому найденному расхождению и не проверяет следующие сущности.
Значения типа FLOAT и DOUBLE могут иметь разные контрольные суммы из-за разницы в точности типов. Чтобы избежать расхождения в контрольных суммах, используйте для всех значений с плавающей точкой тип DOUBLE (как более распространенный среди СУБД) или исключайте столбцы типа FLOAT и DOUBLE из запросов CHECK_SUM_SNAPSHOT
.
Синтаксис
CHECK_SUM(delta_num[, normalization][, [db_name.]entity_name[, square_bracketed_column_list]])
Параметры:
delta_num
-
Номер дельты, по которой рассчитывается контрольная сумма изменений.
normalization
-
Опциональный коэффициент, который повышает лимит на количество проверяемых записей в одной сущности, но снижает уникальность контрольных сумм. Может принимать любое целое значение, начиная с 1. Значение по умолчанию — 1.
Если коэффициент не указан или равен 1, проверяемая сущность может содержать до4'294'967'298
загруженных записей в дельте; при увеличении коэффициента лимит увеличивается пропорционально. db_name
-
Имя логической базы данных, которой принадлежит проверяемая сущность. Опционально, если выбрана логическая БД, используемая по умолчанию.
entity_name
-
Имя логической таблицы или материализованного представления, по которому рассчитывается контрольная сумма. Опциональный параметр.
square_bracketed_column_list
-
Опциональный список имен столбцов, по которым рассчитывается контрольная сумма. Элементы списка перечисляются в квадратных скобках через запятую.
Если столбцы не указаны, система рассчитывает контрольную сумму по всем столбцам таблицы или представления.
Ограничения
- Контрольная сумма логической базы данных рассчитывается только по данным логических таблиц и не учитывает данные материализованных представлений.
- Существует вероятность совпадения контрольных сумм для разных наборов данных.
- Количество проверяемых записей в одной сущности ограничено и регулируется коэффициентом нормализации. Если количество загруженных записей какой-либо сущности в указанной дельте больше
4'294'967'298
, нужно подобрать подходящее значение коэффициента нормализации.
Примеры
Запрос по отдельным столбцам логической таблицы
Расчет контрольной суммы по трем столбцам таблицы sales
в седьмой дельте:
CHECK_SUM(7, marketing.sales, [id, transaction_date, product_code])
На рисунках ниже показаны примеры ответов на запрос CHECK_SUM
с перечислением столбцов: на первом — ответ при отсутствии расхождений в данных между СУБД хранилища, на втором — ответ при наличии расхождений.
Запрос по всем столбцам логической таблицы
Расчет контрольной суммы по всей таблице sales
в седьмой дельте:
CHECK_SUM(7, marketing.sales)
На рисунке ниже показан пример ответа на запрос CHECK_SUM
по логической таблице.
Запрос по всем столбцам материализованного представления
Расчет контрольной суммы по всему материализованному представлению sales_by_stores
в десятой дельте:
CHECK_SUM(10, marketing.sales_by_stores)
Запрос по логической базе данных
Расчет контрольной суммы по всем таблицам логической базы данных marketing
в седьмой дельте:
-- выбор логической базы данных marketing в качестве базы данных по умолчанию
USE marketing;
-- расчет контрольной суммы логической БД
CHECK_SUM(7);
На рисунке ниже показан пример ответа на запрос CHECK_SUM
по логической базе данных.
Запрос по логической базе данных с коэффициентом нормализации
Расчет контрольной суммы по всем таблицам логической базы данных marketing
с коэффициентом нормализации, равным 100:
-- выбор логической базы данных marketing в качестве базы данных по умолчанию
USE marketing;
-- расчет контрольной суммы логической БД с указанным коэффициентом нормализации
CHECK_SUM(7, 100);
На рисунке ниже показан пример ответа на такой запрос.
Порядок расчета контрольных сумм
Расчет контрольной суммы по логической таблице или материализованному представлению
Контрольная сумма логической таблицы или материализованного представления рассчитывается, как описано в разделе CHECK_DATA.
Расчет контрольной суммы по логической базе данных
Контрольная сумма логической базы данных рассчитывается так:
- По каждой логической таблице логической базы данных рассчитывается контрольная сумма, как описано в разделе CHECK_DATA.
- Контрольные суммы всех логических таблиц суммируются — получается 64-битная контрольная сумма логической базы данных.
Пример расчета контрольной суммы по таблице
Рассмотрим пример расчета контрольной суммы по таблице sales
в дельте, в которой загружено две записи. Для простоты возьмем уже рассчитанные контрольные суммы записей: 165074672 (см. пример расчета в разделе CHECK_DATA) и 87891666.
Контрольная сумма таблицы равна 165074672 + 87891666 = 252966338
.