Блог

Я изучал этот проект в поисках решения для параллельного обновления. Наиболее широко предлагаемое / используемое решение — выполнить полную резервную копию базы данных SQL Server 2000 и восстановить ее на SQL Server 2008 с помощью norecovery. Затем восстановите последующие резервные копии журнала транзакций с помощью norecovery. Когда мы будем готовы переключиться, переведите SQL Server 2000 в режим только для чтения, сделайте резервную копию итогового журнала и восстановите его на SQL Server 2008 с помощью recovery. Затем подключите SQL Server 2008 к сети.

Но разве обновление не может быть выполнено с помощью репликации транзакций, где SQL Server 2000 является издателем, а SQL Server 2008 — подписчиком. Создайте скрипт для всех объектов, таких как логины, индексы и т.д., И примените его к SQL Server 2008. Когда мы будем готовы к переключению, мы остановим репликацию, удалим все задания репликации и переключим все приложения для подключения к SQL Server 2008. Я не нашел никого, кто предлагал бы этот метод. С этим что-то не так?

Описанный вами метод переноса данных можно выполнить с использованием репликации SQL Server.

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

Тем не менее, описанный вами метод, безусловно, более технически задействован как в настройке, так и в реализации фактических шагов миграции. Если вы можете смириться с простоями, простой процесс резервного копирования и восстановления, безусловно, будет намного проще. Доставка журналов также была бы другим более простым методом миграции.

Пока что вы знаете, что метод репликации теоретически может работать. Сейчас самое время создать рабочее решение в тестовом режиме, чтобы подтвердить вашу стратегию переноса данных и отработать процесс внедрения.

Если вы не выполняете репликацию иным образом, создание подписки на репликацию изменит вашу схему и некоторые параметры. Например, вы можете в конечном итоге получить GUIDs сгенерированный для всех ваших строк только для облегчения репликации.

Внимание — транзакционная репликация отключит все столбцы ИДЕНТИФИКАТОРОВ у подписчика (SPS транзакционной репликации фактически зависят от этого факта, поскольку они вставляются в столбцы идентификаторов без предварительного указания IDENTITY_INSERT ON). Я могу только подтвердить, что это тот случай, когда подписчиком также является SQL 2000 — возможно, подписчик на 2008 будет вести себя по-другому.

По этой причине репликация транзакций с SQL 2K на самом деле не обеспечивает горячего ожидания. Нам пришлось немного подправить SQL (переустановить столбцы идентификаторов и переписать SPS репликации с помощью оболочек IDENTITY_INSERT), чтобы создать ситуацию, когда подписчик фактически работает в режиме горячего ожидания, готовый к тому, что на него будут указывать приложения. Но это, конечно, не сработало бы из коробки =)

Да, это будет работать, при условии, что вы перенесете другие объекты.