Каков наилучший способ переместить 20+ баз данных на новый сервер баз данных? SQL 2005

Текущий сервер базы данных: SQL Server 2005 - Windows Server 2003 Новый целевой сервер базы данных: SQL Server 2005 - Windows Server 2003 Enterprise - образ виртуальной машины

Текущий сервер баз данных имеет более 20 баз данных, некоторые базы данных приложений... другие базы данных типа Infastructure (Citrix). Мы хотим переместить все эти базы данных в новый, недавно созданный виртуальный блок.

Таким образом, в дальнейшем - да, это физически или виртуально. - 20+ баз данных перенесены в этот новый виртуальный ящик SQL 2005. - приложения на этой коробке требуют минимального времени простоя.

Несколько подходов, которые я могу придумать (все будут проверены): 1. Сторонние физические в виртуальные преобразователи - затем выключите старый блок.
- значения = ассоциации SID, Windows или SQL Server не нравится это.

  1. Перенесите все базы данных сразу на новый сервер - выключите старый сервер, измените имя хоста в новом виртуальном окне на старое имя хоста.

  2. Переместить все сразу, но использовать другое имя хоста для нового блока - это позволяет параллельную работу в случае, если что-то сломается - challenge = должен изменить имя хоста в каждом приложении - могут возникнуть проблемы.

  3. Перемещайтесь по каждой базе данных поэтапно - это будет означать и новое имя хоста, и более длинный и более продолжительный проект.

У кого-нибудь еще есть подобный сценарий?

5 ответов

Мы перешли с одного сервера SQL на новый кластер SQL (все новое оборудование). Около 70 баз данных. Мы сделали так, чтобы отделить базы данных, скопировать файлы, а затем прикрепить базы данных к новым узлам SQL.

Мы были вынуждены обновить имена хостов, но я перевел бы старый в автономный режим и использовал бы то же имя хоста. Вы всегда можете переключиться обратно таким же образом.

Один из способов минимизировать время простоя - использовать доставку журналов с одного сервера на другой. Это требует повторного указания конфигураций приложения, но имеет преимущество, заключающееся в меньшем времени простоя. В общем, процесс выглядит следующим образом:

  1. Создайте новый сервер и переместите задания / логины / службы SSIS и т. Д.
  2. Настройте исходную базу данных для доставки журналов и начните отправку.
  3. Остановите приложение (я) и установите DB только для чтения.
  4. Создайте резервную копию последнего журнала транзакций для базы данных.
  5. Восстановите последний журнал входа в систему на новом сервере, установите no-recovery.
  6. Установите новую базу данных в режим чтения / записи.
  7. Верните повторную заявку в онлайн.

Пара замечаний:

  • DB Mirroring - аналогичное решение.
  • Репликация уровня SAN также схожа, но требует специальных сетей SAN (например, HP EVA).

Плюсы:

  • Минимальное время простоя.
  • Доставка журналов довольно проста в настройке.
  • Откатить план довольно просто.

Минусы:

  • Больше ручных шагов.
  • Нужно проверить приложение, чтобы убедиться, что оно правильно переписано (больше работает администратор sys /DBA).

Итак, есть компромисс, но этот метод работает, и это достаточно распространенная техника.

Эрик -

Если у вас есть несколько долларов, чтобы потратить, например, 300,00 или около того, проверьте набор инструментов Idera Admin. Отличная часть программного обеспечения. Я использовал это в недавнем проекте. Он перемещал базы данных и любые связанные объекты, включая пользователей. Это стоило того. В 3 клика я переместил все свои базы данных. Я до сих пор использую его для перемещения баз данных туда-сюда. Я считаю, что у них есть пробная версия. Также вы получаете множество других инструментов, таких как перемещение пользователей или объектов по базам данных и т. Д.

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

Я бы порекомендовал использовать параллельную настройку для тестирования каждого приложения, но, как только тест будет удовлетворен, я, вероятно, воспользуюсь Detach/Attach: как переместить базы данных SQL Server в новое место с помощью функций Detach и Attach в SQL Server.

Из моего опыта p2v - отличный и быстрый вариант, но не идеальный, если вы хотите минимизировать время простоя. Я бы использовал его только тогда, когда существующие серверы не беспорядок, а виртуализация только для рационализации оборудования. (т. е. вы не переименовываете коробку, а помещаете ее в новый объект AD).

SQL Server и Windows будут в порядке, если вы используете p2v, но перед запуском p2v вам потребуется остановить службы SQL Server. Эффект Windows SID останется неизменным, что не нравится окнам - физическим и виртуальным серверам, подключенным к одной сети.

Если вы используете метод присоединения / отсоединения, убедитесь, что вы также скопировали:

  • логины сервера sql
  • Задания агента сервера SQL (включая задания резервного копирования)
  • связанные серверы
  • расширенные хранимые процедуры

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

Другие вопросы по тегам