Как мне реплицировать и проверять данные из удаленных систем в SQL Server - PullRequest
1 голос
/ 16 февраля 2009

У меня есть задача по созданию некоторой логики для базы данных. Сегодня существует установка IBM MQ Series, которая реплицирует данные из нескольких удаленных систем. В настоящий момент он изменяется в удаленной системе и сбрасывает данные в промежуточную таблицу в базе данных SQL Server 2005.

Я хочу проверить данные в соответствии с некоторой простой логикой проверки (обязательные поля и формат данных) и некоторыми более сложными проверками иерархии данных. Импортируемые данные являются иерархическими с родительскими дочерними отношениями между некоторыми данными Иерархическая проверка должна проверять как данные, доступные в настоящее время в промежуточной таблице, так и в рабочей таблице, чтобы убедиться, что после завершения импорта будет действительная иерархия.

Если проверка записи не удалась, сбой должен как-то регистрироваться, и записи о сбоях не должны импортироваться, а остальные записи должны. Записи в текущих производственных таблицах должны быть заменены новыми записями, если они имеют одинаковый идентификатор. Перенос данных из промежуточной таблицы должен быть выполнен как можно скорее, после этого данные появляются в промежуточной таблице.

Насколько я знаю, общее количество записей в производственных таблицах не будет превышать 1 млн., А вероятное количество обновленных элементов в партии будет составлять не более пары тысяч строк.

Мой вопрос: какое решение лучше всего подходит для импорта данных?

Я подумал о нескольких возможных решениях:

Средства запуска перевода:

  • Служба Windows, которая опрашивает промежуточный стол на регулярной основе и запускает какую-то передачу обрабатывать всякий раз, когда новые данные вставлено.
  • Заставить MQ начать процесс передачи после вставки новых данных в стол
  • Планирование запуска задания SSIS через регулярные интервалы

Средства проверки и передачи данных:

  • Создание задания SSIS
  • Создание хранимых процедур
  • Пользовательский код .NET

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

1 Ответ

0 голосов
/ 16 февраля 2009

Мы используем закрытый процесс для этого типа работы.

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

Если что-либо может быть вставлено в промежуточные таблицы по желанию и имеются дочерние таблицы, то существует риск, что вы можете выполнить импорт в рабочую базу данных до того, как все дочерние записи будут созданы в промежуточных таблицах.

Если вы можете свободно добавлять столбцы в промежуточные таблицы (которые удаленный конец будет игнорировать) или если промежуточные таблицы имеют IDENTITY или GUID, который является уникальным / неповторяющимся, то вы можете создать параллельную таблицу.

В идеале подпрограмма создания строк в промежуточной таблице будет использовать номер партии, а затем в случае успеха создаст запись «Номер партии выполнен». Таким образом, у вас есть семафор, чтобы остановить импорт до тех пор, пока все связанные записи не будут в нем.

(Они могут быть вставлены в блок транзакций, но вы должны быть уверены, что все процессы, вставленные в промежуточную таблицу, соблюдают это).

Учитывая IDENTITY / GUID, я бы создал «таблицу ошибок» 1: 1 для хранения любых сообщений, описывающих сбой импорта.

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

Сказав, что вот более подробное описание наших конкретных процессов:

Чтобы минимизировать пропускную способность и обновления (т.е. уменьшить блокировку и минимизировать ненужные записи в журнале транзакций и т. Д.), Мы делаем следующее:

На исходном компьютере хранится копия передаваемой таблицы. У этого есть дополнительные столбцы для Обновления и Действия (флаг Обновления или Удалить - Обновление включает Вставку, и Вставка, возможно, была обновлена ​​снова прежде, чем место назначения когда-либо получит эту строку ...)

Вставки в эту таблицу, из new , строки в порядке

Обновления в этой таблице происходят только в том случае, если есть разница хотя бы в одном столбце, поэтому вполне нормально (если достаточно интенсивно использовать ЦП) для сравнения всей исходной таблицы с промежуточной таблицей, чтобы выяснить, что изменилось. Обновления устанавливают столбец Обновленные. (Остерегайтесь, когда часы вернутся назад)

Периодически мы помечаем строки исходной таблицы Action = Deleted, если их невозможно найти в исходной таблице.

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

На целевом сервере подпрограмма, которая проверяет данные и импортирует их в производство, работает исключительно в дату обновления (обрабатывает все, начиная с последнего обновления)

Все промежуточные таблицы находятся в отдельной базе данных, в которой ведется минимальное количество журналов - база данных автоматически обновляется с «даты последнего обновления», если она будет восстановлена, поэтому наша цель - минимизировать журнал транзакций. Мы не храним промежуточные таблицы в производственной базе данных (которая будет иметь полное ведение журнала транзакций), чтобы избежать вздутия TLogs

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

Мы передаем данные в стиле исходной базы данных и выполняем манипуляции с данными только в конце пункта назначения. Причина этого заключается в том, что если манипулирование данными является неправильным, и мы исправляем его, нам нужно только повторно запустить его в конце пункта назначения - все исходные данные присутствуют в промежуточных таблицах в конце пункта назначения. Если бы мы выполняли манипуляции на стороне источника, нам также пришлось бы повторно передавать все данные.

Для отладки полезно иметь дату обновления в промежуточной таблице. Мы часто сталкиваемся с «Почему это отличается», и, видя, что «Обновленный» сообщает нам, была ли ошибка в конце пункта назначения (то есть у нас есть последние данные, показывающие ожидаемые данные источника) или в конце источника (последние данные не найдены! )

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...