Azure - копирование существующей базы данных SQL на другой сервер с использованием Transact-SQL и SSMS

Question

У меня есть две подписки на Azure, для простоты аргументации, давайте назовем их subscription1 и subscription2.

У меня есть база данных SQL размером 30 ГБ для подписки 1, и я хочу переместить ее в подписку2.

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

Итак, я придумал использовать подход Transact-SQL, как описано в этой статье

Используя SSMS, я использую следующую команду в главной базе данных конечного сервера (server2), чтобы скопировать базу данных с исходного сервера (server1 в подписке1) на конечный сервер (server2 в подписке 2)

CREATE DATABASE Database2 AS COPY OF server1.Database1;

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

У меня вопрос: когда я буду копировать свою базу данных размером 30 ГБ, как было упомянуто выше, с использованием подхода Transact SQL, будет ли она использовать мою пропускную способность интернета или пропускную способность лазурных центров обработки данных, как при использовании опции копирования с портала

Answer 1

Команда T-SQL, на которую вы ссылаетесь, не будет проходить через ваш компьютер. Он переходит с сервера 1 на сервер 2. Это концептуально эквивалентно выполнению команды T-SQL на портале Azure.

Пройдя еще на один уровень, портал и команда DDL T-SQL в SQL Azure направляются через REST API уровня управления в регионе. Вы можете увидеть документацию по данному вопросу здесь:

https://docs.microsoft.com/en-us/rest/api/sql/databases/createorupdate

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

Еще на один уровень глубже - логика выполнения всего этого заполнения более или менее идентична логике, необходимой внутренне для SQL Azure для создания новой реплики вашей базы данных. В премиальных / больших размерах резервирования у вас будет N копий локально каждой базы данных для обеспечения высокой доступности и производительности, и, если один узел реплики выйдет из строя (аппаратный сбой и т. Д.), Системе внутренне потребуется создать новую непрерывную копию остальные реплики, чтобы восстановить нужное количество резервных копий для вашей базы данных.

Одна последняя деталь - в отличие от традиционных команд SQL Server, она асинхронная. Итак, после отправки команды все остальное происходит в фоновом режиме. Таким образом, как упоминает @Nick.McDermaid, вы можете отключить локальный компьютер после запуска команды и проверить его позже, не беспокоясь о том, что транзакция отменена и откатана. Единственная дополнительная проблема заключается в том, что вам необходимо проверить выполнение команды, которая может занять некоторое время в зависимости от размера базы данных, размера используемой вами резервирования (которая управляет IOPS) и т. Д.