Wir haben einige SQL Server 2005-Datenbanken, die wir bald auf einen neuen Produktionsserver verschieben werden. Diese Datenbanken sind nicht riesig, aber groß genug, um es schwierig zu machen, dies mit so wenig Ausfallzeiten wie möglich zu tun.
Die drei Datenbanken, die zuerst verschoben werden, da sie die kritischsten sind, sind 5, 9 und 25 GB groß (nur Daten ohne Protokolle).
Nun gibt es ein paar Möglichkeiten, aber da ich kein vollwertiger DBA bin, dachte ich, dass einige Leute hier vielleicht bessere Ideen/Vorschläge haben. Hier ist, was uns eingefallen ist:
* Create a full backup, move the file and restore the backup.
Dies ist möglich, aber da die Datenbanken ziemlich groß sind, würde dies ziemlich lange Ausfallzeiten des Systems (mehrere Stunden) bedeuten, da die Datenbanken verschoben werden müssen.
Ist es möglich, heute ein Backup zu erstellen und wiederherzustellen und dann beim eigentlichen Umzug eine differenzielle Wiederherstellung durchzuführen? Das Problem, das ich bisher bei differenziellen Wiederherstellungen festgestellt habe, besteht darin, dass diese immer zu einem VOLLSTÄNDIGEN Backup hinzugefügt werden, wodurch die Dateien dieselbe Größe belassen und die Ausfallzeit durch das Verschieben der Dateien von Server zu Server nicht verringert wird.
Um das Ganze noch komplizierter zu machen, wird die neue Datenbank so konfiguriert, dass sie gespiegelt wird, während die alte Umgebung nicht gespiegelt wird. Das bedeutet, dass ich das differenzielle Backup auf dem Hauptserver wiederherstellen müsste (ich glaube nicht, dass das Probleme verursachen sollte, aber ich dachte, ich frage trotzdem mal).
Wenn es eine andere, einfachere oder bessere Möglichkeit gibt, dies mit möglichst geringen Ausfallzeiten zu tun, würde ich diese natürlich auch gerne erfahren.
Ein Benutzer auf StackOverflow antwortete einfach mit „Sie können dazu die Spiegelung verwenden“. Ohne zu sehr ins Detail zu gehen, sehe ich das so, dass ich einen Spiegel nach dem neuen Prinzip erstellen und dann den Spiegel zwingen kann, den alten Produktionsserver zu übernehmen. Dann deaktiviere ich die Spiegelung und aktiviere sie wieder auf dem neuen Spiegelserver.
Würde das so funktionieren?
Antwort1
Ich habe diese Art der Migration mehrmals durchgeführt und der beste Weg (für mich) ist:
vollständiges Backup (mit verwendeter Datenbank)
Sicherung der Transaktionsprotokolle alle n Minuten (n hängt von der Zeit ab, die zum Kopieren der vollständigen Sicherung benötigt wird)
das komplette Backup auf den neuen Server kopieren und dann die Datenbank ohne Recovery wiederherstellen (
RESTORE....NORECOVERY)Kopieren und Wiederherstellen (immer ohne Wiederherstellung) der Transaktionsprotokolle
Wenn die neue Datenbank fast online ist, stoppen Sie die Anwendungen, die die alte Datenbank verwenden, erstellen Sie eine letzte Sicherungskopie der Transaktionsprotokolle, kopieren Sie sie auf den neuen Server und stellen Sie sie mit der Wiederherstellung wieder her.
jetzt haben Sie die Datenbank mit sehr geringer Ausfallzeit auf einem neuen Server.
Antwort2
Was das Sichern und Verschieben der Datenbanken betrifft, sichere ich regelmäßig eine 30 GB große Datenbank in weniger als einer halben Stunde. Wenn Sie sie auf einem externen USB-Laufwerk sichern, das an den aktuellen Server angeschlossen ist, und sie über das USB-Laufwerk auf den neuen Server übertragen und wiederherstellen, dauert das meiner Meinung nach nicht länger als etwa eine Stunde, plus/minus ein paar Minuten.
Antwort3
Ich versuche, einen Punkt zu machen.
Vielleicht liege ich falsch, lassen Sie andere sagen, ob dies nicht der übliche Weg ist. Können Sie eine Transaktionsreplikation auf einen NEUEN Server einrichten und Datenbanken veröffentlichen und abonnieren, sodass beide Datenbanken mit einer Verzögerung von weniger als ein paar Sekunden konstant laufen?
Danach schließen Sie die Verbindung zu Ihrer alten Datenbank von den Clients und warten ein paar Sekunden.
Deaktivieren Sie die Replikation und beginnen Sie mit der Verwendung der neuen Datenbank