Sådan gendannes en SQL-database ved hjælp af kommandolinjegendannelse med NMM

I denne artikel dokumenteres den procedure, der skal følges for at opnå en vellykket gendannelse af en SQL-database, der blev sikkerhedskopieret med NMM ved hjælp af VDI

Gendannelse af en SQL-database fra sikkerhedskopien ved hjælp af kommandolinjen kan være påkrævet, hvis der er et problem med gendannelse fra den grafiske brugergrænseflade (NetWorker-bruger til SQL Server GUI eller SSMS-pluginet). Enten er browsingopgaven fra GUI'en langsom, eller også er den nødvendige database ikke synlig i GUI'en til gendannelse.


Følgende savesets oprettes typisk, når en enkelt DB sikkerhedskopieres:

En fuld sikkerhedskopiering af en enkelt DB har følgende savesets:
SQLbackups.001 Data Domain sql12srv1 25-05-2016 13:26:41 119 MB 3209027663 cb fuld MSSQL$FINANCE:testdb ==> Fuld sikkerhedskopiering saveset
SQLbackups.001 Data Domain sql12srv1 25-05-2016 13:29:16 5 KB 3192250597 cb incr MSSQL$FINANCE: testdb => = metadata saveset.


En trinvis sikkerhedskopiering af en enkelt DB vil have følgende savesets:
SQLbackups.001 Data Domain sql12srv1 25-05-2016 13:34:14 1320 MB 3141919250 cb incr MSSQL$FINANCE:testdb ==> Log backup saveset
SQLbackups.001 Data Domain sql12srv1 25-05-2016 13:40:31 5 KB 3125142409 cb incr MSSQL$FINANCE:testdb ==> metadata saveset


Bemærk, at hver sikkerhedskopi har et metadata-saveset, som altid oprettes som 'incr'-niveau og normalt er meget lille. Dette lagringssæt indeholder oplysninger, der gør det muligt at se DB-listen i GUI'en "NetWorker User for SQL server". Dette lagringssæt oprettes med hver SQL VDI-sikkerhedskopiering. Det er dog muligt, at dette lagringssæt muligvis ikke eksisterer, hvis manuel kloningsproces fejlagtigt ikke inkluderede dette gemmesæt til kloning, og hvis de originale lagringssæt ikke længere eksisterer. Hvis dette er tilfældet, er kommandolinjegendannelse den eneste mulighed.

Når du har bestemt, hvilken sikkerhedskopi du skal gendanne fra, kan du konstruere kommandolinjen. Nedenfor er et eksempel på en gendannelseskommando:

nsrsqlrc -s nsr-server -c sql12srv1 -t "5/25/2016 1:34:14 PM" -d "MSSQL$FINANCE:testdb-rerecover" -C " 'testdb' = 'c:\recover\testdb.mdf', 'testdb_log' = 'c:\recover\testdb_log.ldf', 'testdb_log1' = 'c:\recover\testdb_log1.ldf'" "MSSQL$FINANCE:testdb"

I ovenstående kommando-s

mulighed er at angive Neter-servernavnet,
-c mulighed bruges til at angive kildeklienten (hvis gendannelsen udføres på en anden vært end kildeklienten),
-d angiv destinationen DB, der skal gendannes til. Denne DB findes ikke. Gendannelsesprocessen opretter DB på målforekomsten.
-C angiver, at dette er en kopigendannelse. Parametrene efter -C angiver de logiske navne på filerne i databasen.  Bemærk, at disse navne skal svare nøjagtigt til de logiske navne på den database, der gendannes.  Hvis databasen findes, skal du udføre egenskaber på DB-navnet fra SSMS GUI og se under 'Filer'.

Hvis gendannelsen udføres på en klynget SQL-server, skal du tilføje "-A "virtual-server name" " til gendannelseskommandoen.

Den sidste komponent i kommandoen er navnet på den DB, der gendannes, f.eks. MSSQL$
FINANCE:testdb

Hvis du ikke er sikker på, hvad de logiske navne på databasefilerne er, kan du angive en ufuldstændig kommando som nedenfor:

