Должен ли я переносить данные с помощью отсоединения / копирования / вложения или резервного копирования-восстановления-воспроизведения?


17

Я собираюсь приступить к переносу файлов базы данных в новую SAN (из старой SAN), и у меня есть несколько вариантов для реализации этого. (1) Было предложено изучить уровень восстановления полной резервной копии в новой базе данных на сервере. Однако (2) мой первоначальный план состоял в том, чтобы скопировать файлы из старого SAN в новый SAN, отсоединив и снова подключив базу данных.

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

Я предполагаю, что мой вопрос заключается в том, оправдан ли я в моем скептицизме выбора BACKUP-RESTORE-Replay и каковы другие достоинства или риски этого варианта?

Ответы:


16

Лично я бы избегал механизмов отсоединения / прикрепления. Особенно в SQL Server 2000, я просто не верю, что вы всегда включите сервер и сможете прикрепить эти файлы. Я слышал много историй, где это не произошло чисто - только потому, что у вас есть План Б, автоматически не делает План А разумным.

При резервном копировании / восстановлении вы не рискуете перейти к Плану B. Если резервное копирование завершится неудачно, ваша база данных все еще работает. Если восстановление не удалось, ваша старая база данных все еще работает. В обоих случаях вы можете восстановить работу исходной базы данных и вернуться к плану позже. В дополнение к дополнительной безопасности, связанной с остановкой SQL Server и / или отключением, это также означает, что вы можете проверить исправность методологии резервного копирования / восстановления (при условии, что у вас есть место для выполнения резервного копирования и еще один экземпляр для проверки восстановить). Вы не можете реально протестировать подход к отсоединению, не отключая базы данных и не останавливая SQL Server, и это сложно сделать за пределами надлежащего окна обслуживания. И, наконец, с другими подходами вы не можете даже начать копировать файлы, пока не отключите или не отключите SQL Server.

Еще одно преимущество по сравнению с методом извлечения диска из-под SQL-сервера: с помощью резервного копирования / восстановления вы можете перемещать различные файлы на разные буквы дисков, чем они были раньше. Например, когда мы мигрировали в новую сеть SAN, у нас было больше томов, поэтому мы могли переместить базу данных tempdb в T: \ (которой раньше не было), некоторые данные и файлы журналов на новые буквы дисков и т. Д. чтобы лучше использовать все новые возможности ввода / вывода, которые у нас были. Если вы просто выключаете SQL Server, а затем меняете диски, у вас должны быть одинаковые буквы дисков и одинаковое количество томов.


7

Раньше я перемещал базы данных почти постоянно из-за реконфигурации 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, и ваши парни из хранилища должны знать об этом, но я бы спросил.


2

Сначала я хотел бы рассмотреть возможность простого использования функции массива хранения для обработки перемещения данных. Если они недоступны из-за того, что поставщик не поддерживает их, вы их не приобрели или администратор SAN не знает, как это сделать ...

Тогда я бы просто использовал следующие шаги.

  1. Представьте новое хранилище серверу SQL.
  2. Остановите службы SQL
  3. Скопируйте все данные со старого диска на новый диск (не забудьте включить разрешения при использовании robocopy)
  4. Удалите буквы дисков из старых дисков.
  5. Измените буквы дисков на новых дисках в соответствии со старыми буквами дисков
  6. Запустите службы SQL

Вот и все.

Нет необходимости в отсоединении / присоединении, поскольку SQL Server знает, что ничего не изменилось. И если что-то идет не так, как надо, у вас есть старая копия баз данных, расположенная на старом LUN в старом массиве хранения. Отказ - это просто вопрос смены букв дисков.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.