Перенос базы данных 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.