Как скопировать большой набор данных в SQLServer db

Question

У меня есть требование принять «моментальный снимок» текущей базы данных и клонировать его в ту же базу данных с новыми Первичными ключами.

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

Какие у меня варианты?

Я боюсь, что для написания SPROC потребуется блокировка строк в базе данных (для параллелизма) на весь период действия, что очень раздражает других пользователей. Как долго будет проводиться такая операция, предполагая, что мы можем оптимизировать ее в полной мере, что позволяет sqlserver? Это будет 30 секунд до 1 минуты, чтобы выполнить это много вставок? Я не могу заблокировать всю таблицу (ы) и сделать объемную вставку, потому что есть другие пользователи под другими учетными записями, которые используют одни и те же таблицы независимо.

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

Если хороший администратор базы данных может получить операцию «клон», чтобы выполнить старт до конца менее чем за 10 секунд, то, вероятно, не стоит сложность решения xmldump/webservice. Но если это потерянная причина, и вставить потенциально миллионы строк, вероятно, выйдет вовремя, то я предпочел бы начать с подхода xml сразу.

Или, может быть, есть совершенно лучший подход вообще?

Большое спасибо за любые идеи, которые вы можете предоставить.

Answer 1

Я бы предложил создать резервную копию базы данных, а затем восстановить ее как новый db на вашем сервере. Вы можете использовать эту новую БД в качестве источника. Я обязательно рекомендую использовать идею xml dump.

Answer 2

Нужно ли быть в одних и тех же таблицах? Вы могли бы сделать набор «моментальные снимки» таблицы, где все эти записи идут, вам нужно будет только один вкладыш + выберите, как

insert into snapshots_source1 (user,col1, col2, ..., colN) 
select 'john', col1, col2, ..., colN from source1 

и так далее.

Вы можете сделать snapshots_*, чтобы иметь столбец IDENTITY, который создаст «новый ПК», и который также может сохранить старый, если вы того пожелаете.

У этого (почти) нет проблем с блокировкой и много выглядит.

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

Это также облегчает очистку и техническое обслуживание вопросы

---8<------8<------8<---outdated answer---8<---8<------8<------8<------8<---

Почему вы не просто взять живую резервную копию и делать манипуляции с данными (ключ изменяющуюся) на клоне назначения?

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

Вы не говорите, сколько ваша БД будет занимать, но вы можете, конечно, резервное копирование 20 миллионов строк (800MB?) В течение примерно 10 секунд, в зависимости от того, как быстро вашей дисковой подсистемы ...