Я хотел бы добавить информацию из моей производственной базы данных в свою ступенчатую базу данных. У меня есть BAK производственной базы данных, и я могу просто восстановить ее на этапе, но меня беспокоит влияние репликации слиянием на это.
Позвольте мне объяснить дальше; У меня 15 пользователей тестируют иногда подключаемое приложение внутри компании. Структура такова, что в каждой системе есть локальный SQL Express, подписанный на сервер Stage SQL 2005 с подписками по запросу. Сервер Stage действует как издатель и распространитель. Тестировщиками был сделан запрос на использование «реальных» данных. Если я просто восстановлю BAK из рабочей среды в свой экземпляр Stage, что произойдет с моими наборами репликации? Когда локальная БД попытается синхронизироваться, будут ли они "ВЫБИРАТЬСЯ", потому что все GUID изменились?
Я думал восстановить производственную базу данных на Stage Server под другим именем, а затем УДАЛИТЬ содержимое, скажем, tblPerson и запустить INSERT INTO из Production tblPerson в теперь пустое Stage tblPerson.
Я хотел бы получить мысли и предложения по обоим.
Восстановит ли дело БАК конец света
и / или
является ли мое второе решение жизнеспособной альтернативой?
Мне вообще нужно так много делать? Могу ли я удалить содержимое tblPerson (Stage), а затем выполнить Cross DB SELECT INTO от tblPerson (Production) к аналогу Stage?
В основном мне интересно / беспокоит влияние этого на мои существующие подписки.
Возможно, подойдет INSERT INTO или BCP. Как вы упомянули, для восстановления производственной базы данных потребуется воссоздать репликацию в промежуточном экземпляре. SELECT INTO не является хорошей идеей, потому что вы не можете использовать существующую таблицу в качестве цели предложения INTO - это должна быть новая таблица, поэтому вам придется удалить целевую таблицу, что снова потребует ремонта для твоя репликация.
Из двух других INSERT определенно самый простой, и я часто использовал этот метод. Если требуется скорость, попробуйте BCP. Массовая вставка обычно выполняется намного быстрее, чем стандартная операция INSERT. Согласно BOL (http://msdn.microsoft.com/en-us/library/ms151206.aspx), вы должны использовать переключатель, чтобы заставить триггеры срабатывать, но похоже, что в противном случае он должен работать нормально.
Восстановление базы данных уничтожит вашу репликацию (по крайней мере, в моих сценариях. Скажите мне, пожалуйста!
Мы сделали в значительной степени то, что вы предлагаете - УДАЛИТЬ * ИЗ myTable и ВСТАВИТЬ INTO. Это заняло некоторое время, но удаление таблиц или удаление / восстановление базы данных уничтожили репликацию в нашем сценарии.
Я не знаю, будет ли это иметь значение, но мы также приостановили репликацию для всех подписчиков, пока это делали.
Вы не хотите использовать репликацию из производственной среды в рабочую среду, особенно репликацию слиянием.
Лучше всего, когда вам когда-либо понадобятся данные в промежуточной базе данных для резервного копирования производственной базы данных и восстановления всего объекта. Если вы попробуете разделить еду на части, вам придется иметь дело со всеми связанными с этим проблемами ссылочной целостности.