Перанос дадзеных бэкапу новай версіі MS SQL Server на больш старую версію

перадгісторыя

Неяк раз для прайгравання бага мне запатрабаваўся бэкап production-базы.

На маё здзіўленне я сутыкнуўся з наступнымі абмежаваннямі:

  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 Server магчымасць SQL-аўтэнтыфікацыі.
  3. У наладах карыстальніка на SQL Server на ўкладцы Адлюстраванне карыстальнікаў пазначыць для адноўленай базы ролю карыстальніка db_securityadmin.

перанос дадзеных

Уласна сам перанос дадзеных складаецца з двух этапаў:

  1. Перанос схемы дадзеных (табліцы, уяўленні, захоўваемыя працэдуры і г.д.)
  2. Перанос саміх дадзеных

Перанос схемы даных

Выконваем наступныя аперацыі:

  1. выбіраем Tasks -> Generate Scripts для пераноснай базы.
  2. Выбіраемы патрэбныя для пераносу аб'екта ці пакідаем значэнне па змаўчанні (у гэтым выпадку будуць створаны скрыпты для ўсіх аб'ектаў базы).
  3. Указваем налады для захавання скрыпту. Зручней за ўсё захаваць скрыпт у адзіны файл у кадоўцы Unicode. Тады пры збоі не спатрэбіцца зноўку паўтараць усе крокі.

Пасля захавання скрыпту яго можна выканаць на зыходным SQL Server (старой версіі), каб стварыць патрабаваную базу.

Увага: пасля выканання скрыпту неабходна праверыць адпаведнасць налад базы з бэкапу і базы, створанай скрыптам. У маім выпадку ў скрыпце адсутнічала налада для COLLATE, што прыводзіла да збою пры пераносе дадзеных і танцам з бубнам перастварэнню базы з дапамогай дапоўненага скрыпту.

перанос дадзеных

Перад пераносам дадзеных неабходна адключыць праверку ўсіх абмежаванняў на базе:

EXEC sp_msforeachtable 'ALTER TABLE ? NOCHECK CONSTRAINT all'

Перанос даных ажыццяўляем з дапамогай майстра імпарту даных Tasks -> Import Data на SQL Server, дзе знаходзіцца створаная скрыптам база:

  1. Указваем налады падключэння да крыніцы (SQL Server 2016 на віртуальнай машыне). Я выкарыстаў Data Source Уласны кліент SQL Server і вышэйзгаданую SQL-аўтэнтыфікацыю.
  2. Указваем налады падключэння да месца прызначэння (SQL Server 2014 на хост-машыне).
  3. Далей наладжваем мапінг. Неабходна абраць усё ня read-only аб'екты (напрыклад, уяўленні выбіраць не трэба). У якасці дадатковых опцый варта абраць «Дазволіць устаўку ў identity-слупкі», калі такія выкарыстоўваюцца.
    Увага: калі пры спробе вылучыць некалькі табліц і праставіць ім уласцівасць «Дазволіць устаўку ў identity-слупкі» уласцівасць ужо была раней усталявана хаця б для адной з вылучаных табліц, у дыялогу будзе адзначана, што ўласцівасць ужо ўсталявана для ўсіх вылучаных табліц. Дадзены факт можа збіць з панталыку і прывесці да памылак пераносу.
  4. Запускаем перанос.
  5. Аднаўляем праверку абмежаванняў:
    EXEC sp_msforeachtable 'ALTER TABLE ? CHECK CONSTRAINT all'

Калі ўзніклі якія-небудзь памылкі, правяраем налады, выдаляем створаную з памылкамі базу, зноўку ствараем яе са скрыпту, уносім выпраўленні і паўтараем перанос дадзеных.

Заключэнне

Дадзеная задача сустракаецца даволі рэдка і ўзнікае толькі з-за вышэйпаказаных абмежаванняў. Часцей за ўсё рашэнне заключаецца ў абнаўленні SQL Server або падлучэнні да выдаленага сервера, калі гэта дазваляе архітэктура прыкладання. Аднак ад легасі-кода і крывых рук няякаснай распрацоўкі ніхто не застрахаваны. Спадзяюся, што Вам гэтая інструкцыя не спатрэбіцца, а калі ўсё ж у ёй узнікне неабходнасць, тое дапаможа зэканоміць кучу часу і нерваў. Дзякуй за ўвагу!

Спіс выкарыстаных крыніц

Крыніца: habr.com