Перемещение базы данных SQL Server на новый диск в режиме онлайн

У меня есть база данных SQL Server 1,4 ТБ, которая очень сильно борется с дисковым вводом / выводом. Мы установили новый массив SSD на сервер, который решит все наши проблемы, мы просто обсуждаем лучший способ перемещения базы данных. В идеале, если мы можем сделать это без простоя, это лучше. Но если выбор между двумя днями низкой производительности (например, при копировании данных) или двумя часами простоя, последний может быть предпочтительнее.

Итак, решения, которые мы придумали:

• Простая копия. Переведите БД в автономный режим, скопируйте файлы, измените расположение в SQL Server и верните его в оперативный режим. По приблизительным подсчетам, это займет до пяти часов, что не совсем приемлемо, но это самое простое решение.

• Блок-копия. Используя утилиту, похожую на rsync, мы копируем файлы в фоновом режиме, пока работает БД. Когда мы будем готовы к миграции, мы переводим БД в автономный режим, делаем разностное копирование с помощью этой утилиты, затем указываем серверу SQL на новые файлы и переводим их в оперативный режим. Время здесь неизвестно. Мы не знаем, сколько времени потребуется, чтобы провести дифференциальный анализ в 1,4 ТБ и скопировать его. Другая наша проблема заключается в том, что при копировании на уровне блоков файлы в каком-то состоянии останутся нечитаемыми для SQL Server, и мы потратим впустую наше время.

• Миграция SQL. Создайте новый файл данных 1.4TB SQL на новом диске и отключите авторазраст для всех остальных файлов. Затем запустите DBBC SHRINKFILE (-file_name-, EMPTYFILE) для всех остальных файлов данных по очереди. После того как все данные пройдены, я в определенный момент возьму запланированное окно, чтобы переместить файл MDF на SSD и удалить другие неиспользуемые файлы. Мне это нравится, потому что это минимизирует время простоя. Но я понятия не имею, сколько времени это займет и не приведет ли это к снижению производительности, пока это происходит.

У нас нет какой-либо среды загрузки и производительности, чтобы проверить это. Я могу убедиться, что стратегии будут работать в нашей промежуточной среде, но не влияние и не производительность.

Одним из способов перемещения всей базы данных является использование 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.