Перенос базы данных SQL Server на новый диск в режиме онлайн
У меня есть база данных SQL Server 1.4TB, которая активно работает с дисковыми вводами /выводами. Мы установили на сервер новый SSD-массив, который решит все наши проблемы, мы просто обсудим лучший способ перемещения базы данных. В идеале, если мы сможем сделать это без простоя, это лучше всего. Но если выбор между двумя днями низкой производительности (например, при копировании данных) в сравнении с двумя часами простоя, последний может быть предпочтительным.
До сих пор решениями, которые мы придумали, являются:
-
Простая копия. Возьмите DB в автономном режиме, скопируйте файлы, измените местоположение на SQL Server и верните его в режиме онлайн. По приблизительным оценкам, это займет до пяти часов, что на самом деле не приемлемо, но это самое простое решение.
-
Блочная копия. Используя утилиту, подобную rsync, мы копируем файлы в фоновом режиме, когда БД работает. Когда мы готовы мигрировать, мы берем DB в автономном режиме, делаем дифференциальную копию с помощью этой утилиты, затем указываем SQL-сервер на новые файлы и выставляем его в Интернете. Сроки здесь неизвестны. Мы не знаем, сколько времени потребуется, чтобы провести дифференциальный анализ 1.4TB и скопировать его. Другая наша проблема заключается в том, что копия на уровне блоков оставит файлы в некотором состоянии, не читаемые SQL Server, и мы будем тратить свое время.
-
Перемещение SQL. Создайте новый файл данных SQL 1.4TB на новом диске и отключите авторазборку для всех других файлов. Затем запустите DBBC SHRINKFILE (-file_name-, EMPTYFILE) по всем другим файлам данных по очереди. После того, как все данные будут пересекаться, я в какой-то момент займу запланированное окно, чтобы переместить MDF-файл на SSD и удалить другие неиспользуемые файлы. Мне это нравится, потому что это минимизирует время простоя. Но я понятия не имею, как долго это будет продолжаться, и приведет ли это к ухудшению производительности, пока это происходит.
У нас нет никакой нагрузки и amp; чтобы проверить это. Я могу проверить, что стратегии будут работать на нашей промежуточной среде, но не на результат, а не на производительность.
2 ответа
Один способ перемещения всей базы данных - это BACKUP
и RESTORE
. База данных будет недоступна во время окончательного переключения, но время простоя должно быть минимальным при планировании. Эта процедура предполагает восстановление FULL
или BULK_LOGGED
модель:
1) Выполните ПОЛНОЕ резервное копирование (или используйте существующий).
2) Восстановите последнюю полную резервную копию для другого имени базы данных, указав опцию WITH MOVE
, чтобы переместить файлы в хранилище SSD по желанию, и NORECOVERY
, чтобы можно было восстановить последующие резервные копии дифференциальных данных и журналов.
3) Применить инкрементные изменения к новой базе данных до момента окончательного завершения с резервными копиями журналов транзакций и RESTORE...WITH NORECOVERY
. Это позволит свести к минимуму время простоя для окончательного перехода к новой базе данных.
4) Чтобы переключиться на новую базу данных, откройте приложение в автономном режиме, выполните окончательную резервную копию журнала транзакций и примените к новой базе данных WITH RECOVERY
. Наконец, переименуйте исходную базу данных на другое имя и переименуйте перенесенную базу данных в исходное имя. Удалите старую базу данных в удобное для вас время.
В модели восстановления SIMPLE вы можете использовать аналогичный процесс, но без резервного копирования /восстановления журнала транзакций в шаге 3. Вместо этого используйте резервное копирование /восстановление дифференциальной базы данных на последнем этапе. Это может потребовать больше времени простоя, в зависимости от количества изменений с первоначальной резервной копии FULL
.
Good approach is to use SQL REPLICATION between two server
once all data replicated on SSD server then take current server offline
and switch to SSD server.