Verschieben der SQL Server-Datenbank auf eine neue Festplatte, während Sie online sind

Ich habe eine 1,4-TB-SQL Server-Datenbank, die massiv mit Festplatten-E / A zu kämpfen hat. Wir haben ein neues SSD-Array auf dem Server installiert, das alle unsere Probleme löst. Wir diskutieren nur, wie die Datenbank am besten verschoben werden kann. Idealerweise ist es am besten, wenn wir dies ohne Ausfallzeiten tun können. Wenn jedoch zwischen zwei Tagen mit schlechter Leistung (z. B. beim Kopieren von Daten) und zwei Stunden Ausfallzeit gewählt werden kann, ist letztere möglicherweise vorzuziehen.

Bisher haben wir folgende Lösungen gefunden:

• Einfache Kopie. Schalten Sie die Datenbank offline, kopieren Sie die Dateien, ändern Sie die Speicherorte in SQL Server und schalten Sie sie wieder online. Grobe Zahlen gehen davon aus, dass dies bis zu fünf Stunden dauern wird, was nicht wirklich akzeptabel ist, aber die einfachste Lösung ist.

• Kopie auf Blockebene. Mit einem rsync-ähnlichen Dienstprogramm kopieren wir die Dateien im Hintergrund, während die Datenbank aktiv ist. Wenn wir zur Migration bereit sind, schalten wir die Datenbank offline, erstellen mit diesem Dienstprogramm eine differenzielle Kopie, zeigen dann mit dem SQL Server auf die neuen Dateien und schalten sie online. Das Timing hier ist unbekannt. Wir wissen nicht, wie lange es dauern wird, eine Differenzialanalyse von 1,4 TB durchzuführen und diese zu kopieren. Unsere andere Sorge ist, dass die Kopie auf Blockebene die Dateien in einem für SQL Server unlesbaren Zustand belässt und wir unsere Zeit verschwenden.

• SQL-Migration. Erstellen Sie eine neue 1,4-TB-SQL-Datendatei auf der neuen Festplatte und deaktivieren Sie das automatische Wachstum für alle anderen Dateien. Führen Sie dann DBBC SHRINKFILE (-file_name-, EMPTYFILE) nacheinander für alle anderen Datendateien aus. Sobald alle Daten vollständig sind, nehme ich irgendwann ein geplantes Fenster, um die MDF-Datei auf die SSD zu verschieben und die anderen nicht verwendeten Dateien zu entfernen. Ich mag das, weil es Ausfallzeiten minimiert. Aber ich habe keine Ahnung, wie lange dies dauern wird und ob es zu Leistungseinbußen führen wird, während es passiert.

Wir haben keine Last- und Leistungsumgebung, um dies zu testen. Ich kann überprüfen, ob die Strategien in unserer Staging-Umgebung funktionieren, jedoch nicht die Auswirkungen und nicht die Leistung.

Eine Methode zum Verschieben der gesamten Datenbank ist mit BACKUPund RESTORE. Die Datenbank ist während des letzten Wechsels nicht verfügbar, aber die Ausfallzeit sollte bei der Planung minimal sein. Dieses Verfahren setzt das FULLoder BULK_LOGGEDWiederherstellungsmodell voraus :

1) Führen Sie eine vollständige Sicherung durch (oder verwenden Sie Ihre vorhandene).

2) Stellen Sie die letzte vollständige Sicherung unter einem anderen Datenbanknamen wieder her und geben Sie die WITH MOVEOption zum Verschieben von Dateien auf dem SSD-Speicher nach NORECOVERYBedarf sowie die Option an, damit nachfolgende differenzielle und Protokollsicherungen wiederhergestellt werden können.

3) Übernehmen Sie inkrementelle Änderungen an der neuen Datenbank bis zum Zeitpunkt der endgültigen Umstellung mit Transaktionsprotokollsicherungen und RESTORE...WITH NORECOVERY. Dadurch werden Ausfallzeiten für den endgültigen Wechsel zur neuen Datenbank minimiert.

4) Um zur neuen Datenbank zu wechseln, schalten Sie die Anwendung offline, führen Sie eine endgültige Transaktionsprotokollsicherung durch und wenden Sie sie auf die neue Datenbank an WITH RECOVERY. Benennen Sie abschließend die ursprüngliche Datenbank in einen anderen Namen um und benennen Sie die verschobene Datenbank in den ursprünglichen Namen um. Löschen Sie die alte Datenbank nach Belieben.

Im SIMPLE-Wiederherstellungsmodell können Sie einen ähnlichen Prozess verwenden, jedoch ohne die Sicherung / Wiederherstellung des Transaktionsprotokolls in Schritt 3. Verwenden Sie stattdessen im letzten Schritt eine differenzielle Datenbanksicherung / -wiederherstellung. Dies kann je nach Anzahl der Änderungen seit der ersten FULLSicherung mehr Ausfallzeiten erfordern .

Good approach is to use SQL REPLICATION between two server
once all data replicated on SSD server then take current server offline 
and switch to SSD server.