nsrsqlrc -s nsr-server -c sql12srv1 -t "25-05-2016 13:34:14" -d "MSSQL$FINANCE:testdb-restitueret" -C " 'mydb' = 'c:\ gendanne\testdb.mdf'" "MSSQL$FINANCE:testdb"
43708:(pid 2144):Starttidspunkt: ons 25 maj 15:37:42 2016
43621:(pid 2144):Computer Navn: SQL12SRV1 Brugernavn: Administrator
NSR_CLIENT: sql12srv1.jets.local;
                  NSR_SERVER: NSR-server;
37725: (PID 2144): Gendannelse af database 'testdb' til 'testdb-gendannet' ...
142468:(PID 2144):[2292]nsr/db_apps/bsmsql/rcstripes.c(222): Finde backup til saveset MSSQL$FINANCE:/testdb.
37945:(pid 2144):Manglende flytning for logisk fil testdb.
37945:(pid 2144):Manglende flytning af logisk fil testdb_log.
37945:(pid 2144):Manglende flytning af logisk fil testdb_log1.
37946:(pid 2144):Ingen logisk fil med navnet mydb i original database
29401:(pid 2144):D atabase file relocation list error. Faktisk filliste er:
37947: (pid 2144):       testdb = C:\Programmer\Microsoft SQL Server\MSSQL11. ØKONOMI\MSSQL\DATA\
testdb.mdf 37947:(PID 2144):       testdb_log = C:\Programmer\Microsoft SQL Server\MSSQL11. FINANS\MSSQL\DATA\testdb_log.ldf
37947:(PID 2144):       testdb_log1 = C:\Programmer\Microsoft SQL Server\MSSQL11. FINANS\MSSQL\DATA\testdb_log1.ldf
142468:(pid 2144):[2292]nsr/db_apps/bsmsql/rcstripes.c(222): Finde backup til saveset MSSQL$FINANCE:/testdb.
37945:(pid 2144):Manglende flytning for logisk fil testdb.
37945:(pid 2144):Manglende flytning af logisk fil testdb_log.
37945:(pid 2144):Manglende flytning af logisk fil testdb_log1.
37946:(pid 2144):Ingen logisk fil med navnet mydb i original database
29401:(pid 2144):D atabase-filflytningslistefejl. Faktisk filliste er:
37947: (pid 2144):       testdb = C:\Programmer\Microsoft SQL Server\MSSQL11. ØKONOMI\MSSQL\DATA\
testdb.mdf 37947:(PID 2144):       testdb_log = C:\Programmer\Microsoft SQL Server\MSSQL11. FINANS\MSSQL\DATA\testdb_log.ldf
37947:(PID 2144):       testdb_log1 = C:\Programmer\Microsoft SQL Server\MSSQL11. FINANCE\MSSQL\DATA\testdb_log1.ldf
Gendannelseshandlingen er færdig med fejl(e). Se modulets sikkerhedskopieringslogfil for at få flere oplysninger. ukendt XBSA-fejl 1169 (0x491) nsr/db_apps/bsmsql/rcovmain.cpp(442): Indtastning af oprydning(). NSR/db_apps/BSMql/rcovmain.cpp(500): Afslutter oprydning().
43709:(pid 2144):Stop tid: ons 25. maj 15:37:49 2016


***********************

I ovenstående kommando gav jeg et tilfældigt logisk navn 'mydb', og kommandoen spytter det faktiske logiske navn på DB-filerne og den oprindelige placering af dem ud. Du kan bruge disse oplysninger til at oprette din gendannelseskommando. Bemærk, at du skal angive en anden sti for at gendanne dataene til. Du kan og bør ikke angive den oprindelige kildesti i gendannelseskommandoen for at undgå risikoen for at overskrive eksisterende data.

Sikkerhedskopieringstiden for gendannelse kan hentes fra kommandoen mminfo. Enten kan savetime som vist i outputtet bruges, eller du kan rapportere på nsavetime og bruge denne tid i stedet.

f.eks:

mminfo -avot -s nsr-server -q "client=sql12srv1,savetime >= yesterday"

SQLbackups.001 Data Domain sql12srv1 25-05-2016 13:26:41 119 MB 3209027663 cb fuld MSSQL$FINANCE:testdb
SQLbackups.001 Data Domain sql12srv1 25-05-2016 13:29:16 5 KB 3192250597 cb incr MSSQL$FINANCE:testdb
SQLbackups.001 Data Domain sql12srv1 25-05-2016 13:34:14 1320 MB 3141919250 cb incr MSSQL$FINANCE:testdb
SQLbackups.001 Data Domain sql12srv1 25-05-2016 13:40:31 5 KB 3125142409 cb incr MSSQL$FINANCE:testdb

