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. Задайте настройките за запазване на скрипта. Най-удобно е да запазите скрипта в един Unicode файл. След това, в случай на неуспех, не е необходимо да повтаряте всички стъпки отново.

След като скриптът бъде записан, той може да се стартира на оригиналния SQL Server (стара версия), за да се създаде необходимата база.

Предупреждение: След като изпълните скрипта, трябва да проверите съответствието между настройките на базата данни от архива и базата данни, създадена от скрипта. В моя случай нямаше настройка за COLLATE в скрипта, което доведе до повреда при прехвърляне на данни и танци с тамбура за пресъздаване на базата данни с помощта на допълнения скрипт.

Трансфер на данни

Преди да прехвърлите данни, трябва да деактивирате проверката на всички ограничения на базата данни:

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