Hvis du bruger SQL Server Management Studio (SSMS) eller en anden GUI til at administrere dine databaser, kan du være vant til at sikkerhedskopiere og gendanne databaser ved at bruge "peg og klik".
Normalt involverer dette at højreklikke på databasen og vælge Gendan eller lignende, og følg derefter anvisningerne (f.eks. ved gendannelse af en database i Azure Data Studio).
Men hvis du nogensinde har brug for at gøre det med T-SQL, kan du bruge RESTORE DATABASE
erklæring.
Eksempel
Her er et grundlæggende eksempel:
RESTORE DATABASE World
FROM DISK = N'/var/opt/mssql/Bak/World.bak'
WITH FILE = 1;
Dette er næsten så enkelt, som det kan blive. RESTORE DATABASE
sætning har en ret kompleks syntaks (som med de fleste ting T-SQL), men denne sætning er tilstrækkelig til en grundlæggende standardgendannelsesoperation.
I dette tilfælde gendannede jeg en database kaldet Verden fra en .bak-fil. Jeg brugte FROM DISK
for at angive, at det var fra en .bak-fil, og jeg gav den fulde sti til den fil. Andre muligheder her inkluderer FROM TAPE
og FROM URL
.
Jeg har også inkluderet WITH FILE = 1
her, men det er alligevel standardværdien. Denne klausul specificerer backupsættets filnummer, der skal bruges. Det vil sige, hvilket backupsæt der skal bruges i filen (en fil kan have flere backupsæt).
Få en liste over sikkerhedskopieringssæt
Du kan bruge RESTORE HEADERONLY
for at få en liste over sikkerhedskopieringssæt i filen. Mere specifikt returnerer det et resultatsæt med backup-headeroplysninger for alle backupsæt.
Eksempel:
RESTORE HEADERONLY
FROM DISK = N'/var/opt/mssql/Bak/WideWorldImporters-Full.bak';
Dette giver mange kolonner tilbage, så jeg vil ikke præsentere dem alle her.
En af kolonnerne hedder Position . Dette skal bruges sammen med FILE =
mulighed ved gendannelse af databasen.
Eksempel med flere muligheder
Her er et eksempel med flere muligheder:
RESTORE DATABASE [WideWorldImporters]
FROM DISK = N'/var/opt/mssql/Bak/WideWorldImporters-Full.bak'
WITH FILE = 1,
MOVE N'WWI_Primary' TO N'/var/opt/mssql/data/WideWorldImporters.mdf',
MOVE N'WWI_UserData' TO N'/var/opt/mssql/data/WideWorldImporters_UserData.ndf',
MOVE N'WWI_Log' TO N'/var/opt/mssql/data/WideWorldImporters.ldf',
MOVE N'WWI_InMemory_Data_1' TO N'/var/opt/mssql/data/WideWorldImporters_InMemory_Data_1',
NOUNLOAD,
STATS = 5;
Dette er faktisk det script, som Azure Data Studio genererede til mig, da jeg brugte GUI-grænsefladen til at starte en gendannelseshandling. Når du gør det, giver Azure Data Studio dig mulighed for at køre gendannelsen med det samme eller generere et script med T-SQL-koden, som du kan køre senere.
I dette tilfælde bruger scriptet MOVE
argument for at flytte hvert logisk filnavn i backupfilen til den angivne fysiske filplacering på operativsystemet. I dette tilfælde brugte .bak-filen en anden fysisk filplacering (og brugte Windows-filstier), og dette skulle ændres, så det passede til mit system. Se nedenfor for en forklaring på, hvordan du får denne information.
NOUNLOAD
er faktisk en båndoption. Det sikrer, at båndet ikke fjernes fra drevet, når gendannelsen er fuldført. Da jeg ikke var ved at gendanne fra bånd, blev denne mulighed ignoreret.
STATS
argument giver dig mulighed for at måle forløbet af gendannelsesoperationen. Det specificerer, at en meddelelse vil blive vist, hver gang en anden procentdel fuldfører. Hvis du ikke inkluderer en procentværdi her, vil SQL Server vise en meddelelse, efter hver 10 % er gennemført.
GENDAN KUN FILELISTE
Hvis du ville lave en sætning som den tidligere, som bruger MOVE
argument for at flytte hvert logisk filnavn i backupfilen til den angivne fysiske filplacering på operativsystemet, kan du bruge RESTORE FILELISTONLY
for at returnere de logiske filnavne (og mere).
RESTORE FILELISTONLY
returnerer et resultatsæt, der indeholder en liste over databasen og logfiler, der er indeholdt i sikkerhedskopisættet.
Her er et eksempel, der bruger den samme WideWorldImporters .bak-fil fra det tidligere eksempel:
RESTORE FILELISTONLY
FROM DISK = N'/var/opt/mssql/Bak/WideWorldImporters-Full.bak';
Resultat (ved hjælp af lodret output):
-[ RECORD 1 ]------------------------- LogicalName | WWI_Primary PhysicalName | D:\Data\WideWorldImporters.mdf Type | D FileGroupName | PRIMARY Size | 1073741824 MaxSize | 35184372080640 FileId | 1 CreateLSN | 0 DropLSN | 0 UniqueId | 8d30f4f9-a463-404f-805a-9bd1c634b66b ReadOnlyLSN | 0 ReadWriteLSN | 0 BackupSizeInBytes | 11993088 SourceBlockSize | 512 FileGroupId | 1 LogGroupGUID | NULL DifferentialBaseLSN | 626000002440500037 DifferentialBaseGUID | 0c5a4141-4a09-4b31-8c83-217870278065 IsReadOnly | 0 IsPresent | 1 TDEThumbprint | NULL SnapshotUrl | NULL -[ RECORD 2 ]------------------------- LogicalName | WWI_UserData PhysicalName | D:\Data\WideWorldImporters_UserData.ndf Type | D FileGroupName | USERDATA Size | 2147483648 MaxSize | 35184372080640 FileId | 3 CreateLSN | 37000000095200001 DropLSN | 0 UniqueId | 28d406e0-78ff-4400-9a4b-3a05d136b1f3 ReadOnlyLSN | 0 ReadWriteLSN | 0 BackupSizeInBytes | 434962432 SourceBlockSize | 512 FileGroupId | 2 LogGroupGUID | NULL DifferentialBaseLSN | 626000002440500037 DifferentialBaseGUID | 0c5a4141-4a09-4b31-8c83-217870278065 IsReadOnly | 0 IsPresent | 1 TDEThumbprint | NULL SnapshotUrl | NULL -[ RECORD 3 ]------------------------- LogicalName | WWI_Log PhysicalName | E:\Log\WideWorldImporters.ldf Type | L FileGroupName | NULL Size | 104857600 MaxSize | 2199023255552 FileId | 2 CreateLSN | 0 DropLSN | 0 UniqueId | 6ac6807e-8774-415b-8efc-e8c569b0855e ReadOnlyLSN | 0 ReadWriteLSN | 0 BackupSizeInBytes | 0 SourceBlockSize | 512 FileGroupId | 0 LogGroupGUID | NULL DifferentialBaseLSN | 0 DifferentialBaseGUID | 00000000-0000-0000-0000-000000000000 IsReadOnly | 0 IsPresent | 1 TDEThumbprint | NULL SnapshotUrl | NULL -[ RECORD 4 ]------------------------- LogicalName | WWI_InMemory_Data_1 PhysicalName | D:\Data\WideWorldImporters_InMemory_Data_1 Type | S FileGroupName | WWI_InMemory_Data Size | 0 MaxSize | 0 FileId | 65537 CreateLSN | 624000000336200003 DropLSN | 0 UniqueId | f65663c8-a250-433e-bbe6-e13a5599a607 ReadOnlyLSN | 0 ReadWriteLSN | 0 BackupSizeInBytes | 980090880 SourceBlockSize | 512 FileGroupId | 3 LogGroupGUID | NULL DifferentialBaseLSN | 626000002440500037 DifferentialBaseGUID | 0c5a4141-4a09-4b31-8c83-217870278065 IsReadOnly | 0 IsPresent | 1 TDEThumbprint | NULL SnapshotUrl | NULL
Så vi kan se, at de fysiske placeringer af denne fil bruger Windows-filstier. For eksempel den første (med et logisk navn WWI_Primary ) har en fysisk placering på D:\Data\WideWorldImporters.mdf .
I mit tilfælde gendannede jeg databasen til SQL Server til Linux (kører i en Docker-container på min Mac), så da jeg gendannede denne .bak-fil til mit system, var jeg nødt til at ændre de fysiske stier, så de passede til mit system.
Du kan selvfølgelig også ændre filstierne, når du gendanner den til en Windows-maskine, hvis det kræves.
Den fulde syntaks
Sikkerhedskopiering og gendannelse af databaser kan være ret involveret, afhængigt af dine krav. RESTORE
statement er designet til at dække mange forskellige scenarier. Det dækker især følgende gendannelsesscenarier:
- Gendan en hel database fra en komplet databasesikkerhedskopi (en komplet gendannelse).
- Gendan en del af en database (en delvis gendannelse).
- Gendan specifikke filer eller filgrupper til en database (en filgendannelse).
- Gendan specifikke sider til en database (en sidegendannelse).
- Gendan en transaktionslog til en database (en transaktionsloggendannelse).
- Gendan en database til det tidspunkt, der er fanget af et databaseøjebliksbillede.
Den fulde syntaks indeholder en masse muligheder, så hvis dine krav overstiger omfanget af denne artikel, så tjek Microsoft-dokumentationen for den officielle RESTORE
syntaks og forklaring.
Læs også Microsofts gendannelses- og gendannelsesoversigt for at få et overblik over de forskellige overvejelser og tilgange til gendannelse af databaser.