Мы перемещаем нашу нетривиальную базу данных SQL Server [65Gib] на новый сервер.
В дополнение к этому мы переходим на SQL Server 2008 R2 с SQL Server 2005, и в идеале нужно потратить некоторое время на выполнение ALTER для перемещения различных таблиц в разные файловые группы.
Традиционный нож будет:
Я бы хотел предварительно загрузить как можно большую часть трансфера; есть ли хороший [простой] способ скопировать действующую версию базы данных и продолжить обновление целевого сервера, пока не будут выполнены все подготовительные работы? Мне пришло в голову, что я мог бы использовать репликацию, но я не знал, смогу ли я затем повысить репликацию Slave до Master ...
Или я ошибаюсь, пытаясь переключить серверы и версии программного обеспечения одновременно?
65 ГБ действительно тривиально, но, возможно, этого не хватит при копировании через медленную локальную сеть или если вы не можете позволить себе несколько минут простоя.
Самый быстрый способ переключиться (и сделать это простым) - это сделать лог-шип (без режима восстановления) между вашим существующим БД и вашим новый дб.
Вы должны иметь возможность копировать логины и задания агента до отключения и оставлять их отключенными, пока не переместите свой живой трафик.
Не совсем ошибочно переключать серверы и версию sql server одновременно, это зависит от ваших требований. Просто помните, что перевод базы данных в оперативный режим на sql server 2008 R2 - это односторонний процесс, который обновит файлы данных при первом восстановлении базы данных, и пути назад нет!
Другой ваш не такой простой вариант - это сделать следующее:
Вероятно, существует множество вариантов вышеуказанных подходов. Мораль этой истории состоит в том, что вы должны учитывать стоимость переключения и стоимость простоя. Это компромисс.
Вы можете отсоединить свою базу данных от старого сервера, скопировать физические файлы и прикрепить их к новому; он с радостью присоединится к другой версии SQL Server, и если вы уже перенесли логины (используя один из предложенных методов), все будет работать мгновенно.
Создание полной резервной копии базы данных и резервной копии журнала (и, при желании, сжатие базы данных) перед переносом поможет уменьшить размер копируемых файлов.
Эта статья включает несколько хранимых процедур, которые упрощают перенос логина.
http://support.microsoft.com/kb/918992
Он также поддерживает исходный sid для входа в систему, поэтому пользователям вашей базы данных не потребуется sp_change_users_login для сопоставления sid нового входа с тем, что хранится в пользовательской db.
Я бы сделал резервную копию / восстановление с ПОЛНОЙ резервной копией накануне вечером или около того, а затем сделал бы дифференциальное резервное копирование / восстановление днем. Я бы не стал копировать МДФ и ЛДФ. Раньше я переносил таким образом базы данных размером около 400 ГБ на диске.
Мгновенная инициализация файлов для MDF делает это довольно быстро
Логины я бы уже написал и применил, настроил и отключил задания и т. Д.
Зеркальное отображение базы данных будет работать в разных версиях SQL. Я сделал именно то, что вы пытаетесь сделать, используя зеркальное отображение базы данных и предварительно перенеся логины. Уловка заключается в том, что вам нужно настроить зеркалирование БД с помощью t-sql, графический интерфейс не примет его, также вы не можете вернуться, поэтому сделайте полную резервную копию своей БД непосредственно перед тем, как вы захотите обрезать, отключите зеркало, выполните процедуру sp_change_users_logins 'Update_One' 'user' 'user', чтобы синхронизировать ваши новые логины с пользователями, существующими в базе данных, и все готово. Перенос БД любого размера менее чем за 10 секунд. Даже меньше, если у вас все это написано по сценарию.
Почему бы вам не скопировать MDF и LDF при выполнении восстановления? В нашей базе ок. 350 ГБ в