mminfo -avot -s nsr-server -q "client=sql12srv1,savetime >= yesterday" -r volume,client,sumflags,sumsize,level,savetime(25),nsavetime,name

SQLbackups.001 sql12srv1 cb 119 MB fuld 25-05-2016 13:26:41 1464197201 MSSQL$FINANCE:testdb
SQLbackups.001 sql12srv1 cb 5 KB incr 25-05-2016 13:29:16 1464197356 MSSQL$FINANCE:testdb
SQLbackups.001 sql12srv1 cb 1320 MB incr 25-05-2016 13:34:14 1464197654 MSSQL$FINANCE:testdb
SQLbackups.001 sql12srv1 cb 5 KB incr 25-05-2016 13:40:31 1464198031 MSSQL$FINANCE:testdb

Bemærk Du kan angive nsavetime/savetime for enten metadatasaveset eller det faktiske datalagringssæt. Begge disse vil fungere.

Scenarie 2:

Hvis sikkerhedskopierne er registreret i mediedb uden DB-navnene, vil tidspunktet for den nødvendige sikkerhedskopi ikke være så indlysende. For eksempel har alle DB-sikkerhedskopier de samme gemte sætnavne som nedenfor:

SQLbackups.001 Data Domain sql12srv1 25-05-2016 16:43:15 151 KB 2672168543 cb incr MSSQL$FINANCE:
SQLbackups.001 Data Domain sql12srv1 25-05-2016 16:45:26 151 KB 2655391455 cb incr MSSQL$FINANCE:

Ud fra ovenstående kan man ikke se, hvilket lagringssæt der har den sikkerhedskopi, du har brug for.

Hvis medata-datalagringssættet findes, kan sikkerhedskopieringerne gennemses fra GUI'en, og du kan finde DB-navnet og sikkerhedskopieringstiden fra GUI'en. Hvis DB24 f.eks. var påkrævet, viser den grafiske brugergrænseflade sikkerhedskopieringstiden som "25-05-2016 16:49". 



Hvis metadatalagringssættet ikke er der, skal du køre kommandoen nsrinfo for at finde sparetiden for gendannelsen. f.eks. hvis mminfo viser savesets som nedenfor:

SQLbackups.001 Data Domain sql12srv1 25-05-2016 16:43:15 151 KB 2672168543 cb incr MSSQL$FINANCE:
SQLbackups.001 Data Domain sql12srv1 25-05-2016 16:45:26 151 KB 2655391455 cb incr MSSQL$FINANCE:
SQLbackups.001 Data Domain sql12srv1 25-05-2016 16:47:34 151 KB 2638614367 cb incr MSSQL$FINANCE:
SQLbackups.001 Data Domain sql12srv1 25-05-2016 16:49:42 151 KB 2621837279 cb inkl. MSSQL$FINANCE:
SQLbackups.001 Data Domain sql12srv1 25-05-2016 16:51:50 151 KB 2605060191 cb incr MSSQL$FINANCE:
SQLbackups.001 Data Domain sql12srv1 25-05-2016 16:53:58 151 KB 2588283103 cb incr MSSQL$FINANCE:

Kør nsrinfo på lagringstiderne som nedenfor for at få oplysninger om den database, der er en del af det gemte sæt:nsrinfo -n mssql -t "25-05-2016 16:

43:15" sql12srv1
scanningsklient 'sql12srv1' til sparetid 1464208995(25-05-2016 16:43:15) fra mssql-navneområdet
MSSQL$FINANCE:/ DB21
MSSQL$FINANCE:/DB21%/files.1464208995.1464209044
2 objekter fundet

nsrinfo -n mssql -t "25-05-2016 16:49:42" sql12srv1
scanningsklient 'sql12srv1' til savetime 1464209382(25-05-2016 16:49:42) fra mssql-navneområdet
MSSQL$FINANCE:/DB24
MSSQL$FINANCE:/DB24%/files.1464209382.1464209437
Der blev fundet

2 objekterDa gemmesættene ikke viser DB-navnene, kan ovenstående være lidt forsøg og fejl i scenariet, hvor metadatalagringssættet ikke findes. Brug den omtrentlige DB-størrelse som et fingerpeg om at indsnævre nsrinfo-forespørgslen til nogle få gemte sæt.