У нас есть старый сервер SQL 2000, назовем его «oldSQL2K», а новый сервер SQL 2008, назовем его «newSQL2K8». Оба находятся в производстве. oldSQL2K имеет около 90 пользовательских баз данных, к которым имеют доступ как люди через соединения ODBC, так и приложения через логины SQL.
Мне нужен совет о том, как лучше всего продолжить миграцию баз данных со старого SQL2K на новый SQL2K8.
Я вручную перенес около дюжины баз данных, сделав резервную копию SQL на старой и восстановив SQL на новой. Я уже перенес все логии SQL со старого на новый, так что готово.
В качестве эксперимента я попробовал простое изменение имени DNS, но, конечно же, это не удалось.
Вот проблемы: одно из устаревших приложений, которые мы поддерживаем, «Must Stay Alive» имеет старое имя сервераSQL2000, встроенное в скомпилированный код, а исходный код исчез! Долгая история, не моя вина, а теперь моя проблема. Это приложение работает примерно на 50 рабочих станциях.
Наш сервисный центр выявил около тысячи рабочих станций, на которые этот переход повлияет. Ой.
У нас есть утилита SQL Client Network на упомянутых 50 рабочих станциях, и обновление псевдонима там действительно работает. Однако я бы хотел избежать установки его на другие рабочие станции и серверы, если это вообще возможно.
Итак, ребята, как бы вы продолжили эту миграцию, если бы это были вы?
Я бы мигрировал так же, как и вы, но изолировал те приложения, которые «должны оставаться в живых», которые не могут быть легко изменены, и оставил их на старом сервере. Затем виртуализируйте сервер SQL2000, если у вас есть среда виртуальной машины. Старое приложение, вероятно, не выиграет от перехода на SQL2008, если только у вас не возникнут проблемы с производительностью и вам не потребуется больше ресурсов для обработки, а виртуальная машина будет постоянным напоминанием о плохих приложениях, которые действительно следует заменить.
Виртуализация того, что осталось, - вполне разумная идея ... в качестве альтернативы вы можете переместить их в SQL Server 2008 (после проверки, что они все еще работают) и использовать магию DNS для перенаправления. Я видел это много раз - работает, хотя и не так чисто.
Раньше я сталкивался с подобными «ловушками-22», и был применен подход к переходу на другой сервер SQL 2000, который можно легко изменить, но нельзя обновить до 2008, и как только вы перейдете к паре приложений ( как тот, который вы упомянули), где имя сервера не может быть изменено, мы удалили старый сервер из домена и отключили его, вставив заглушку в псевдоним DNS, указывающий на новый сервер SQL. Использование изолированной сети помогает решить все проблемы, с которыми вы столкнетесь при настройке производства, но при этом ничего не нарушит.
Если у вас есть изолированная сеть (или вы можете ее создать), где вы можете дублировать имена серверов и иметь хотя бы одного клиента для тестирования, я бы использовал это для оценки. Это позволит вам проверить псевдоним DNS. Скопируйте резервную копию для каждой данной базы данных и восстановите ее до SQL 2008 x64 или любой другой версии / архитектуры, которой будет ваш prod-сервер, и протестируйте с разными уровнями совместимости для каждой базы данных.
Надеюсь, это поможет с некоторыми идеями!