Эффективное преобразование данных из одной базы данных SQL в другую в реальной среде

Question

У нас немного грязная база данных.

Наша основная бэк-офисная система написана на Visual Fox Pro с локальными данными (да, я знаю!)

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

Это означает, что у нас есть две базы данных SQL - одна, в которую пишет наш процесс экспорта FoxPro, и другая, из которой наши веб-сайты читают.

Этот вопрос касается преобразования из одной базы данных SQL в другую (SqlFoxProData -> SqlWebData).

Для конкретной таблицы (одной из наших основных таблиц приложений), поскольку во время этого процесса происходят различные преобразования данных, это не простые операторы UPDATE, INSERT и DELETE, использующие самостоятельные объединения, но вместо этого мы должны использовать курсоры (Я знаю!)

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

В основном, когда мы обновляем SqlWebData.ImportantTable из SqlFoxProData.ImportantTable, это вызывает случайные тайм-ауты / тупики подключения / другие проблемы на живых веб-сайтах.

Я много работал над оптимизацией запросов, кэшированием и т. Д., Но настал момент, когда я искал другую стратегию для обновления данных.

Одна идея, которая пришла в голову, состоит в том, чтобы иметь две копии ImportantTable (A и B), некоторое представление о том, какая таблица в настоящий момент «активна», обновляет неактивную таблицу, затем переключает таблицу текущих действий

т.е. веб-сайты читаются из ImportantTableA, пока мы обновляем важные таблицы, а затем переключаем веб-сайты на чтение из важной таблицы.

Вопрос в том, возможно ли это и хорошая идея? Я делал что-то подобное раньше, но я не уверен, что это обязательно хорошо для оптимизации / индексации и т. Д.

Любые предложения приветствуются, я знаю, что это беспорядочная ситуация ... и долгосрочной целью было бы заставить наше приложение FoxPro указывать на SQL.

(мы используем SQL 2005, если это поможет)

Я должен добавить, что согласованность данных в данном случае не особенно важна, поскольку данные всегда немного устарели

Answer 1

Есть много способов снять шкуру с этой кошки.

Сначала я бы атаковал проблемы блокировки. Я редко использую CURSORS, и я думаю, что улучшение производительности и блокировка могут решить многие ваши проблемы.

Я ожидаю, что я решу это, используя две отдельные промежуточные таблицы. Один для экспорта FoxPro в SQL и один преобразованный в окончательный формат в SQL бок о бок. Затем либо поменяйте финал для производства, используя sp_rename, либо просто используйте 3 транзакции INSERT / UPDATE / DELETE, чтобы применить все изменения из финальной таблицы к производству. В любом случае, там будет какая-то блокировка, но о каком большом мы говорим?

Answer 2

"Для конкретной таблицы (одной из наших основных таблиц приложений), поскольку во время этого процесса происходят различные преобразования данных, это не простые операторы UPDATE, INSERT и DELETE, использующие самостоятельные объединения, но мы должны использовать курсоры вместо этого (я знаю!) "

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

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

Вы также можете использовать SSIS для перемещения данных.

Answer 3

Вы должны иметь возможность поддерживать одну базу данных для веб-сайта и просто реплицировать эту таблицу из другой таблицы базы данных SQL.

Предполагается, что вы не обновляете данные с самого сайта.

Answer 4

На основании вашего ответа Эрни выше, вы спросили, как вы реплицируете базы данных. Вот инструкции Microsoft по репликации в SQL2005.

Однако, если вы спрашиваете о репликации и о том, как это сделать, это говорит мне о том, что вы немного разбираетесь в SQL-сервере. Тем не менее, довольно легко все испортить, и, хотя я полностью учусь на опыте, если это критически важные данные, вам может быть лучше нанять DBA или, по крайней мере, протестировать # $ @ # $ % из этого, прежде чем вы на самом деле реализуете его.

Answer 5

Есть ли у вас возможность сделать обновления более элементарными, чем заявленные «очистка и повторная вставка»? Я думаю, что Visual Fox Pro поддерживает триггеры, верно? Для ваших таблиц ключей вы можете добавить триггер к обновлению / вставке / удалению, чтобы захватить идентификатор записей, которые меняются, а затем переместить (или удалить) только эти записи?

Или как насчет записи всех изменений в автономную базу данных и обеспечения репликации SQL Server для синхронизации?

[извините, это был бы комментарий, если бы у меня было достаточно репутации!]