Раньше я перемещал базы данных почти постоянно из-за реконфигурации SAN и миграций.
Предполагая, что вы перемещаете целый сервер за раз, я бы выбрал что-то вроде вашего пути # 2. (Если вы перемещаете одну базу данных за раз и в конечном итоге делаете каждую базу данных на сервере, это будет более проблематично, поскольку вам придется менять пути к файлам.)
Обратите внимание, что «single_user» не обязательно означает «ВЫ». Вы можете перейти к базе данных DBCC CHECKDB и не сможете войти, потому что там уже кто-то есть. Подготовьте сценарий, который вы можете запустить, чтобы загрузить «всех, кроме вас», из базы данных и сохранить его в удобном месте. Обратите внимание, что SQL 2000 не обладает такими же возможностями «держать всех», как в более современных версиях.
Одна старая хитрость - приостановить службу SQL Server. Это предотвратит новые входы в систему, но любой, кто уже подключен, может продолжить работу как обычно. Итак: подключитесь через окно SSMS, чтобы вы могли выполнить работу, затем приостановите службу, затем отключите нежелательные подключения, выполните свои действия через командное окно SSMS (не GUI, оно устанавливает и разрывает много подключений), а затем отмените паузу сервис. Предупреждение: я не уверен, как это отразится на кластере. Это может хотеть аварийного переключения.
Удобно иметь возможность держать всех пользователей приложения вне сервера, пока вы не закончите свою работу. В противном случае соединения могут начать появляться, когда вы пытаетесь что-то сделать, что может привести к конфликту ресурсов и / или замедлению работы. В прошлом я использовал следующие способы, в зависимости от конкретной ситуации: Отключение серверов приложений. Использование ALTER DATABASE .. SET RESTRICTED_USER (Если учетные записи приложений являются членами ролей db_owner, sysadmin или dbcreator, это проблема. ) Говорить пользователям, что система будет отключена в определенное время, например, в воскресенье утром. (Это не будет работать в «реальной» среде 24x7.) Отключите сетевой адаптер, с которым сталкиваются серверы приложений или пользователи. (В этом случае я мог бы войти через другой сетевой адаптер, подключенный к сети только для администратора или через МОТ.)
Отсоединение большого количества баз данных и их повторное присоединение может быть большой работой. Если вы сделаете это, убедитесь, что у вас есть скрипт «attach», написанный заранее.
Я имел большой успех, останавливая SQL Server, копируя все, меняя буквы дисков и запуская SQL Server. Нет отсоединения / прикрепления. Пока SQL Server выключен и вы копируете (не перемещаете) файлы, вы не можете столкнуться с большими проблемами, даже если вы перемещаете системные базы данных. Поскольку пути одинаковы, SQL Server не поймет, что ничего не изменилось, пока служба была отключена. Просто убедитесь, что буквы дисков указаны в правильных объемах, иначе все пойдет не так, как надо.
Моя самая частая проблема заключалась в неправильном получении ACL на файловых каталогах. Более современные версии SQL Server лучше устанавливают только те разрешения, которые необходимы учетной записи службы, тогда как более старые версии кажутся менее суетливыми. Если вы забыли установить ACL, а учетная запись службы не является локальным администратором (не то, чтобы я рекомендовал это сделать), одна или несколько баз данных могут не открыться при запуске экземпляра. Не паникуйте, просто измените ACL и прикрепите базу данных.
Я обычно использую ROBOCOPY для такой работы. Для сохранения ACL есть ключ командной строки.
Использование вычисления / проверки CRC - неплохая идея, но я никогда этого не делал. Когда базы данных возвращаются, я запускаю CHECKDB () для всех из них. Я обычно готовлю сценарий для этого раньше, чем полагаться на ручную работу по обслуживанию. Таким образом, я могу проверить пару небольших баз данных, прежде чем проверять большую базу данных, которая может занять много минут или часов. Я сомневаюсь, что проверка CRC (или средство сравнения данных Redgate) найдет что-то, что CHECKDB () пропустит, и если это произойдет, SQL Server не сможет это исправить.
После того, как я скопирую файлы, но перед тем, как перезапустить экземпляр, я пойду и немного изменю путь к файлу старых папок, переименовав одну из папок. Это дополнительная проверка в отношении проблемы «упс, сервер все еще указывает на старые файлы».
Не спешите отбрасывать старые файлы и восстанавливать место на старом хранилище, а также удостовериться, что ваши полные резервные копии успешно выполнены. Тест восстановить пару этих резервных копий в другом месте. Если у вас есть хорошие проверки checkdb () и хорошие полные резервные копии, вы можете подумать о том, чтобы сбросить это старое хранилище и закрыть левую руку.
Наихудшие проблемы, с которыми я столкнулся при этих миграциях, произошли после того, как я подумал, что все кончено. Это будет администратор SAN, который скажет мне, что что-то случилось, и мои файловые системы были взломаны. (Переписано, переформатировано, скопировано снова.)
Еще одна забавная проблема - медленный SAN без видимой причины. Если вы считаете, что копирование ваших данных займет 10 часов, и вы скопировали 30% на 9-м часе, у вас есть проблема. Наблюдайте за временем передачи (robocopy показывает скопированный% и дает оценки времени, или вы можете использовать Perfmon) и иметь запасной план, если что-то пойдет не так.
Кроме того, я не уверен, что ваши тома будут разделены для вас, но вы можете быть уверены, что они используют смещение в 1 МБ. На Windows Server 2008 и выше, это не должно быть проблемой. На старых ОС это так. Здесь есть масса вещей, которые можно найти в Google, и ваши парни из хранилища должны знать об этом, но я бы спросил.