ProHoster > блог > Администрација > Пренесување резервни податоци од нова верзија на MS SQL Server на постара верзија

Пренесување резервни податоци од нова верзија на MS SQL Server на постара верзија

праисторијата

Еднаш, за да репродуцирам грешка, ми требаше резервна копија од базата на податоци за производство.

На мое изненадување, наидов на следниве ограничувања:

  1. Резервната копија на базата на податоци беше направена на верзијата SQL Server, 2016 и не беше компатибилен со мојот SQL Server, 2014.
  2. На мојот работен компјутер, оперативниот систем што се користеше беше Windows 7па не можев да ажурирам SQL Server, до верзијата 2016 година
  3. Поддржаниот производ беше дел од поголем систем со цврсто поврзана стара архитектура и исто така зборуваше со други производи и бази, така што може да потрае многу долго време за да се распореди на друга станица.

Со оглед на горенаведеното, дојдов до заклучок дека е дојдено време за патерици од нестандардни решенија.

Враќање податоци од резервна копија

Избрав да користам виртуелна машина Oracle VM VirtualBox со Windows 10 (можете да направите тест слика за прелистувачот Edge оттука). SQL Server 2016 беше инсталиран на виртуелната машина и базата на податоци на апликациите беше вратена од резервна копија (настава).

Конфигурирање на пристап до SQL Server на виртуелна машина

Следно, беше неопходно да се преземат некои чекори за да може да се пристапи до SQL Server однадвор:

  1. За заштитниот ѕид, додајте правило за прескокнување на барањата за порти 1433.
  2. Пожелно е пристапот до серверот да не оди преку автентикација на Windows, туку преку SQL со користење најава и лозинка (полесно е да се постави пристап). Меѓутоа, во овој случај, треба да запомните да овозможите SQL автентикација во својствата на SQL Server.
  3. Во корисничките поставки на SQL Server на јазичето Корисничко мапирање наведете ја корисничката улога за обновената база на податоци db_securityadmin.

Пренос на податоци

Всушност, самиот пренос на податоци се состои од две фази:

  1. Пренос на шеми на податоци (табели, прегледи, складирани процедури, итн.)
  2. Пренесување на самите податоци

Пренос на шема на податоци

Ги извршуваме следните операции:

  1. изберете Задачи -> Генерирање скрипти за пренослива основа.
  2. Изберете ги објектите што треба да ги префрлите или оставете ја стандардната вредност (во овој случај, ќе се креираат скрипти за сите објекти на базата на податоци).
  3. Наведете ги поставките за зачувување на скриптата. Најпогодно е да се зачува скриптата во една датотека на Уникод. Потоа, во случај на неуспех, не треба повторно да ги повторувате сите чекори.

Откако ќе се зачува скриптата, може да се изврши на оригиналниот SQL Server (стара верзија) за да се создаде потребната база.

Предупредување: По извршувањето на скриптата, треба да ја проверите кореспонденцијата помеѓу поставките на базата на податоци од резервната копија и базата на податоци создадена од скриптата. Во мојот случај, немаше поставка за COMLATE во сценариото, што доведе до неуспех при пренос на податоци и танцување со тамбура за да се рекреира базата на податоци користејќи ја дополнетата скрипта.

Пренос на податоци

Пред да префрлите податоци, мора да ја оневозможите проверката на сите ограничувања на базата на податоци:

EXEC sp_msforeachtable 'ALTER TABLE ? NOCHECK CONSTRAINT all'

Преносот на податоци се врши со помош на волшебникот за увоз на податоци Задачи -> Увези податоци на SQL Server, каде што се наоѓа базата на податоци создадена од скриптата:

  1. Наведете ги поставките за поврзување со изворот (SQL Server 2016 на виртуелна машина). Користев извор на податоци Мајчин клиент на SQL Server и гореспоменатата SQL автентикација.
  2. Наведете ги поставките за поврзување за дестинацијата (SQL Server 2014 на машината домаќин).
  3. Следно, поставете го мапирањето. Сите мора да бидат избрани не само за читање објекти (на пример, погледите не треба да се избираат). Како дополнителни опции, изберете „Дозволи вметнување во колони за идентитет“доколку се користат такви.
    Предупредување: ако, кога се обидувате да изберете неколку табели и да го поставите нивниот имот „Дозволи вметнување во колони за идентитет“ својството е веќе поставено за барем една од избраните табели, дијалогот ќе покаже дека имотот е веќе поставен за сите избрани табели. Овој факт може да биде збунувачки и да доведе до грешки при миграцијата.
  4. Го започнуваме трансферот.
  5. Враќање на проверка на ограничувања: 
    EXEC sp_msforeachtable 'ALTER TABLE ? CHECK CONSTRAINT all'

Ако се појават грешки, ги проверуваме поставките, ја бришеме базата на податоци создадена со грешки, повторно ја креираме од скриптата, правиме корекции и го повторуваме преносот на податоците.

Заклучок

Оваа задача е доста ретка и се јавува само поради горенаведените ограничувања. Највообичаеното решение е да се надгради SQL Server или да се поврзе со оддалечен сервер доколку архитектурата на апликацијата го дозволува тоа. Сепак, никој не е имун од наследниот код и кривите раце на неквалитетниот развој. Се надевам дека нема да ви треба оваа инструкција, но ако сепак ви е потребна, ќе помогне да заштедите многу време и нерви. Ви благодариме за вниманието!

Список на користени извори

Извор: www.habr.com