ProHoster > BLOG > administrare > Transferarea datelor de rezervă de la o nouă versiune de MS SQL Server la o versiune mai veche

Transferarea datelor de rezervă de la o nouă versiune de MS SQL Server la o versiune mai veche

preistorie

Odată, pentru a reproduce un bug, am avut nevoie de o copie de rezervă a bazei de date de producție.

Spre surprinderea mea, am întâlnit următoarele limitări:

  1. Backup-ul bazei de date a fost făcut pe versiune SQL Server 2016 și nu era compatibil cu al meu SQL Server 2014.
  2. Pe computerul meu de lucru, sistemul de operare folosit a fost Ferestre 7deci nu am putut actualiza SQL Server până la versiunea 2016
  3. Produsul acceptat făcea parte dintr-un sistem mai mare, cu o arhitectură moștenită strâns cuplată și, de asemenea, a vorbit cu alte produse și baze, așa că ar putea dura foarte mult timp pentru a-l implementa pe o altă stație.

Având în vedere cele de mai sus, am ajuns la concluzia că a venit timpul pentru cârje de soluții nestandard.

Restaurarea datelor dintr-o copie de rezervă

Am ales să folosesc o mașină virtuală Oracle VM VirtualBox cu Windows 10 (puteți face o imagine de test pentru browserul Edge prin urmare). SQL Server 2016 a fost instalat pe mașina virtuală și baza de date a aplicației a fost restaurată din backup (instrucție).

Configurarea accesului la SQL Server pe o mașină virtuală

În continuare, a fost necesar să se facă câțiva pași pentru a putea accesa SQL Server din exterior:

  1. Pentru firewall, adăugați o regulă pentru a omite cererile de port 1433.
  2. Este de dorit ca accesul la server să nu treacă prin autentificare Windows, ci prin SQL folosind un login și o parolă (este mai ușor să configurați accesul). Cu toate acestea, în acest caz, trebuie să vă amintiți să activați autentificarea SQL în proprietățile SQL Server.
  3. În setările utilizatorului pe SQL Server, pe fila Maparea utilizatorului specificați rolul de utilizator pentru baza de date restaurată db_securityadmin.

Transfer de date

De fapt, transferul de date în sine constă în două etape:

  1. Transferul schemei de date (tabele, vizualizări, proceduri stocate etc.)
  2. Transferarea datelor în sine

Transferul schemei de date

Efectuam urmatoarele operatiuni:

  1. selecta Sarcini -> Generare scripturi pentru o bază portabilă.
  2. Selectați obiectele pe care trebuie să le transferați sau lăsați valoarea implicită (în acest caz, vor fi create scripturi pentru toate obiectele bazei de date).
  3. Specificați setările pentru salvarea scriptului. Cel mai convenabil este să salvați scriptul într-un singur fișier Unicode. Apoi, în caz de eșec, nu trebuie să repetați din nou toți pașii.

Odată ce scriptul este salvat, acesta poate fi rulat pe serverul SQL original (versiunea veche) pentru a crea baza necesară.

Atenție: După executarea scriptului, trebuie să verificați corespondența dintre setările bazei de date din backup și baza de date creată de script. În cazul meu, nu a existat nicio setare pentru COLLATE în script, ceea ce a dus la un eșec la transferul datelor și la dansul cu o tamburină pentru a recrea baza de date folosind script-ul suplimentat.

Transfer de date

Înainte de a transfera date, trebuie să dezactivați verificarea tuturor restricțiilor din baza de date:

EXEC sp_msforeachtable 'ALTER TABLE ? NOCHECK CONSTRAINT all'

Transferul de date se realizează utilizând expertul de import de date Sarcini -> Import date pe SQL Server, unde se află baza de date creată de script:

  1. Specificați setările de conectare la sursă (SQL Server 2016 pe o mașină virtuală). Am folosit sursa de date Client nativ SQL Server și autentificarea SQL menționată mai sus.
  2. Specificați setările de conexiune pentru destinație (SQL Server 2014 pe mașina gazdă).
  3. Apoi, configurați maparea. Toate trebuie selectate nu numai pentru citire obiecte (de exemplu, vizualizările nu trebuie selectate). Ca opțiuni suplimentare, selectați „Permiteți inserarea în coloanele de identitate”dacă sunt folosite astfel.
    Atenție: dacă, când încercați să selectați mai multe tabele și să le setați proprietatea „Permiteți inserarea în coloanele de identitate” proprietatea a fost deja setată pentru cel puțin unul dintre tabelele selectate, dialogul va indica faptul că proprietatea a fost deja setată pentru toate tabelele selectate. Acest fapt poate fi confuz și poate duce la erori de migrare.
  4. Începem transferul.
  5. Restabilirea verificării constrângerii: 
    EXEC sp_msforeachtable 'ALTER TABLE ? CHECK CONSTRAINT all'

Dacă apar erori, verificăm setările, ștergem baza de date creată cu erori, o recreăm din script, facem corecții și repetă transferul de date.

Concluzie

Această sarcină este destul de rară și are loc numai din cauza limitărilor de mai sus. Cea mai comună soluție este actualizarea SQL Server sau conectarea la un server la distanță dacă arhitectura aplicației permite acest lucru. Cu toate acestea, nimeni nu este imun de codul moștenit și mâinile strâmbe ale dezvoltării de proastă calitate. Sper că nu veți avea nevoie de această instrucțiune, dar dacă tot aveți nevoie de ea, vă va ajuta să economisiți mult timp și nervi. Vă mulțumim pentru atenție!

Lista surselor utilizate

Sursa: www.habr.com