Как мне переместить весь экземпляр SQL для SQL Server 2012 на другой сервер?

Я пробовал это с SQL Server 2012, без радости:

Как я могу скопировать экземпляр SQL Server 2008 на другой сервер ?

SQL не запускался на целевом сервере, он сначала жаловался на невозможность записи в файлы журнала ошибок, а теперь он жалуется на внутреннюю ошибку.

Я думаю, это, вероятно, проблема ACL / прав, но безопасность выглядит так же, все, что я сделал, это перезаписал существующий каталог установки SQL каталогом SQL с исходного сервера.

Исходный сервер - Windows 2008 R2, целевой сервер - Windows 2012 R2, если это имеет какое-то значение

Да, я знаю, как это сделать, используя метод sp_help_revlogin, но у нас много пользователей, и я не хочу приходиться бегать ко всем и узнавать их пароль

Это ПРОСТАЯ операция с MSql, почему в чертогах MS приходится вставлять всевозможные скрытые права и мусор в свою файловую систему? Когда SQL-сервер выключен, база данных должна быть просто другим файлом IMHO.

Кроме того, если SQL-сервер когда-либо делает дамп, мне бы очень хотелось, чтобы мне не приходилось восстанавливать все 600 ГБ из резервной копии, если я могу просто восстановить 80 ГБ в файлах базы данных SQL, вы знаете?

-1
задан 17 July 2017 в 23:44
3 ответа

SQL DBA здесь. Я думаю, вы неправильно понимаете, как работает sp_help_revlogin : http://support.microsoft.com/kb/918992

Это набор сценариев, которые вы запускаете на исходном сервере, вывод будет быть большим длинным скриптом для воссоздания всех логинов, включая (зашифрованные) пароли .

Возьмите этот скрипт и запустите его на целевом сервере, он воссоздаст все логины, а ваши восстановленные ( или прикреплены) базы данных должны их легко распознавать.

5-минутный процесс, максимум, если только вы не хотите просмотреть список вывода и включить / исключить отдельные логины.

Я не знаю, что вы застряли с копированием вся папка заполнена файлами SQL, возможно, вам придется перемотать туда шаг или два, если вы не просто перезаписали файлы из только что установленного экземпляра.

Я предпочитаю следующий метод:

  1. Получить новый SQL экземпляр, запущенный из чистой установки
  2. Копирование MASTER возможно, но очень сложно. Честно говоря, единственной системной базой данных, которую я бы скопировал, будет MSDB (для сохранения запланированных заданий) или просто скопировать их из старого ящика и воссоздать их.
  3. Для пользовательских баз данных выполните резервное копирование / восстановление из старого или скопируйте только файлы данных (mdf, ndf) и журналов (ldf) в новое окно и прикрепите их.

Удачи. Вы также можете найти более подробную справку на dba.Stackexchange.com.

2
ответ дан 5 December 2019 в 19:07

Ваши базы данных ЯВЛЯЮТСЯ «просто» файлами. Если вы щелкните правой кнопкой мыши базу данных в SSMS и выберите свойства, вы сможете найти эту информацию. Обычно это файл базы данных (.mdf) и журнал транзакций (.ldf).

Я думаю, что вы ошиблись в том, что вы не должны копировать все содержимое пути установки. Вместо этого вы должны копировать только файлы .mdf и .ldf обратно в то же место, что и на исходном сервере.

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

Когда дело доходит до резервного копирования и восстановления - ДА, вы можете просто восстановить файлы .mdf и .ldf. Но различные методы резервного копирования и восстановления SQL - это уже другая тема.

Конечно, при всем этом вам необходимо убедиться, что служба SQL-сервера остановлена ​​или база данных отключена.

1
ответ дан 5 December 2019 в 19:07

Я думаю, что это, вероятно, проблема ACL / прав, но безопасность выглядит так же, все, что я сделал, это перезаписал существующий каталог установки SQL каталогом SQL с исходного сервера.

Почему не «Разве вы просто создаете резервную копию и восстанавливаете базы данных?»

Почему MS должна вбивать все виды скрытых прав и мусора в свою файловую систему? Когда SQL-сервер выключен, база данных должна быть просто другим файлом IMHO.

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

Также, если SQL-сервер когда-либо сделает дамп, мне бы очень хотелось, чтобы не приходилось восстанавливать все 600 ГБ из резервной копии image, если я могу просто восстановить 80 ГБ в файлах базы данных SQL, понимаете?

Конечно, это легко сделать, но сначала вы должны знать, что делаете.

Ни в чем из этого нет ошибки SQL Сервер или Microsoft.

1
ответ дан 5 December 2019 в 19:07

Теги

Похожие вопросы