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

Question

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

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

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

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

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

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

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

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

Answer 1

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

Answer 2

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

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

и так далее.

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

Это (почти) не имеет проблем с блокировкой и выглядит более разумно.

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

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

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

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

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

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