Перенос баз данных MS Sharepoint Server с одного MS SQL на другой
 

Добрый день.
Публикую краткую инструкцию по переносу баз данных MS Sharepoint Server с одного MS SQL на другой (больше для себя, чтобы не забыть, но, может, кому и понадобится).
Я руководствовался инструкцией по вот этой ссылке, но по дороге образовалось несколько подводных камней.

Первое: инструментарий. Безусловно, самый удобный инструмент - SS Management Studio. Но тут кроется засада №1. SSMS надо использовать в строгом соответствии с версией SQL сервера. Если 2017-й, то 18-ю версию SSMS. Если 2019-й, то 19-ю (на днях вышла 20-я, но я её ещё не успел попробовать).
Если переносить базы 2017-го сервера 19-й версией - могут возникнуть неприятные артефакты.
Да, конечно же, донорский и целевой SQL-сервера должны быть одной версии.

Второе: бэкапы. Тут ничего особого говорить не буду: если вы их не делаете перед такими операциями, вам не нужно этим заниматься.

Третье (очевидное): всё надо делать пользователем, входящим в группу "Администраторы", которому на обоих серверах присвоены роли db_backupoperator и db_owner.


Итак. Действие первое (после бэкапов) - останавливаем все службы Sharepoint, IIS и Project Server (если есть). Если что-то не остановите - у вас не отцепятся от SQL сервера базы. Страшного ничего не случится - просто ищите неостановленные службы и пробуйте заново отцепить базы.

Действие второе: отцепляем базы от сервера с помощью SSMS (перечень баз можно увидеть в консоли SharePoint-а командой Get-SPDatabase). Тут есть альтернатива: можно воспользоваться встроенным в SSMS мастером копирования баз. Но он требует поднятого на целевом сервере агента MS SQL. Я делал и так, и так - показалось надёжнее детачить их руками. Хотя бы потому, что нет опасности перепутать в дальнейшем базы на разных серверах.

Действие третье: копируем базы с донорского сервера на целевой. Обычным файловым копированием. На каждую БД должно быть два файла - .mdf и .ldf.

Действие четвёртое: копируем имена входа.
По этой ссылке можно найти скрипт переноса имён входа и паролей. Он довольно сложен, создаёт хранимые процедуры на донорском сервере, что на продакшене делать страшновато.
Как показала практика, он имеет смысл для переноса только имён входа с SQL-аутентификацией. Доменные имена входа можно (и проще) создать руками на новом сервере, беспокоиться за их гранты не надо - они приедут в файлах БД. Ну или у вас стопицот имён входа - тогда гоните скрипт.
В моём случае было 2 реальных пользователя и 6 служебных SharePoint - создал руками.

Действие пятое: аттачим в SSMS базы к новому серверу. Ничего сложного, просто долго и муторно кликаем.

Действие шестое и самое интересное. Сопоставление имён серверов на сервере Sharepoint. В вышеуказанной методичке рекомендуется с помощью утилиты клиента SQL Server cliconfg.exe создать псевдоним - чтобы при обращении к <OLDSQL> подставлялось <NEWSQL>. Это рабочее решение, но мне оно не показалось красивым.
Поэтому я поменял имя сервера в конфигах Sharepoint руками: в C:\ProgramData\Microsoft\SharePoint\Config\ нашёл контекстным пользователем три XML файла со строками connectionString">Data Source=<OLDSQL> и поменял там содержимое на <NEWSQL>. Подозреваю, что хватило бы одного, но правил во всех.
Возможно, это ещё обнаружится в C:\Program Files\AppFabric 1.1 для Windows Server\DistributedCacheService.exe.config - там тоже надо поменять.
Ну и вообще прошерстить регистри поиском <OLDSQL> не вредно будет.

После этого перегружаем сервер Sharepoint и, если мы всё сделали правильно, радуемся.