Datenbank beschädigt? SQL-Datenbank wiederherstellen

Eine versehentliche Änderung kann wichtige Daten löschen, während die Datenbank weiterläuft. Georeplikation überträgt auch diese Änderung auf die sekundäre Datenbank. Eine Wiederherstellung aus einer Sicherung stellt einen früheren Zustand in einer separaten Datenbank bereit. Dort kannst du die wiederhergestellten Daten vor ihrer Verwendung prüfen. Dieses Lab simuliert einen Schaden durch Löschen einer Testtabelle und verwendet Point-in-time restore (PITR) zur Wiederherstellung auf einen bestimmten Zeitpunkt.

Testdaten vorbereiten

Verwende sqldb-cloudtrips aus Azure SQL Database erstellen. Nach dem Failovergruppen-Trip verwende den Server, der aktuell die primäre Datenbank enthält; die wiederhergestellte Datenbank entsteht auf diesem Server.

Verbinde dich über VS Code oder Query editor (preview) mit dieser Labdatenbank. Führe einmal aus:

CREATE TABLE dbo.RestoreCheck (
    Id int PRIMARY KEY,
    Note nvarchar(100)
);
INSERT INTO dbo.RestoreCheck VALUES (1, N'Keep this record');

Warte nach erfolgreicher Ausführung eine Minute und führe dann aus:

SELECT SYSUTCDATETIME() AS RestoreTimeUtc;
SELECT Id, Note FROM dbo.RestoreCheck;

Notiere RestoreTimeUtc genau wie angezeigt. Dieser Zeitpunkt liegt nach dem bestätigten Speichern der Zeile und dient als Wiederherstellungsziel. Prüfe Keep this record in Zeile 1; dein Zeitstempel wird abweichen.

Den Fehler simulieren

Warte eine weitere Minute, um Wiederherstellungszeit und Fehler zeitlich zu trennen. Führe in derselben Labdatenbank aus:

DROP TABLE dbo.RestoreCheck;
SELECT OBJECT_ID('dbo.RestoreCheck', 'U') AS TableObjectId;

Erwarte NULL: Die Testtabelle ist gelöscht. Das entfernt nur die für diese Übung erstellte Tabelle.

Früheren Zustand wiederherstellen

Öffne die primäre sqldb-cloudtrips → Overview → Restore. Konfiguriere:

Restore point: Notierte RestoreTimeUtc
New database name: sqldb-restored
Server: Derselbe Server wie die Quelle (festgelegt)
Compute + storage: Gewählte Kapazität und Kosten prüfen

Prüfe die Zeitzonenangabe im Portal und rechne deinen UTC-Zeitstempel gegebenenfalls um. Der Zeitpunkt muss im verfügbaren Wiederherstellungsfenster liegen. Ist er zu aktuell, warte auf die entsprechenden Sicherungen und aktualisiere die Ansicht; neu erstellte Datenbanken benötigen auch eine abgeschlossene erste Sicherung. Eine Hyperscale-Quelle wird in Hyperscale wiederhergestellt.

Vergleiche den Zeitpunkt mit deiner Notiz und prüfe den neuen Datenbanknamen. Wähle Review + create → Create und warte auf den Abschluss. Azure erstellt eine separat berechnete Datenbank und erhält das Original.

Wiederhergestellte Daten prüfen

Verbinde dich direkt mit dem SQL-Server der Quelle und wähle sqldb-restored als Datenbank. Verwende die Adminzugangsdaten des Servers und führe aus:

SELECT DB_NAME() AS DatabaseName;
SELECT Id, Note FROM dbo.RestoreCheck;

Erwarte sqldb-restored und Zeile 1 mit Keep this record. Im Original fehlt die gelöschte Tabelle weiterhin. Die wiederhergestellte Datenbank gehört nicht zur vorhandenen Failovergruppe; deren Listener bedient weiterhin die ursprüngliche Datenbank.

Prüfe bei einem echten Vorfall die wiederhergestellten Daten und kopiere anschließend benötigte Datensätze zurück oder plane den Wechsel der Anwendung. Ein vollständiger Wechsel setzt auch gültige Änderungen nach dem gewählten Zeitpunkt zurück.

Bereinigen

Lösche nach der Prüfung sqldb-restored. Behalte die ursprüngliche Datenbank für weitere Trips; erhalte Server und Ressourcengruppe, solange du ihre Sicherungen benötigst.