Von AWS zu Google Cloud migrieren: Von Amazon RDS for SQL Server zu Cloud SQL for SQL Server migrieren

Last reviewed 2024-06-28 UTC

Google Cloud bietet Tools, Produkte, Anleitungen und professionelle Dienstleistungen, um von Amazon Relational Database Service (RDS) zu Cloud SQL for SQL Server zu migrieren.

Dieses Dokument richtet sich an Cloud- und Datenbankadministratoren, die Planung, Implementierung und Validierung eines Datenbankmigrationsprojekts durchführen möchten. Es ist auch für Entscheidungsträger gedacht, die die Möglichkeit einer Migration in Betracht ziehen und ein Beispiel wollen, wie eine Migration aussehen könnte.

In diesem Dokument geht es um eine homogene Datenbankmigration, also eine Migration, in denen Quell- und Zieldatenbank dieselbe Datenbanktechnologie haben. Die Quelle ist Amazon RDS for SQL Server und das Ziel ist Cloud SQL for SQL Server.

Dieses Dokument ist Teil einer mehrteiligen Reihe zur Migration von AWS zu Google Cloud, die folgende Dokumente enthält:

• Jetzt starten
• Von Amazon EC2 zu Compute Engine migrieren
• Von Amazon S3 zu Cloud Storage migrieren
• Von Amazon EKS zu GKE migrieren
• Von AWS zu Google Cloud migrieren: Von Amazon RDS for SQL Server zu Cloud SQL for SQL Server migrieren (dieses Dokument)

In dieser Reihe wird davon ausgegangen, dass Sie die folgenden Dokumente gelesen haben und mit ihnen vertraut sind:

• Zu Google Cloud migrieren: Erste Schritte: Beschreibt das allgemeine Migrations-Framework, dem Sie in dieser Migration folgen.
• Zu Google Cloud migrieren: Best Practices zur Validierung eines Migrationsplans: Beschreibt mögliche Änderungen und Verbesserungen Ihres Migrationsplans.

Diese Grafik veranschaulicht den Migrationsprozess: In Migrationsszenarien entspricht die Bereitstellungsphase dem Durchführen eines Migrationsprozesses.

Die Migration von Amazon RDS zu Cloud SQL erfolgt in einer Folge von Iterationen, z. B. einige Datenbankinstanzen zuerst und andere später. Bei jeder einzelnen Migrationsiteration folgen Sie den Phasen des allgemeinen Migrations-Framework. Es sieht so aus:

1. Arbeitslasten und Daten bewerten und erkennen.
2. Grundlage in Google Cloud planen und erstellen.
3. Arbeitslasten und Daten zu Google Cloud migrieren.
4. Google Cloud-Umgebung optimieren.

Weitere Informationen zu den Phasen dieses Frameworks finden Sie unter Zu Google Cloud migrieren: Erste Schritte.

Quellumgebung bewerten

In der Bewertungsphase bestimmen Sie die Anforderungen und Abhängigkeiten der Ressourcen, die Sie migrieren möchten.

Die Bewertungsphase umfasst die folgenden Aufgaben:

1. Ein umfassendes Inventar Ihrer Arbeitslasten erstellen.
2. Arbeitslasten nach ihren Attributen und Abhängigkeiten katalogisieren.
3. Trainieren und schulen Sie Ihre Teams in Bezug auf Google Cloud, der Best Practices für Datenbanken.
4. Tests und Proofs of Concept in Google Cloud erstellen.
5. Die Gesamtbetriebskosten (TCO) der Zielumgebung berechnen.
6. Reihenfolge und Priorität der Arbeitslasten festlegen, die Sie migrieren möchten.

In der Datenbankbewertungsphase können Sie die Größe und Spezifikationen Ihrer Cloud SQL-Zielinstanz für die Datenbank auswählen, die mit der Quelle für ähnliche Leistungsanforderungen übereinstimmen. Achten Sie dabei besonders auf Laufwerkgröße und Durchsatz, IOPS und Anzahl der vCPUs. Migrationen können aufgrund einer falschen Größe der Zieldatenbankinstanz zu Problemen führen oder fehlschlagen. Eine falsche Größe kann zu langen Migrationszeiten, zu Problemen mit der Datenbankleistung, Datenbankfehlern und Problemen mit der Anwendungsleistung führen. Beachten Sie bei der Entscheidung für die Cloud SQL-Instanz, dass die Laufwerksleistung von der Laufwerkgröße und der Anzahl der vCPUs abhängt.

Weitere Informationen zur Bewertungsphase und zu diesen Aufgaben finden Sie unter Zu Google Cloud migrieren: Arbeitslasten bewerten und erkennen. Die folgenden Abschnitte basieren auf Informationen in jenem Dokument.

Inventar Ihrer Amazon RDS-Instanzen erstellen

Um den Umfang der Migration zu definieren, erstellen Sie ein Inventar und erfassen Informationen zu Ihren Amazon RDS-Instanzen. Im Idealfall sollte der Prozess automatisiert werden, da manuelle Ansätze fehleranfällig sind und zu falschen Annahmen führen können.

Amazon RDS und Cloud SQL haben möglicherweise keine ähnlichen Funktionen, Spezifikationen oder Abläufe. Einige Funktionen werden möglicherweise anders implementiert oder sind nicht verfügbar. Zu den Unterschieden können Infrastruktur, Speicher, Authentifizierung und Sicherheit, Replikation, Sicherung, Hochverfügbarkeit, Ressourcenkapazitätsmodell und bestimmte Integrationen und Erweiterungen von Datenbank-Engines gehören. Je nach Typ des Datenbankmoduls, Instanzgröße und Architektur gibt es auch Unterschiede bei den Standardwerten der Einstellungen von Datenbankparametern.

Benchmarking kann Ihnen helfen, die zu migrierenden Arbeitslasten besser zu verstehen zu migrierenden Arbeitslasten und hilft Ihnen, die richtige Architektur der Zielumgebung. Das Erfassen von Leistungsinformationen ist wichtig, um die Leistungsanforderungen der Google Cloud-Zielumgebung abzuschätzen. Benchmarking-Konzepte und -Tools werden in der Test- und Validierungsphase des Migrationsprozesses durchgeführt, aber sie gelten auch für die Inventarerstellungsphase.

Tools für Bewertungen

Für eine erste Übersicht über Ihre aktuelle Infrastruktur empfehlen wir die Verwendung des Google Cloud-Migrationscenters zusammen mit anderen spezialisierten Tools zur Datenbankbewertung wie migVisor und das Datenbanktool zur Migrationsberwertung (DMA)

Mit dem Migrationscenter können Sie eine umfassende Bewertung Ihrer Anwendungs- und Datenbanklandschaft, einschließlich der technischen Eignung für eine Datenbankmigration zu Google Cloud ausführen. Sie erhalten Größe und Konfigurationsempfehlungen für jede Quelldatenbank und erstellen einen Bericht zu den Gesamtbetriebskosten (TCO) für Server und Datenbanken.

Weitere Informationen zur Bewertung Ihrer AWS-Umgebung mithilfe des Migrationscenters, siehe Daten von anderen Cloud-Anbietern importieren

Neben dem Migrationscenter können Sie das spezielle Tool migVisor verwenden. migVisor unterstützt eine Vielzahl von Datenbankmodulen und ist besonders geeignet für heterogene Migrationen. Für eine Einführung in migVisor, siehe Übersicht über migVisor

migVisor kann Artefakte und inkompatible proprietäre Datenbank-Features identifizieren, die zu Migrationsfehlern führen können, und kann auf Umgehungsmöglichkeiten hinweisen. migVisor kann auch eine Ziellösung für Google Cloud empfehlen, einschließlich der anfänglichen Größe und Architektur.

Die Ausgabe der migVisor-Datenbankbewertung enthält Folgendes:

• Umfassende Erkennung und Analyse aktueller Datenbankbereitstellungen.
• Detaillierter Bericht zur Komplexität der Migration, basierend auf den proprietären Features, die von Ihrer Datenbank verwendet werden.
• Finanzbericht mit Details zu den Kosteneinsparungen nach der Migration, Migrationskosten und einem neuen Betriebsbudget.
• Stufenbasierter Migrationsplan für die Migration von Datenbanken und zugehörigen Anwendungen mit minimalen Unterbrechungen für das Geschäft.

Beispiele für Bewertungsergebnisse finden Sie unter migVisor – Tool zur Cloud-Migrationsbewertung

Beachten Sie, dass migVisor die Auslastung des Datenbankservers vorübergehend erhöht. In der Regel liegt diese zusätzliche Last unter 3 % und kann außerhalb der Spitzenzeiten ausgeführt werden.

Mithilfe der Bewertungsausgabe von migVisor können Sie eine vollständige Bestandsaufnahme Ihrer RDS-Instanzen erstellen. Der Bericht enthält allgemeine Attribute (Version und Version des Datenbankmoduls, CPUs und Speichergröße) sowie Details zur Datenbanktopologie, zu Sicherungsrichtlinien, Parametereinstellungen und speziell verwendeten Anpassungen.

Wenn Sie lieber Open-Source-Tools verwenden, können Sie Data-Collector-Scripts mit (oder anstelle) den genannten Tools verwenden. Mit diesen Skripts können Sie detaillierte Informationen (über Arbeitslasten, Funktionen, Datenbankobjekte und Datenbankcode) und Ihr Datenbankinventar erstellen. Außerdem bieten Skripts in der Regel eine detaillierte Datenbank, Migrationsbewertung, einschließlich einer Schätzung des Migrationsaufwands.

Wir empfehlen das Open-Source-Tool DMA, das von Google-Entwicklern entwickelt wurde. Es bietet eine vollständige und genaue Datenbankbewertung, einschließlich verwendeter Features, Datenbanklogik und Datenbankobjekte (einschließlich Schemas, Tabellen, Ansichten, Funktionen, Triggern und gespeicherten Prozeduren).

Laden Sie zur Verwendung von DMA die Skripts zur Erfassung für Ihr Datenbankmodul aus dem Git-Repository und folgen Sie der Anleitung. Senden Sie die Ausgabedateien zur Analyse an Google Cloud. Google Cloud erstellt und stellt eine Leseausgabe für die Datenbankbewertung bereit und bietet die nächsten Schritte auf der Migration.

Migrationsumfang und vertretbare Ausfallzeiten ermitteln und dokumentieren

In dieser Phase dokumentieren Sie wichtige Informationen, die sich auf Ihre Migrationsstrategie und Ihre Tools auswirken. Mittlerweile können Sie die folgenden Fragen beantworten:

• Sind Ihre Datenbanken größer als 5 TB?
• Befinden sich in Ihrer Datenbank große Tabellen? Sind sie größer als 16 TB?
• Wo befinden sich die Datenbanken (Regionen und Zonen) und in welcher Nähe befinden sich die Datenbanken?
• Wie oft ändern sich die Daten?
• Welches Datenkonsistenzmodell verwenden Sie?
• Welche Optionen gibt es für Zieldatenbanken?
• Wie kompatibel sind die Quell- und Zieldatenbanken?
• Müssen sich die Daten an einigen physischen Standorten befinden?
• Gibt es Daten, die komprimiert und archiviert werden können, oder gibt es Daten, die überhaupt keine Migration erforderlich?

Legen Sie fest, welche Daten beibehalten und welche migriert werden sollen, um den Migrationsbereich festzulegen. Das Migrieren aller Datenbanken kann viel Zeit und Aufwand in Anspruch nehmen. Einige Daten können in den Sicherungen Ihrer Quelldatenbank verbleiben. Zum Beispiel alte Logging-Tabellen oder Archivdaten, die möglicherweise nicht benötigt werden. Alternativ können Sie sich je nach Strategie und Tools auch nach dem Migrationsprozess entscheiden.

Legen Sie Baselines zur Datenmigration fest, mit denen Sie Ihre Ergebnisse und Auswirkungen vergleichen und bewerten können. Diese Referenzen sind Referenzpunkte, die den Status Ihrer Daten vor und nach der Migration darstellen und Ihnen bei der Entscheidung helfen. Es ist wichtig, Messungen in der Quellumgebung vorzunehmen, um den Erfolg Ihrer Datenmigration zu bewerten. Zu solchen Messungen gehören:

• Die Größe und Struktur Ihrer Daten.
• Vollständigkeit und Einheitlichkeit Ihrer Daten
• Dauer und Leistung der wichtigsten Geschäftstransaktionen und Prozesse.

Legen Sie fest, wie viel Ausfallzeit Sie sich leisten können. Welche geschäftlichen Auswirkungen haben Ausfallzeiten? Gibt es Zeiträume mit geringer Datenbankaktivität, in denen weniger Nutzer von Ausfallzeiten betroffen sind? Wenn ja, wie lang sind diese Zeiträume und wann treten sie auf? Ziehen Sie in Erwägung, eine teilweise Ausfallzeit für Schreibzugriffe einzuplanen, während Lesezugriffe weiterhin bedient werden.

Bereitstellungs- und Verwaltungsprozess bewerten

Nachdem Sie die Inventare erstellt haben, bewerten Sie die Betriebs- und Bereitstellungsprozesse für Ihre Datenbank, um zu bestimmen, wie diese angeapsst werden müssen, um die Migration zu erleichtern. Diese Prozesse sind grundlegend dafür, wie Sie Ihre Produktionsumgebung vorbereiten und pflegen.

Überlegen Sie, wie Sie die folgenden Aufgaben ausführen:

• Definieren und erzwingen Sie Sicherheitsrichtlinien für Ihre Instanzen: Sie müssen zum Beispiel Amazon Security Groups ersetzen. Mit Google IAM-Rollen, VPC-Firewallregeln und VPC Service Controls können Sie den Zugriff auf Ihre Cloud SQL-Instanzen steuern und die Daten in einer VPC einschränken. Wenn Sie die Windows-Authentifizierung mit Cloud SQL for SQL Server verwenden wollen, müssen Sie einVerwaltetes Microsoft AD bereitstellen und eine Verbindung zu Ihrer vorhandenen Active Directory-Infrastruktur herstellen.
• Instanzen patchen und konfigurieren: Ihre vorhandenen Bereitstellungstools müssen möglicherweise aktualisiert werden. Vielleicht verwenden Sie benutzerdefinierte Konfigurationseinstellungen in Amazon-Parametergruppen oder Amazon-Optionsgruppen. Ihre Bereitstellungstools müssen möglicherweise angepasst werden, damit Sie Google Cloud Storage oder Secret Manager zum Lesen solcher benutzerdefinierten Konfigurationslisten verwenden können.
• Monitoring- und Benachrichtigungsinfrastruktur verwalten: Messwertkategorien für Ihre Amazon-Quelldatenbankinstanzen sorgen für Beobachtbarkeit während des Migrationsprozess. Zu den Messwertkategorien können Amazon CloudWatch, Leistungsinformationen, erweitertes Monitoring und Betriebssystemprozesslisten gehören.

Bewertung abschließen

Nachdem Sie das Inventar aus Ihrer Amazon RDS-Umgebung erstellt haben, schließen Sie die restlichen Aktivitäten der Bewertungsphase ab, wie unter Zu Google Cloud migrieren: Arbeitslasten bewerten und erkennen beschrieben.

Grundlage planen und aufbauen

In der Planungs- und Erstellungsphase stellen Sie die Infrastruktur bereit und konfigurieren sie für Folgendes:

• Unterstützung Ihrer Arbeitslasten in Ihrer Google Cloud-Umgebung.
• Verbinden Ihrer AWS-Umgebung und Ihrer Google Cloud-Umgebung, um die Migration abzuschließen.

Grundlage in Google Cloud erstellen

Die Planungs- und Erstellungsphase besteht aus den folgenden Aufgaben:

1. Erstellen Sie eine Ressourcenhierarchie.
2. Konfigurieren Sie die Identitäts- und Zugriffsverwaltung.
3. Richten Sie die Abrechnung ein.
4. Richten Sie die Netzwerkverbindung ein.
5. Erhöhen Sie die Sicherheit.
6. Logging, Monitoring und Benachrichtigungen einrichten

Weitere Informationen zu den einzelnen Aufgaben finden Sie unter Zu Google Cloud migrieren: Grundlage erstellen.

Monitoring und Benachrichtigungen

Verwenden Sie Google Cloud Monitoring, welches vordefinierte Dashboards für verschiedene Google Cloud-Produkte, einschließlich eines Monitoring-Dashboards von Cloud SQL enthält. Alternativ können Sie auch Überwachungslösungen von Drittanbietern verwenden, die in die Google Cloud integriert sind, wie Datadog und Splunk. Weitere Informationen finden Sie unter Beobachtbarkeit von Datenbanken

Amazon RDS for SQL Server-Instanzen zu Cloud SQL for SQL Server migrieren

So migrieren Sie Ihre Instanzen:

1. Wählen Sie die Migrationsstrategie aus: kontinuierliche Replikation oder geplante Wartung.

2. Wählen Sie die Migrationstools je nach gewählter Strategie und Anforderungen.

3. Definieren Sie den Migrationsplan und den Zeitplan für jede Datenbankmigration, einschließlich Vorbereitungs- und Ausführungsaufgaben.

4. Definieren Sie die Vorbereitungsaufgaben, die ausgeführt werden müssen, um sicherzustellen, dass das Migrationstool richtig funktionieren kann.

5. Definieren Sie die Ausführungsaufgaben, einschließlich der Arbeitsaktivitäten, die die Migration implementieren.

6. Definieren Sie Fallback-Szenarien für jede Ausführungsaufgabe.

7. Führen Sie Tests und Validierungen durch, die in einer separaten Staging-Umgebung durchgeführt werden können.

8. Führen Sie die Migration aus.

9. Führen Sie die Produktionsumstellung durch.

10. Bereinigen Sie die Quellumgebung und konfigurieren Sie die Zielinstanz.

11. Führen Sie eine Abstimmung und Optimierung durch.

Die einzelnen Phasen werden in folgenden Abschnitten beschrieben.

Migrationsstrategie auswählen

In diesem Schritt haben Sie genügend Informationen, um eine der folgenden Migrationsstrategien zu bewerten und auszuwählen, die am besten zu Ihrem Anwendungsfall für jede Datenbank passen:

• Geplante Wartung (auch als einmalige Migration bezeichnet): Dieser Ansatz ist ideal, wenn Sie sich Ausfallzeiten leisten können. Diese Option ist in Bezug auf Kosten und Komplexität relativ günstig, da Ihre Arbeitslasten und Dienste nicht viel Refaktorierung erfordern. Schlägt die Migration jedoch fehl, müssen Sie den Prozess neu starten, was die Ausfallzeit verlängert.

• Kontinuierliche Replikation (auch als „Trickle-Migration“ bezeichnet): Für geschäftskritischen Datenbanken bietet diese Option ein geringeres Risiko von Datenverlusten und nahezu keine Ausfallzeiten. Der Aufwand ist in mehrere Schritte unterteilt. Tritt ein Fehler auf, nehmen Rollback und Wiederholung weniger Zeit in Anspruch. Die Einrichtung ist jedoch komplexer und erfordert mehr Planung und Zeit. Zusätzlicher Aufwand ist auch für die Refaktorierung der Anwendungen erforderlich, die eine Verbindung zu Ihren Datenbankinstanzen herstellen. Betrachten Sie eine der folgenden Varianten:

  • Mit dem Ansatz Y (Schreiben und Lesen), der eine Form der parallelen Migration ist, bei der Daten aus beiden Quellen dupliziert und Zielinstanzen während der Migration erstellt werden.
  • Die Verwendung eines Mikrodiensts für den Datenzugriff, der den Refaktorierungsaufwand für den Ansatz Y (Schreiben und Lesen) reduziert.

Weitere Informationen zu Datenmigrationsstrategien finden Sie unter Datenmigrationsansätze bewerten.

Das folgende Diagramm zeigt ein Flussdiagramm, das auf Beispielfragen basiert, die Sie bei der Entscheidung über die Migrationsstrategie für eine einzelne Datenbank haben können:

Das obige Flussdiagramm zeigt die folgenden Entscheidungspunkte:

• Können Sie sich Ausfallzeiten leisten?

  • Falls nicht, übernehmen Sie die Migrationsstrategie für kontinuierliche Replikation.
  • Wenn ja, fahren Sie mit dem nächsten Entscheidungspunkt fort.

• Ist die Ausfallzeit in Form eines Umstellungsfensters für Sie beim Migrieren der Daten tragbar? Das Umstellungsfenster gibt an, wie lange es dauert, die Datenbank zu sichern, sie zu Cloud SQL zu übertragen, sie wiederherzustellen, und dann zu Ihren Anwendungen zu wechseln.

  • Falls nicht, übernehmen Sie die Migrationsstrategie für kontinuierliche Replikation.
  • Falls ja, wenden Sie die Migrationsstrategie für die geplante Wartung an.

Die Strategien können für verschiedene Datenbanken variieren, auch wenn sie sich auf derselben Instanz befinden. Eine Mischung von Strategien kann optimale Ergebnisse liefern. Beispiel: Migration kleiner und selten genutzter Datenbanken mit dem Ansatz der geplanten Wartung, aber kontinuierliche Replikation für geschäftskritische Datenbanken, bei denen Ausfallzeiten teuer sind.

Normalerweise gilt eine Migration als abgeschlossen, wenn der Wechsel zwischen der anfänglichen Quellinstanz und der Zielinstanz stattfindet. Jede Replikation (falls verwendet) wird gestoppt und alle Lese- und Schreibvorgänge werden auf der Zielinstanz ausgeführt. Das Wechseln, wenn beide Instanzen synchron sind, bedeutet keinen Datenverlust und minimale Ausfallzeiten.

Weitere Informationen zu Datenmigrationsstrategien und -bereitstellungen finden Sie unter Klassifizierung von Datenbankmigrationen und Bereitstellungsstrategien.

Ausfallzeiten und Auswirkungen auf die Migration minimieren

Migrationskonfigurationen, die keine Ausfallzeiten der Anwendung ermöglichen, erfordern eine kompliziertere Einrichtung. Finden Sie das richtige Gleichgewicht zwischen der Komplexität der Einrichtung und den Ausfallzeiten, die zu Zeiten mit geringem Trafficaufkommen geplant sind.

Jede Migrationsstrategie hat einen Kompromiss und einige Auswirkungen auf den Migrationsprozess. Replikationsprozesse erfordern z. B. eine zusätzliche Belastung Ihrer Quellinstanzen, und Ihre Anwendungen könnten durch die Replikationsverzögerung beeinträchtigt werden. Anwendungen (und Kunden) müssen möglicherweise während Ausfallzeiten der Anwendung warten, zumindest so lange, wie die Replikationsverzögerung vor der Verwendung andauert, bevor sie die neue Datenbank nutzen können. In der Praxis können folgende Faktoren die Ausfallzeiten erhöhen:

• Datenbankabfragen können einige Sekunden dauern. Zum Zeitpunkt der Migration können In-Flight-Abfragen abgebrochen werden.
• Es kann einige Zeit dauern, bis sich der Cache füllt, wenn die Datenbank groß ist oder über einen großen Pufferspeicher verfügt.
• Anwendungen, die in der Quelle beendet und in Google Cloud neu gestartet wurden, haben möglicherweise eine kleine Verzögerung bis zur Verbindung mit der Google Cloud Datenbankinstanz.
• Netzwerkrouten zu den Anwendungen müssen umgeleitet werden. Je nachdem, wie DNS-Einträge eingerichtet sind, kann dies einige Zeit dauern. Wenn Sie das DNS aktualisieren, reduzieren Sie TTL vor der Migration.

Mit den folgenden gängigen Vorgehensweisen können Sie Ausfallzeiten und Auswirkungen minimieren:

• Ermitteln Sie einen Zeitraum, in dem die Ausfallzeit eine minimale Auswirkung auf Ihre Arbeitslasten hat. Zum Beispiel außerhalb der normalen Geschäftszeiten, an Wochenenden oder während anderer geplanter Wartungsfenster.
• Identifizieren Sie Teile Ihrer Arbeitslasten, die in verschiedenen Phasen Migrations- und Produktionsumstellung durchlaufen können. Ihre Anwendungen haben möglicherweise verschiedene Komponenten, die isoliert, angepasst und migriert werden können, ohne das dies Auswirkungen hat. Beispiele: Frontends, CRM-Module, Backend-Dienste und Plattformen für das Berichtswesen. Solche Module könnten eigene Datenbanken haben, die zu einem früheren oder späteren Zeitpunkt für die Migration vorgesehen werden können.
• Wenn Sie sich eine gewisse Latenz für die Zieldatenbank leisten können, sollten Sie eine schrittweise Migration implementieren. Verwenden Sie inkrementelle, Batch-Datenübertragungen und passen Sie einen Teil Ihrer Arbeitslasten so an, dass sie mit den veralteten Daten auf der Zielinstanz arbeiten.
• Prüfen Sie, ob Sie Ihre Anwendungen so refaktorieren können, dass die Auswirkungen der Migration minimal sind. Passen Sie beispielsweise Ihre Anwendungen so an, dass sie sowohl in Quell- als auch in Zieldatenbanken schreiben können und implementieren Sie daher eine Replikation auf Anwendungsebene.

Auswahl der Tools für die Migration

Der wichtigste Faktor für eine erfolgreiche Migration ist die Auswahl des richtigen Migrationstools. Nachdem Sie eine Migrationsstrategie festgelegt haben, prüfen und entscheiden Sie sich für ein Migrationstool.

Es gibt viele Tools, die jeweils für bestimmte Migrationsanwendungsfälle optimiert sind. Beispiele für Anwendungsfälle:

• Migrationsstrategie (geplante Wartung oder kontinuierliche Replikation)
• Quell- und Ziel-Datenbankmodule und Engine-Versionen.
• Umgebungen, in denen sich Quell- und Zielinstanzen befinden.
• Datenbankgröße Je größer die Datenbank, desto länger dauert es, die erste Sicherung zu migrieren.
• Die Häufigkeit der Datenbankänderungen.
• Verfügbarkeit von verwalteten Diensten für die Migration

Für eine nahtlose Migration und Umstellung können Sie Anwendungsbereitstellungsmuster, Infrastrukturorchestrierung und benutzerdefinierte Migrationsanwendungen verwenden. Allerdings können spezielle Tools, die als verwaltete Migrationsdienste bezeichnet werden, das Verschieben von Daten, Anwendungen oder sogar ganzen Infrastrukturen von einer Umgebung in eine andere erleichtern. Sie führen die Datenextraktion aus den Quelldatenbanken aus, übertragen Daten sicher in die Zieldatenbanken und können die Daten während der Übertragung optional ändern. Mit diesen Funktionen kapseln sie die komplexe Logik der Migration ein und bieten Funktionen zur Überwachung der Migration.

Verwaltete Migrationsdienste bieten folgende Vorteile:

• Ausfallzeiten minimieren: Dienste verwenden die integrierten Replikationsfunktionen der Datenbankmodule, sofern verfügbar, und stufen Replikate hoch.

• Datenintegrität und -sicherheit gewährleisten: Die Daten werden sicher und zuverlässig von der Quell- zur Zieldatenbank übertragen.

• Konsistente Migration: Andere Migrationsverfahren und -muster können durch die Verwendung von ausführbaren Datenbankmigrationsdateien, die Sie verwalten und überwachen können, in einer konsistenten, gemeinsamen Schnittstelle konsolidiert werden.

• Stabile und bewährte Migrationsmodelle anbieten: Datenbankmigrationen sind seltene, aber wichtige Ereignisse. Um Fehler und Probleme mit bestehenden Lösungen für Anfänger zu vermeiden, können Sie Tools von erfahrenen Experten verwenden, anstatt eine benutzerdefinierte Lösung zu erstellen.

• Kosten optimieren: Verwaltete Migrationsdienste können höhere Kosten verursachen als zusätzliche Server und Ressourcen für benutzerdefinierte Migrationslösungen bereitzustellen.

In den nächsten Abschnitten werden die Empfehlungen für das Migrationstool beschrieben, die von der ausgewählten Migrationsstrategie abhängen.

Tools für geplante Wartungsmigrationen

In den folgenden Unterabschnitten werden die Tools, die für einmalige Migrationen verwendet werden können, sowie deren Einschränkungen und Best Practices, beschrieben.

Integrierte Sicherungen des Datenbankmoduls

Wenn erhebliche Ausfallzeiten akzeptabel sind und Ihre Quelldatenbanken relativ statisch sind, können Sie die integrierten Sicherungs- und Wiederherstellungsfunktionen des Datenbankmoduls verwenden.

Die Einrichtung und Synchronisierung ist etwas aufwendiger, insbesondere bei einer großen Anzahl von Datenbanken. Sicherungen von Datenbankmodulen sind jedoch in der Regel leicht verfügbar und einfach zu verwenden. Dieser Ansatz eignet sich für jede Datenbankgröße und ist in der Regel effektiver als andere Tools für große Instanzen.

Für Sicherungen von Datenbankmoduls gelten die folgenden allgemeinen Einschränkungen:

• Sicherungen können fehleranfällig sein, insbesondere wenn sie manuell durchgeführt werden.
• Daten sind nicht gesichert, wenn die Sicherungen nicht ordnungsgemäß verwaltet werden.
• Sicherungen bieten keine geeigneten Monitoringfunktionen.

Beachten Sie für diesen Ansatz die folgenden Einschränkungen und Best Practices:

• Verwenden Sie für Sicherungen von Datenbanken, die größer als 5 TB sind, eine Stripe-Sicherung (eine Sicherung mehrerer Dateien).
• Wenn Sie eine Stripe-Sicherung verwenden, können Sie nicht mehr als zehn Sicherungsdateien gleichzeitig sichern oder wiederherstellen.
• Sie müssen in einem Amazon S3-Bucket in derselben Amazon-Region Ihrer Quelldatenbankinstanz gespeichert werden.
• Sicherungen enthalten keine SQL Server-Anmeldungen, ‐Berechtigungen und Serverrollen, da sie sich auf Instanzebene befinden. Um diesen Datentyp von der Quellinstanz zur Zielinstanz zu übertragen, verwenden Sie PowerShell-Skripte oder Tools wie DBAtools.

Weitere Informationen zu Einschränkungen und Best Practices finden Sie unter Best Practices für das Importieren und Exportieren von Daten mit Cloud SQL für SQL Server und Bekannte Probleme bei Cloud SQL for SQL Server.

Andere Ansätze für geplante Wartungsmigrationen

Die Verwendung anderer Ansätze ermöglicht mehr Kontrolle und Flexibilität für Ihren geplanten Wartungsmigrationsprozess.

Zum Beispiel durch Verwendung von Flatfiles zum Exportieren und Importieren Ihrer Daten (oder durch Verwendung benutzerdefinierter Skripts) haben Sie folgende Möglichkeiten:

• Während der Migration Daten transformieren, prüfen oder andere Vorgänge ausführen. Zum Beispiel Validierungen, Aggregation oder Normalisierung und Denormalisierung Ihrer Quelldaten.
• Auswählen, welche Strukturen migriert werden sollen und welche nicht. Vielleicht möchten Sie auch nur einen Teil Ihrer Tabellen in Flatfiles für den Import extrahieren.
• Daten nach Domain, Quelle, Alter oder anderen benutzerdefinierten Kriterien filtern. Sie haben beispielsweise die Möglichkeit, Daten auszuschließen, die einen Altersschwellenwert erreichen, und sie vor der Migration in Dateien oder der letzten Sicherung der Quelldatenbank zu speichern.
• Ihre Datenbankstrukturen refaktorieren und die anfallende Ausfallzeit mit der Migrationsausfallzeit synchronisieren.
• Mehrere Instanzen oder Datenbanken in einer einzigen Instanz oder Datenbank konsolidieren, um die Betriebskosten zu minimieren und Skalierbarkeitsprobleme zu verringern. Sie können beispielsweise Ihren Ansatz von einer Instanz, Datenbank oder einem Schema pro Kunde zu einer einzigen für Mandantenfähigkeit optimierten Datenbankstruktur ändern.

Weitere Ansätze sind:

• CSV- oder JSON-Dateien verwenden: Bei diesem Ansatz extrahieren Sie die Daten der Datenbank in die Dateien und importieren die Dateien anschließend in Ihre Zielinstanzen.

  • Diese Methode ist in der Regel langsamer, hilft Ihnen aber, eine Teilmenge von Tabellen (oder Daten in einer bestimmten Tabelle) zu migrieren.
  • Die CSV- und JSON-Formate werden von vielen Tools verstanden.
  • Wenn Sie den Prozess automatisieren, haben Sie die Möglichkeit, zu einer Batch-Migration mit kontinuierlicher Replikation überzugehen.

• Verwenden Sie den SQL Server Import- und Export-Assistent von Microsoft: Dieses Tool verwendet die SQL Server-Integration Services (SSIS) und ermöglicht den Import von Daten aus verschiedenen Quellen, wie z. B. aus Datenbankmodulen oder Flatfiles.

• Verwenden Sie den Assistent zum Generieren und Veröffentlichen von SQL Server-Skripts und bcp-Dienstprogramm: Dieses Tool ist Teil von Microsoft SQL Server Management Studio.

  • So können Sie Skripts entweder für Ihr gesamtes Datenbankschema oder nur für Teile davon erstellen.
  • Mit dem bcp-Dienstprogramm können Sie ein Skript für die Daten erstellen und sie in Dateien exportieren.

• Snapshot-Replikation verwenden, wenn Ihre Quelle Amazon RDS Standard verwendet:

  • Bei diesem Ansatz stellen Sie die SQL Server-Sicherung der RDS-Instanz zu einer anderen eigenständigen Instanz von SQL Server in Compute Engine wieder her. Verwenden Sie dann die Snapshot-Replikation, um zu Cloud SQL for SQL Server zu migrieren.
  • Bei der Snapshot-Generierung werden Sperren für Quelltabellen beibehalten, was sich möglicherweise auf Ihre Arbeitslasten auswirkt.
  • Die Snapshot-Replikation kann zusätzliche Lasten auf Ihrem Amazon RDS-Server einführen.
  • Sie können jedoch auswählen, welche Objekte migriert oder repliziert werden, was Flexibilität bietet.
  • Details finden Sie unter Daten mithilfe von Snapshot-Replikation von SQL Server 2017 zu Cloud SQL for SQL Server migrieren.

Tools für Migrationen mit kontinuierlichen Replikationen

Das folgende Diagramm zeigt ein Flussdiagramm mit Fragen, die Ihnen bei der Auswahl des Migrationstools für eine einzelne Datenbank bei Verwendung einer Migrationsstrategie für kontinuierliche Replikation helfen können:

Das obige Flussdiagramm zeigt die folgenden Entscheidungspunkte:

• Möchten Sie verwaltete Migrationsdienste verwenden?

  • Falls ja, fahren Sie mit der nächsten Entscheidung fort. Wenn Sie sich minimale Ausfallzeiten erlauben können und keine Datentransformation oder Synchronisation in Echtzeit benötigen, empfehlen wir Database Migration Service. Andernfalls sollten Sie die Optionen von Drittanbietern prüfen.
  • Falls nicht, fahren Sie mit der nächsten Entscheidung fort. Wenn die integrierte Replikation des Datenbankmoduls unterstützt wird, empfehlen wir die Verwendung der integrierten Replikation. Falls nicht, sollten Sie andere Migrationsoptionen ausprobieren.

• Können Sie sich eine minimale Ausfallzeit leisten und ohne Datentransformation oder Echtzeitsynchronisierung migrieren?

  • Wenn ja, empfehlen wir Database Migration Service.
  • Falls nein, prüfen Sie Drittanbieter-Optionen.

• Wird die spezifische integrierte Replikation des Datenbankmoduls unterstützt?

  • Wenn ja, empfehlen wir die Verwendung der integrierten Replikation.
  • Falls nein, sollten Sie andere Migrationsoptionen in Betracht ziehen.

In den folgenden Abschnitten werden die Tools beschrieben, die für kontinuierliche Replikationsmigrationen verwendet werden können, zusammen mit ihren Einschränkungen und Best Practices.

Database Migration Service für kontinuierliche Replikationsmigration

Database Migration Service unterstützt homogene Migrationen zu Cloud SQL for SQL Server, wenn Amazon RDS die Quelle ist.

Database Migration Service ist ein kostengünstiges und unkompliziertes Tool. Wir empfehlen Database Migration Service für Situationen mit folgenden Umständen:

• Sie sollten sich eine minimale Ausfallzeit leisten können.
• Eine Echtzeitsynchronisierung ist nicht erforderlich.
• Während der Migration müssen keine Datentransformationen durchgeführt werden.

Beachten Sie bei der Auswahl dieses Tools die folgenden Einschränkungen und Best Practices:

• Die Ausfallzeit hängt von der Häufigkeit des Sicherung der Transaktionslogs ab:
• Sicherungen enthalten keine SQL Server-Anmeldungen, -Berechtigungen oder -Serverrollen, da sie auf Instanzebene erfolgen. Schreiben Sie sie aus der Quellinstanz und übertragen sie dann mithilfe von PowerShell-Scripts oder -Tools wie DBAtools.

Eine vollständige Liste der Beschränkungen finden Sie unter bekannte Einschränkungen.

Integrierte Replikation des Datenbankmoduls

Cloud SQL unterstützt die Replikation für SQL Server. Standard-Amazon RDS für SQL Server kann jedoch nur Abonnent sein. Integrierte Replikation von Amazon RDS Standard ist nicht verfügbar. Nur Amazon RDS Custom for SQL Server kann als integrierter Publisher eingerichtet werden.

Eine Liste der unterstützten und nicht unterstützten Funktionen in Amazon RDS finden Sie unter Amazon RDS für Microsoft SQL Server

Andere Ansätze für die Migration einer kontinuierlichen Replikation

Weitere Ansätze für die Migration der kontinuierlichen Replikation:

• Anwendungen refaktorieren, um J (Schreiben und Lesen) auszuführen oder einen Mikrodienst für den Datenzugriff verwenden.

  • Die fortlaufende Replikation wird von Ihren Anwendungen ausgeführt.
  • Die Migration konzentriert sich auf die Refaktorierung oder Entwicklung von Tools, die Verbindungen zu Ihren Datenbankinstanzen herstellen.
  • Leseranwendungen werden nach und nach refaktoriert und bereitgestellt, um die Zielinstanz zu verwenden.

• Funktionen implementieren, die in regelmäßigen Abständen Daten in Ihrer Quellinstanz abfragen, nur neue Daten herausfiltern und Daten in CSV-, JSON- oder Parquet-Dateien schreiben.

  • Diese Dateien werden in einem Google Cloud Storage-Bucket gespeichert.
  • Die Dateien können mithilfe von Cloud Functions sofort in Ihre Zieldatenbankinstanz geschrieben werden.
  • Change Data Capture (CDC)-Funktionen können Replikationsmigration nahezu in Echtzeit durchführen.
  • Sie können CDC in einen Amazon S3-Data Lake im Parquet-Format streamen. Verwenden Sie dazu AWS Database Migration Service (AWS DMS).
  • Sie können eine benutzerdefinierte Implementierung haben, um die Dateien zu lesen und ihren Inhalt in Cloud SQL zu schreiben.

Drittanbietertools für kontinuierliche Replikationsmigrationen

Wenn Sie ein Drittanbieter-Tool verwenden möchten, können Sie eine der folgenden Empfehlungen wählen, die Sie für die meisten Datenbankmodule verwenden können.

Striim ist eine End-to-End-In-Memory-Plattform zum Erfassen, Filtern, Transformieren, Anreichern, Zusammenfassen, Analysieren und Bereitstellen von Daten in Echtzeit:

• Vorteile:

  • Bewältigt große Datenmengen und komplexe Migrationen.
  • Integrierte Change Data Capture für SQL Server.
  • Vorkonfigurierte Verbindungsvorlagen und Pipelines ohne Code.
  • Kann geschäftskritische, große Datenbanken bewältigen, die unter hoher Transaktionslast ausgeführt werden.
  • Genau einmalige Zustellung.

• Nachteile:

  • Kein Open Source.
  • Kann teuer werden, insbesondere bei langen Migrationen.
  • Einige Einschränkungen bei der Weitergabe von DDL-Vorgängen (Data Definition Language). Weitere Informationen finden Sie unter Unterstützte DDL-Vorgänge und Hinweise und Einschränkungen zur Schemaentwicklung.

Weitere Informationen zu Striim finden Sie unter Striim in der Google Cloud ausführen

Debezium ist eine verteilte Open-Source-Plattform für CDC, die Datenänderungen an externe Abonnenten streamt:

• Vorteile:

  • Open Source
  • Starke Community-Unterstützung.
  • Kostengünstig
  • Detaillierte Steuerung von Zeilen, Tabellen oder Datenbanken
  • Spezialisiert auf die Erfassung von Änderungen in Echtzeit aus Datenbank-Transaktionslogs.

• Herausforderungen:

  • Erfordert spezifische Erfahrung mit Kafka und ZooKeeper.
  • Datenänderungen werden mindestens einmal übermittelt, was bedeutet, dass Sie Duplikate verarbeiten müssen.
  • Manuelles Monitoring von Monitoring mit Grafana und Prometheus
  • Keine Unterstützung für inkrementelle Batchreplikation.

Weitere Informationen zu Debezium-Migrationen finden Sie unter Nahezu-in-Echtzeit-Datenreplikation mit Debezium.

Migrationsplan und Zeitplan definieren

Für eine erfolgreiche Datenbankmigration und Produktionsumstellung empfehlen wir die Vorbereitung eines klar definierten, umfassenden Migrationsplans. Wir empfehlen Ihnen, eine Liste aller erforderlichen Arbeitsaufgaben zu erstellen, um die Auswirkungen auf Ihr Unternehmen zu reduzieren.

Durch das Definieren des Migrationsbereichs werden die Arbeitsaufgaben angezeigt, die Sie vorab, während und nach der Datenbankmigration erledigen müssen. Wenn Sie beispielsweise bestimmte Tabellen nicht aus einer Datenbank migrieren möchten, benötigen Sie möglicherweise Aufgaben vor oder nach der Migration, um diese Filterung zu implementieren. Achten Sie außerdem darauf, dass sich die Datenbankmigration nicht auf Ihr vorhandenes Service Level Agreement (SLA) und Ihren Geschäftskontinuitätsplan auswirkt.

Ihre Dokumentation zur Migrationsplanung sollte folgende Dokumente enthalten:

• Technical Design Document (TDD)
• RACI-Matrix
• Zeitplan (z. B. ein T-Minus-Plan)

Datenbankmigrationen sind ein iterativer Prozess und die ersten Migrationen sind häufig langsamer als die späteren. Normalerweise verlaufen gut geplante Migrationen ohne Probleme, doch ungeplante Probleme können trotzdem auftreten. Wir empfehlen Ihnen, immer einen Rollback-Plan zu haben. Befolgen Sie als Best Practice die Anweisungen aus: Migration zu Google Cloud: Best Practices zum Validieren eines Migrationsplans

TDD

Der TDD dokumentiert alle technischen Entscheidungen, die für das Projekt getroffen werden müssen. Schließen Sie Folgendes im TDD ein:

• Geschäftsanforderungen und Wichtigkeit
• Recovery Time Objective (RTO)
• Recovery Point Objective (RPO)
• Details zur Datenbankmigration
• Schätzungen des Migrationsaufwands
• Empfehlungen für die Migrationsvalidierung

RACI-Matrix

Einige Migrationsprojekte erfordern eine RACI-Matrix. Dabei handelt es sich um ein allgemeines Projektmanagementdokument, das definiert, welche Personen oder Gruppen für Aufgaben und Ergebnisse im Migrationsprojekt verantwortlich sind.

Zeitplan

Bereiten Sie einen Zeitplan für jede zu migrierende Datenbank vor. Schließen Sie alle auszuführenden Aufgaben und ein und legen Sie Start- und Endtermine fest.

Wir empfehlen, für jede Migrationsumgebung einen T-Minus-Plan zu erstellen. Ein T-Minus-Plan ist als Countdown-Zeitplan strukturiert, der alle zum Durchführen des Migrationsprojekts erforderlichen Aufgaben sowie die zuständigen Gruppen und die geschätzte Dauer auflistet.

Der Zeitplan sollte nicht nur die Ausführung von Vorbereitungsaufgaben vor der Migration, sondern auch Validierungs-, Audit- oder Testaufgaben berücksichtigen, die nach der Datenübertragung erfolgen.

Die Dauer der Migrationsaufgaben hängt in der Regel von der Datenbankgröße ab, aber auch andere Aspekte sind zu berücksichtigen, wie die Komplexität der Geschäftslogik, Anwendungsnutzung und Teamverfügbarkeit.

Ein T-Minus-Plan könnte so aussehen:

Datum	Phase	Kategorie	Aufgaben	Rolle	T-Minus	Status
1.11.2023	Vor der Migration	Aufgabe	Bewertungsbericht erstellen	Discovery-Team	-21	Fertig
7.11.2023	Vor der Migration	Zielvorbereitung	Entwurf der Zielumgebung, wie im Designdokument beschrieben	Migrationsteam	-14	Fertig
15.11.2023	Vor der Migration	Unternehmens-Governance	Migrationsdatum und T-Minus-Genehmigung	Leitende Positionen	-6	Fertig
18.11.2023	Migration	DMS einrichten	Verbindungsprofile erstellen	Cloud Migration Engineer	-3	Fertig
19.11.2023	Migration	DMS einrichten	Migrationsjobs erstellen und starten	Cloud Migration Engineer	-2	Nicht gestartet
19.11.2023	Migration	DMS überwachen	DMS-Jobs und DDL-Änderungen in der Quellinstanz überwachen	Cloud Migration Engineer	-2	Nicht gestartet
21.11.2023	Migration	DMS umstellen	DMS-Replikat hochstufen	Cloud Migration Engineer	0	Nicht gestartet
21.11.2023	Migration	Migrationsvalidierung	Validierung der Datenbankmigration	Migrationsteam	0	Nicht gestartet
21.11.2023	Migration	Anwendungstest	Funktions- und Leistungstests ausführen	Migrationsteam	0	Nicht gestartet
22.11.2023	Migration	Unternehmens-Governance	Migrationsvalidierung GO oder NO GO	Migrationsteam	1	Nicht gestartet
23.11.2023	Nach der Migration	Monitoring validieren	Monitoring konfigurieren	Infrastrukturteam	2	Nicht gestartet
25.11.2023	Nach der Migration	Sicherheit	DMS-Nutzerkonto entfernen	Sicherheitsteam	4	Nicht gestartet

Mehrere Datenbankmigrationen

Wenn Sie mehrere Datenbanken migrieren möchten, sollte Ihr Migrationsplan Aufgaben für alle Migrationen enthalten.

Wir empfehlen, den Prozess mit der Migration einer kleineren, idealerweise nicht geschäftskritischen Datenbank zu beginnen. Dieser Ansatz kann Ihnen dabei helfen, Ihr Wissen und Ihr Vertrauen in den Migrationsprozess und die Tools zu erweitern. Sie können Schwachstellen im Prozess auch in den frühen Phasen des gesamten Migrationsplans erkennen.

Wenn Sie mehrere Datenbanken migrieren müssen, können die Zeitpläne parallelisiert werden. Wenn Sie beispielsweise den Migrationsprozess beschleunigen möchten, können Sie eine Gruppe von kleinen, statischen oder weniger geschäftskritischen Datenbanken gleichzeitig migrieren, wie im folgenden Diagramm dargestellt.

Im im Diagramm dargestellten Beispiel sind die Datenbanken 1-4 eine Gruppe kleiner Datenbanken, die gleichzeitig migriert werden.

Vorbereitungsaufgaben definieren

Die Vorbereitungsaufgaben sind alle Aktivitäten, die Sie durchführen müssen, um die Voraussetzungen für die Migration zu erfüllen. Ohne die Vorbereitungsaufgaben kann die Migration nicht erfolgen oder führt dazu, dass sich die migrierte Datenbank in einem nicht verwendbaren Zustand befindet.

Vorbereitungsaufgaben können so kategorisiert werden:

• Amazon RDS-Instanzen – Vorbereitungen und Voraussetzungen
• Vorbereitung der Quelldatenbank und Voraussetzungen
• Cloud SQL-Einrichtung
• Migrationsspezifische Einrichtung

Amazon RDS-Instanz – Vorbereitung und Voraussetzungen

Beachten Sie die folgenden gängigen Einrichtungs- und erforderlichen Aufgaben:

• Je nach Migrationspfad müssen Sie möglicherweise Remote-Verbindungen auf Ihren RDS-Instanzen zulassen. Wenn Ihre RDS-Instanz in Ihrer VPC als privat konfiguriert ist, muss eine private RFC 1918-Verbindung zwischen Amazon und Google Cloud bestehen.

• Möglicherweise müssen Sie eine neue Sicherheitsgruppe konfigurieren, um Remote-Verbindungen zu erforderlichen Ports zu zulassen.

  • In AWS ist der Netzwerkzugriff für Datenbankinstanzen standardmäßig deaktiviert.
  • Sie können Regeln in einer Sicherheitsgruppe festlegen, die den Zugriff von z.  . einem IP-Adressbereich, ein Port oder eine Sicherheitsgruppe zu zulassen. Dieselben Regeln gelten für alle Datenbankinstanzen, die dieser Sicherheitsgruppe zugeordnet sind.

• Für die fortlaufende Replikation (Streamingänderungen über CDC) müssen Sie eine vollständige RDS-Instanz und kein Lesereplikat mit aktiviertem CDC verwenden. Weitere Informationen siehe Change Data Capture mit SQL Server verwenden

• Wenn Sie Tools von Drittanbietern verwenden, sind in der Regel Voreinstellungen und Konfigurationen erforderlich, bevor Sie das Tool verwenden. Prüfen Sie die Dokumentation des Drittanbietertools.

Vorbereitung der Quelldatenbank und Voraussetzungen

• Achten Sie darauf, dass die Quelldatenbank während der Migrationsvorgänge Pufferspeicher und Arbeitsspeicher hat. Wenn Sie zum Beispiel Sicherungsdateien für Transaktionslogs verwenden, überwachen Sie die Speichernutzung und stellen Sie sicher, dass Sie über zusätzlichen Pufferspeicherplatz verfügen.
• Dokumentieren Sie die Einstellungen Ihrer Datenbankparameter und wenden Sie sie auf Ihre Zielinstanz an, bevor Sie Migrationstests und Validierungen durchführen.

• Führen Sie Referenzmessungen an der Quellumgebung in der Produktion durch. Beachten Sie dabei Folgendes:

  • Messen Sie die Größe Ihrer Daten sowie die Leistung Ihrer Arbeitslast. Wie lange dauern wichtige Abfragen oder Transaktionen durchschnittlich? Wie lange zu Spitzenzeiten?
  • Dokumentieren Sie die Basismessungen für einen späteren Vergleich, damit Sie entscheiden können, ob die Genauigkeit Ihrer Datenbankmigration zufriedenstellend ist. Entscheiden Sie, ob Sie Ihre Produktionsarbeitslasten wechseln und die Quellumgebung außer Betrieb nehmen können oder ob Sie sie noch für Fallback-Zwecke benötigen.

Cloud SQL-Einrichtung

Wählen Sie die Größe und die Spezifikationen Ihrer Cloud SQL-Zielinstanz sorgfältig aus, um die Quelle für ähnliche Leistungsanforderungen anzupassen. Achten Sie besonders auf die Laufwerkgröße und den Durchsatz, die IOPS und die Anzahl der vCPUs. Falsche Größen können zu langen Migrationszeiten, Problemen mit der Datenbankleistung, Datenbankfehlern und Probleme mit der Anwendungsleistung führen.

Prüfen Sie, ob das Ziel korrekt passt. Es ist wichtig zu beachten, dass die Konfigurationsoptionen für Amazon RDS von Cloud SQL variieren können. Falls Cloud SQL Ihre Anforderungen nicht erfüllt, sollten Sie Optionen erwägen. die Datenbanken in Compute Engine enthalten.

Sie müssen die folgenden Eigenschaften und Anforderungen bestätigen, bevor Sie Ihre Cloud SQL-Instanzen erstellen, da sie später nicht geändert werden könne, ohne sie neu zu erstellen.

• Wählen Sie das Projekt und die Region Ihrer Ziel-Cloud-SQL-Instanzen sorgfältig aus. Cloud SQL-Instanzen können ohne Datenübertragung nicht zwischen Google Cloud-Projekten und Regionen migriert werden.

• Migrieren Sie zu einer übereinstimmenden Hauptversion in Cloud SQL. Wenn Ihre Quelle beispielsweise SQL Server 15.0 verwendet, migrieren Sie zu Cloud SQL for SQL Server 15.0. Wenn sich die Versionen unterscheiden, sollte die Einstellung der Kompatibilitätsstufe identisch sein, damit dieselben Engine-Funktionen gewährleistet sind.

• Replizieren Sie die Benutzerinformationen separat, wenn Sie integrierte Datenbank-Engine-Backups oder Database Migration Service verwenden. Einzelheiten hierzu finden Sie im Abschnitt Datenbankmodulspezifische Sicherungen .

• Prüfen Sie die spezifischen Konfigurations-Flags des Datenbankmoduls und vergleichen Sie deren Quell- und Zielinstanzwerte. Stellen Sie sicher, dass Sie deren Auswirkungen verstehen und ob sie gleich sein müssen oder nicht. Vergleichen Sie z. B. die Werte in der Ansicht „sys.configurations“ in der Quelldatenbank mit den Werten in der Cloud SQL-Instanz. Beachten Sie, dass nicht alle Flags gleich sein müssen und nicht alle Flagänderungen sind auf einer Cloud SQL-Instanz zulässig.

Weitere Informationen zur Einrichtung von Cloud SQL finden Sie hier:

• Allgemeine Best Practices für SQL Server
• Konfigurationsoptionen für Instanzen für SQL Server
• Datenbankmodulspezifische Flags für SQL Server

Migrationsspezifische Einrichtung

Wenn Sie zur Migration den Dateiexport und -import verwenden oder das Migrationstool von Database Migration Service verwenden, müssen Sie einen Cloud Storage-Bucket erstellen. Im Bucket werden die Datenbank- und Transaktionslog-Sicherungsdateien gespeichert. Weitere Informationen zur Verwendung von Database Migration Service, siehe Sicherungsdateien in einem Cloud Storage-Bucket speichern

Wenn Sie Replikation verwenden, müssen Sie dafür sorgen, dass das Cloud SQL-Replikat Zugriff auf Ihre primäre Datenbank hat. Dies kann mithilfe der dokumentierten Verbindungsoptionen erreicht werden.

Je nach Szenario und Kritik müssen Sie möglicherweise ein Fallback-Szenario implementieren, das in der Regel die Umkehrung der Replikationsrichtung beinhaltet. In diesem Fall benötigen Sie möglicherweise einen zusätzlichen Replikationsmechanismus von Cloud SQL zurück zur Amazon-Quellinstanz.

Bei den meisten Drittanbietertools müssen Sie migrationsspezifische Ressourcen bereitstellen. Für Striim müssen Sie beispielsweise zuerst den Google Cloud Marketplace verwenden. Zum Einrichten Ihrer Migrationsumgebung in Striim können Sie dann Anwendungen mit dem Ablaufdesigner erstellen und ändern oder eine bereits vorhandene Vorlage auswählen. Anwendungen können auch mithilfe der Programmiersprache Tungsten Query Language (TQL) codiert werden. Mit einem Datenvalidierungs-Dashboard erhalten Sie eine visuelle Darstellung der von Ihrer Striim-Anwendung verarbeiteten Daten

Sie können die Ressourcen außer Betrieb nehmen, die Ihre Amazon- und Google Cloud-Umgebung verbinden, nachdem die Migration abgeschlossen und validiert ist.

Ausführungsaufgaben definieren

Ausführungsaufgaben implementieren die Migrationsarbeit selbst. Die Aufgaben hängen vom ausgewählten Migrationstool ab, wie in den folgenden Unterabschnitten beschrieben.

Datenbankmodulspezifische Sicherungen

Weitere Informationen und Anleitungen für datenbankspezifische Sicherungen finden Sie unter Importieren von Daten aus einer BAK-Datei in Cloud SQL für SQL Server und Exportieren von Daten aus RDS für SQL Server. Weitere Informationen zum Automatisieren von Dateiuploads von Transaktionsprotokollen finden Sie unter Planen Sie Uploads von Transaktionslogdateien für Amazon RDS.

Database Migration Service-Migrationsjobs

Definieren und konfigurieren Sie Migrationsjobs in Database Migration Service, um Daten aus einer Quellinstanz in die Zieldatenbank zu migrieren. Migrationsjobs stellen über benutzerdefinierte Verbindungsprofil eine Verbindung zur Quelldatenbankinstanz her.

Testen Sie alle Voraussetzungen, um sicherzustellen, dass der Job erfolgreich ausgeführt werden kann. Wählen Sie einen Zeitpunkt aus, zu dem Ihre Arbeitslasten eine kleine Ausfallzeit für die Migration und Produktionsumstellung tolerieren können.

Der Migrationsprozess umfasst in der Regel die folgenden Aufgaben:

• Exportieren Sie eine vollständige Sicherung der Quelldatenbank und laden Sie sie dann in einen Cloud Storage-Bucket.
• Erstellen Sie eine Sicherung der Transaktionslog-Dateien und laden Sie sie in denselben Cloud Storage-Bucket hoch. Weitere Informationen dazu, wie Sie diesen Prozess automatisieren, siehe Planen Sie Uploads von Transaktionslogdateien für Amazon RDS.
• In Database Migration Service überwachen Sie die Verarbeitung der Sicherungen der Transaktionslogs.
• Beenden Sie das Schreiben in die Quelldatenbank.
• Warten Sie, bis die Quelle und das Ziel synchronisiert wurden. Dies ist der Zeitpunkt, zu dem die endgültige Sicherung des Transaktionslogs verarbeitet wird.
• Beenden Sie die laufende Replikation und stufen Sie den Migrationsjob hoch.Durch das Hochstufen eines Migrationsjobs wird die Cloud SQL-Zielinstanz von der Quelldatenbankinstanz getrennt und dann zu einer primären Instanz hochgestuft.
• Stellen Sie die Anwendungen bereit, die auf die neue Zieldatenbank verweisen.

Detaillierte Informationen zum Einrichten der Migration finden Sie unter SQL Server-Datenbanken zu Cloud SQL for SQL Server migrieren

Integrierte Replikation des Datenbankmoduls

Wenn Sie Amazon RDS Standard verwenden, müssen Sie möglicherweise zuerst zur benutzerdefinierten Amazon RDS-Version migrieren und dann nach Cloud SQL replizieren.

Cloud SQL unterstützt die Replikation für SQL Server. Weitere Informationen zur Replikation von einem externen Server finden Sie unter Daten mithilfe von Snapshot-Replikation von SQL Server 2017 zu Cloud SQL for SQL Server migrieren

Drittanbieter-Tools

Definieren Sie alle Ausführungsaufgaben für das ausgewählte Drittanbieter-Tool. Wenn Sie sich beispielsweise für die Verwendung von Striim entscheiden, müssen Sie Anwendungen in Ihrem Namespace erstellen und den CDC-Leser so konfigurieren, dass eine Verbindung zur Amazon-Instanz hergestellt wird. Weitere Informationen finden Sie unter SQL Server-Einrichtung in der Striim-Dokumentation

Fallback-Szenarien definieren

Definieren Sie Fallback-Aktionselemente für jede Migrationsausführungsaufgabe zum Schutz vor unvorhergesehenen Problemen während des Migrationsprozesses. Die Fallback-Aufgaben hängen in der Regel von der verwendeten Migrationsstrategie und den verwendeten Tools ab.

Das Fallback erfordert unter Umständen einen erheblichen Aufwand. Führen Sie die Umstellung der Produktion am besten erst durch, wenn die Testergebnisse zufriedenstellend sind. Die Datenbankmigration und das Fallback-Szenario sollten ordnungsgemäß getestet werden, um schwerwiegende Ausfälle zu vermeiden.

Definieren Sie Erfolgskriterien und einen Zeitrahmen für alle Aufgaben zur Migrationsausführung. Durch einen Probelauf für die Migration können Sie Informationen zu den erwarteten Zeiten für jede Aufgabe erfassen. Bei einer geplanten Wartungsmigration können Sie sich zum Beispiel die Ausfallzeit leisten, die durch das Umstellungsfenster dargestellt wird. Es ist jedoch wichtig, Ihre nächste Aktion zu planen, falls der einmalige Migrationsjob oder die Wiederherstellung der Sicherung mit der Zeit fehlschlägt. Je nachdem, wie viel Zeit Ihre geplante Ausfallzeit verstrichen ist, müssen Sie möglicherweise die Migration verschieben, wenn die Migrationsaufgabe nicht im erwarteten Zeitraum abgeschlossen ist.

Ein Fallback-Plan bezieht sich in der Regel darauf, die Migration nach der Produktionsumstellung rückgängig zu machen, falls Probleme mit der Zielinstanz auftreten. Denken Sie beim Implementieren eines Fallback-Plans daran, dass dieser als vollständige Datenbankmigration behandelt werden muss, einschließlich Planung und Tests.

Wenn Sie sich gegen einen Fallback-Plan entscheiden, müssen Sie die möglichen Folgen verstehen. Wenn Sie keinen Fallback-Plan haben, kann dies zu unvorhergesehenen Aufwand führen und zu vermeidbaren Unterbrechungen im Migrationsprozess führen.

Ein Fallback ist zwar das letzte Mittel, das von den meisten Datenbankmigrationen nicht verwendet wird, wir empfehlen jedoch, immer eine Fallback-Strategie zu verwenden.

Einfaches Fallback

Bei dieser Fallback-Strategie stellen Sie Ihre Anwendungen wieder auf die ursprüngliche Quelldatenbankinstanz um. Verwenden Sie diese Strategie, wenn Sie Ausfallzeiten in Kauf nehmen können, wenn Sie ein Fallback ausführen, oder wenn Sie die Transaktionen nicht mit Commit im neuen Zielsystem ausführen müssen.

Wenn Sie alle geschriebenen Daten in Ihrer Zieldatenbank benötigen und eine gewisse Ausfallzeit tragbar ist, können Sie Schreibvorgänge auf Ihre Zieldatenbankinstanz beenden, integrierte Sicherungen erstellen und diese auf Ihrer Quellinstanz wiederherstellen. und Ihre Anwendungen dann wieder mit der ursprünglichen Quelldatenbankinstanz verbinden. Je nach Art der Arbeitslast und der in der Zieldatenbankinstanz geschriebenen Datenmenge können Sie diese zu einem späteren Zeitpunkt in Ihr ursprüngliches Quelldatenbanksystem einbringen, insbesondere wenn Ihre Arbeitslast nicht von einem bestimmten Erstellungszeitpunkt der Datensätze oder von zeitlichen Beschränkungen abhängig ist.

Rückwärtsreplikation

Bei dieser Strategie replizieren Sie die Schreibvorgänge, die für Ihre neue Zieldatenbank nach der Produktionsumstellung stattfinden, wieder in die ursprüngliche Quelldatenbank. Auf diese Weise halten Sie die ursprüngliche Quelle mit der neuen Zieldatenbank synchron und lassen die Schreibvorgänge in der neuen Zieldatenbankinstanz stattfinden. Der größte Nachteil ist, dass Sie den Replikationsstream erst testen können, nachdem Sie die Zieldatenbankinstanz erstellt haben. Daher sind keine End-to-End-Tests möglich und es gibt eine kurze Zeitspanne ohne Fallback.

Wählen Sie diesen Ansatz, wenn Sie Ihre Quellinstanz noch einige Zeit beibehalten und mithilfe der Migration mit kontinuierlicher Replikation migrieren können.

Vorwärtsreplikation

Diese Strategie ist eine Variante der Rückwärtsreplikation. Sie replizieren die Schreibvorgänge in Ihrer neuen Zieldatenbank auf eine dritte Datenbankinstanz Ihrer Wahl. Sie können Ihre Anwendungen auf diese dritte Datenbank verweisen, die eine Verbindung zum Server herstellt und schreibgeschützte Abfragen ausführt, wenn der Server nicht verfügbar ist. Sie können jeden Replikationsmechanismus je nach Bedarf verwenden. Der Vorteil dieses Ansatzes ist, dass er vollständig getestet werden kann.

Verwenden Sie diesen Ansatz, wenn immer ein Fallback verwendet werden soll oder wenn Sie Ihre anfängliche Quelldatenbank kurz nach der Produktionsumstellung verwerfen müssen.

Doppelte Schreibvorgänge

Wenn Sie eine Migrationsstrategie für den Mikrodienst „Y (Schreiben und Lesen)“ oder „Datenzugriff“ auswählen, ist dieser Fallback-Plan bereits festgelegt. Diese Strategie ist komplizierter, da Sie Anwendungen refaktorieren oder Tools entwickeln müssen, die eine Verbindung zu Ihren Datenbankinstanzen herstellen.

Ihre Anwendungen schreiben sowohl in die anfänglichen Quell- als auch in die Zieldatenbankinstanzen, sodass Sie eine schrittweise Umstellung der Produktion vornehmen können, bis Sie nur noch Ihre Zieldatenbankinstanzen verwenden. Falls Probleme auftreten, verbinden Sie Ihre Anwendungen ohne Ausfallzeiten wieder mit der ursprünglichen Quelle. Sie können die ursprüngliche Quelle und den doppelten Schreibmechanismus verwerfen, wenn Sie die Migration als problemlos durchgeführt betrachten.

Wir empfehlen diesen Ansatz, wenn es wichtig ist, keine Ausfallzeiten bei der Migration zu haben, ein zuverlässiges Fallback zu haben und wenn Sie Zeit und Ressourcen für die Refaktorierung der Anwendung haben.

Testen und Validieren

Das Ziel dieses Schritts ist es, Folgendes zu testen und zu validieren:

• Erfolgreiche Migration der Daten in der Datenbank.
• Einbindung in vorhandene Anwendungen nach der Umstellung auf die neue Zielinstanz.

Definieren Sie die wichtigsten Erfolgsfaktoren, die von Ihrer Migration abhängig sind. Dies sind Beispiele für subjektive Faktoren:

• Welche Daten migriert werden sollen Bei einigen Arbeitslasten ist es möglicherweise nicht erforderlich, alle Daten zu migrieren. Möglicherweise möchten Sie keine Daten migrieren, die bereits aggregiert, redundant, archiviert oder alt sind. Sie können diese Daten in einem Cloud Storage-Bucket als Sicherung archivieren.
• Ein akzeptabler Prozentsatz an Datenverlust. Dies gilt insbesondere für Daten, die für Analysearbeitslasten verwendet werden, bei denen der Verlust eines Teils der Daten keine Auswirkungen auf die allgemeinen Trends oder die Leistung Ihrer Arbeitslasten hat.
• Kriterien für Datenqualität und -quantität, die Sie auf Ihre Quellumgebung anwenden und nach der Migration mit der Zielumgebung vergleichen können.
• Leistungskriterien Einige Geschäftstransaktionen sind in der Zielumgebung möglicherweise langsamer, die Verarbeitungszeit liegt jedoch noch innerhalb der definierten Erwartungen.

Die Speicherkonfigurationen in Ihrer Quellumgebung lassen sich möglicherweise nicht direkt zu Google Cloud-Umgebungszielen zuordnen. Beispiel: Konfigurationen von den SSD-Volumes für allgemeine Zwecke (gp2 und gp3) mit IOPS-Burst-Leistung oder Bereitgestellte IOPS SSD. Führen Sie ein Benchmarking Ihrer Quelle durch, um die Zielinstanzen zu vergleichen und die richtige Größe zu bestimmen, sowohl in der Bewertungs- als auch in der Validierungsphase.

Beim Benchmarking wenden Sie produktionsähnliche Abfolgen von Vorgängen auf die Datenbankinstanzen an. In dieser Zeit erfassen und verarbeiten Sie Messwerte, um die relative Leistung von Quell- und Zielsystemen zu messen und zu vergleichen.

Verwenden Sie für herkömmliche, serverbasierte Konfigurationen relevante Messwerte, die bei Spitzenlasten beobachtet werden. Bei flexiblen Ressourcenkapazitätsmodellen wie Aurora Serverless sollten Sie sich die historischen Messwertdaten ansehen, um Ihre Skalierungsanforderungen zu berücksichtigen.

Die folgenden Tools können für Tests, Validierung und Datenbank-Benchmarking verwendet werden:

• HammerDB: Ein Open-Source-Datenbank-Benchmarking- und Lasttest-Tool. Es unterstützt komplexe Transaktions- und Analysearbeitslasten auf der Grundlage von Industriestandards auf mehreren Datenbank-Engines (sowohl TPROC-C als auch TPROC-H). HammerDB bietet eine detaillierte Dokumentation und eine breite Nutzer-Community. Sie haben die Möglichkeit, Ergebnisse über mehrere Datenbank-Engines und Speicherkonfigurationen hinweg freizugeben und zu vergleichen. Weitere Informationen finden Sie unter SQL Server-Lasttests mit HammerDB und Benchmarking der Amazon RDS SQL Server-Leistung mit HammerDB.
• DBT2-Benchmark-Tool: Benchmarking speziell für MySQL. Eine Reihe von Datenbank-Workload-Kits imitieren eine Anwendung für ein Unternehmen, das Lager besitzt und eine Mischung aus Lese- und Schreibtransaktionen umfasst. Verwenden Sie dieses Tool, wenn Sie einen vorgefertigten Lasttest für die Online-Transaktionsverarbeitung (OLTP) verwenden möchten.
• DbUnit: Ein Open-Source-Tool zum Testen von Einheiten, mit dem relationale Datenbankinteraktionen in Java getestet werden können. Die Einrichtung und Verwendung ist unkompliziert und unterstützt mehrere Datenbankmodule (z. B. MySQL, PostgreSQL und SQL Server) verwenden. Je nach Größe und Komplexität der Datenbank kann die Testausführung jedoch auch länger dauern. Wir empfehlen dieses Tool, wenn es möglichst einfach sein soll.
• DbFit: Ein Open-Source-Framework für Datenbanktests, das die testgesteuerte Codeentwicklung und automatisierte Tests unterstützt. Es verwendet eine einfache Syntax für die Erstellung von Testfällen und bietet datengesteuerte Tests, Versionskontrolle und Testergebnisberichte. Support für komplexe Abfragen und Transaktionen ist jedoch begrenzt und es gibt im Vergleich zu anderen Tools keine große Community-Support oder umfangreiche Dokumentation. Wir empfehlen dieses Tool, wenn Ihre Abfragen nicht komplex sind und Sie automatisierte Tests durchführen möchten und diese in die Continuous Integration- und Continuous Delivery-Prozesse integrieren wollen.

Führen Sie immer einen Probelauf für die Migration durch, um einen End-to-End-Test durchzuführen, einschließlich des Tests des Migrationsplans. Durch einen Probelauf wird die Datenbankmigration in vollem Umfang durchgeführt, ohne dass die Produktionsarbeitslasten gewechselt werden:

• Ermöglicht die ordnungsgemäße Migration aller Objekte und Konfigurationen.
• Hilft Ihnen, Ihre Migrationstestfälle zu definieren und auszuführen.
• Sie erhalten einen Einblick in die Zeit, die für die eigentliche Migration benötigt wird. Damit können Sie Ihre Zeitachse kalibrieren.
• Stellt einen Anlass zum Testen, Validieren und Anpassen des Migrationsplans dar. Manchmal kann man nicht alles im Voraus planen. Das hilft Ihnen, eventuelle Lücken zu erkennen.

Datentests können mit einem kleinen Teil der zu migrierenden Datenbanken oder mit dem gesamten Satz durchgeführt werden. Abhängig von der Gesamtzahl der Datenbanken und den zur Implementierung der Migration verwendeten Tools können Sie sich für einen risikobasierten Ansatz entscheiden. Mit diesem Ansatz führen Sie die Datenvalidierung für eine Teilmenge von Datenbanken durch, die mit demselben Tool migriert wurden, insbesondere wenn es sich um einen verwalteten Migrationsdienst handelt.

Für Tests sollten Sie Zugriff auf Quell- und Zieldatenbanken haben und die folgenden Aufgaben durchführen:

• Vergleichen Sie Quell- und Zielschemas. Prüfen Sie, ob alle Tabellen und ausführbaren Dateien vorhanden sind. Prüfen Sie die Zeilenanzahl und vergleichen Sie Daten auf Datenbankebene.
• Führen Sie Benutzerdefinierte Datenvalidierungsskripts aus.
• Testen Sie, ob die migrierten Daten auch in den Anwendungen sichtbar sind, die auf die Zieldatenbank umgestellt haben (migrierte Daten werden über die Anwendung gelesen).
• Führen Sie Integrationstests zwischen den umgestellten Anwendungen und der Zieldatenbank durch, indem Sie verschiedene Anwendungsfälle testen. Diese Tests umfassen sowohl das Lesen als auch das Schreiben von Daten in die Zieldatenbanken über die Anwendungen, damit die Arbeitslasten migrierte Daten zusammen mit neu erstellten Daten vollständig unterstützen.
• Testen Sie die Leistung der am häufigsten verwendeten Datenbankabfragen, um festzustellen, ob es aufgrund von Fehlkonfigurationen oder falscher Dimensionierung zu Beeinträchtigungen kommt.

Im Idealfall sind alle diese Migrationstestszenarien in jedem Quellsystem automatisiert und wiederholbar. Die Suite für automatisierte Testfälle ist so konzipiert, dass sie mit den gewechselten Anwendungen abzuschneiden.

Wenn Sie Database Migration Service als Migrationstool verwenden, finden Sie weitere Informationen unter Migration prüfen.

Datenvalidierungstool

Für die Datenvalidierung empfehlen wir die Verwendung des Datenvalidierungstools (DVT). DVT ist ein von Google unterstütztes Open-Source-Python-Befehlszeilentool, das eine automatisierte und wiederholbare Lösung für die Validierung über verschiedene Umgebungen hinweg bietet.

Das DVT kann den Datenvalidierungsprozess optimieren, indem es benutzerdefinierte, mehrstufige Validierungsfunktionen bietet, um Quell- und Zieltabellen auf der Tabellen-, Spalten- und Zeilenebene zu vergleichen. Sie können auch Validierungsregeln hinzufügen.

Das DVT deckt viele Google Cloud-Datenquellen ab, darunter AlloyDB für PostgreSQL, BigQuery, Cloud SQL, Spanner, JSON und CSV-Dateien auf Cloud Storage. Es kann auch in Cloud Functions und Cloud Run für eine ereignisbasierte Auslösung und Orchestrierung eingebunden werden.

Das DVT unterstützt die folgenden Arten von Validierungen:

• Vergleiche auf Schemaebene
• Spalte (einschließlich „AVG“, „COUNT“, „SUM“, „MIN“, „MAX“, „GROUP BY“ und „STRING_AGG“)
• Zeile (einschließlich Hash-Wert und genaue Übereinstimmung in Feldvergleichen)
• Vergleich der Ergebnisse benutzerdefinierter Abfrageergebnisse

Weitere Informationen zum DVT finden Sie im Git-Repository und unter Datenvalidierung mit dem Datenvalidierungstool von Google Cloud leicht gemacht.

Migration ausführen

Die Migrationsaufgaben umfassen die Aktivitäten, die die Übertragung von einem zu einem anderen System.

Beachten Sie die folgenden Best Practices für die Datenmigration:

• Informieren Sie die beteiligten Teams, wenn ein Planschritt beginnt und endet.
• Wenn einer der Schritte länger als erwartet dauert, vergleichen Sie die verstrichene Zeit mit der maximal für diesen Schritt zugewiesenen Zeit. Geben Sie in diesem Fall regelmäßige Zwischenaktualisierungen an die betroffenen Teams weiter.
• Wenn der Zeitraum größer ist als die maximale Zeit, die für jeden Schritt im Plan reserviert ist, sollten Sie ein Rollback durchführen.
• Treffen Sie für jeden Schritt des Migrations- und Umstellungsplans die Entscheidung „Go oder No-Go“.
• Erwägen Sie Rollback-Aktionen oder alternative Szenarien für jeden der Schritte.

Führen Sie die Migration gemäß Ihrer definierte Ausführungsaufgaben aus und erfahren Sie mehr in der Dokumentation des ausgewählten Migrationstools.

Produktionsumstellung ausführen

Der allgemeine Produktionsumstellungsprozess kann je nach ausgewählter Migrationsstrategie variieren. Wenn bei Ihren Arbeitslasten Ausfallzeiten auftreten können, beginnt die Migrationsumstellung damit, dass Schreibvorgänge in Ihre Quelldatenbank beendet werden.

Bei Migrationen von kontinuierlichen Replikationen führen Sie in der Regel die folgenden allgemeinen Schritte im Umstellungsprozess aus:

• Beenden Sie das Schreiben in die Quelldatenbank.
• Leeren Sie die Quelle.
• Beenden Sie den Replikationsprozess.
• Stellen Sie die Anwendungen bereit, die auf die neue Zieldatenbank verweisen.

Nachdem die Daten mit dem ausgewählten Migrationstool migriert wurden, prüfen Sie die Daten in der Zieldatenbank. Sie bestätigen, dass die Quelldatenbank und die Zieldatenbank synchronisiert sind und die Daten in der Zielinstanz den von Ihnen gewählten Erfolgsstandards für die Migration entsprechen.

Sobald die Datenvalidierung Ihre Kriterien erfüllt, können Sie die Umstellung auf Anwendungsebene durchführen. Stellen Sie die Arbeitslasten bereit, die für die Verwendung der neuen Zielinstanz refaktorisiert wurden. Sie stellen die Versionen Ihrer Anwendungen bereit, die auf die neue Zieldatenbankinstanz verweisen. Die Bereitstellungen können entweder über Rolling Updates, gestaffelte Releases oder durch ein Blau/Grün-Bereitstellungsmuster erfolgen. Es können einige Anwendungsausfallzeiten auftreten.

Befolgen Sie die Best Practices für Ihren Produktions-Umstellungsprozess:

• Überwachen Sie Ihre Anwendungen, die mit der Zieldatenbank arbeiten, nach der Umstellung.
• Legen Sie einen Überwachungszeitraum fest, um zu entscheiden, ob Sie den Fallback-Plan implementieren müssen.
• Beachten Sie, dass Ihre Cloud SQL- oder AlloyDB for PostgreSQL-Instanz möglicherweise neu gestartet werden muss, wenn Sie einige Datenbank-Flags ändern.
• Beachten Sie, dass der Aufwand für das Rollback der Migration größer sein kann, als Probleme in der Zielumgebung zu beheben.

Quellumgebung bereinigen und Cloud SQL-Instanz konfigurieren

Nach der Umstellung können Sie die Quelldatenbanken löschen. Wir empfehlen Ihnen, die folgenden wichtigen Aktionen vor der Bereinigung Ihrer Quellinstanz durchzuführen:

• Erstellen Sie eine abschließende Sicherung jeder Quelldatenbank. Diese Sicherungen bieten Ihnen einen Endzustand der Quelldatenbanken. Die Sicherungen können auch in einigen Fällen erforderlich sein, um bestimmte Datenvorschriften einzuhalten.

• Erfassen Sie die Datenbankparametereinstellungen der Quellinstanz. Oder überprüfen Sie, ob sie mit denen übereinstimmen, die Sie in der Phase der Inventarerstellung gesammelt haben. Passen Sie die Parameter der Zielinstanz an die Parameter der Quellinstanz an.

• Sammeln Sie die Datenbankstatistiken der Quellinstanz und vergleichen Sie sie mit denen der Zielinstanz. Wenn die Statistiken nicht übereinstimmen, ist es schwierig, die Leistung von Quell- und Zielinstanz zu vergleichen.

In einem Fallback-Szenario können Sie die Replikation der Schreibvorgänge auf der Cloud SQL-Instanz wieder in die ursprüngliche Quelldatenbank implementieren. Die Einrichtung ähnelt dem Migrationsprozess, würde jedoch in umgekehrter Richtung ausgeführt: Die ursprüngliche Quelldatenbank wird dann zum neuen Ziel.

Um die Quellinstanzen nach der Umstellung auf dem neuesten Stand zu halten, sollten Sie die Schreibvorgänge auf den Cloud SQL-Zielinstanzen zurück in die Quelldatenbank replizieren. Wenn Sie ein Rollback durchführen müssen, können Sie mit minimalem Datenverlust auf Ihre alten Quellinstanzen zurückgreifen.

Neben der Bereinigung der Quellumgebung müssen die folgenden wichtigen Konfigurationen für Ihre Cloud SQL-Instanzen vorgenommen werden:

• Konfigurieren Sie für die primäre Instanz ein Wartungsfenster, in dem betriebsunterbrechende Updates erfolgen können.
• Konfigurieren Sie den Speicher auf der Instanz so, dass mindestens 20 % Speicherplatz zur Verfügung stehen, um kritische Datenbankwartungsvorgänge, die Cloud SQL durchführen könnte, unterzubringen. Wenn Sie eine Warnung erhalten möchten, wenn der verfügbare Speicherplatz unter 20 % liegt, erstellen Sie eine messwertbasierte Benachrichtigungsrichtlinie für den Messwert zur Laufwerksauslastung.

Starten Sie keinen neuen Verwaltungsvorgang, bevor der letzte Vorgang abgeschlossen ist.

Hier finden Sie weitere Informationen:

• Informationen zur Wartung von Cloud SQL-Instanzen
• Spezifische Einstellungen für SQL Server-Engine.

Umgebung nach der Migration optimieren

Die Optimierung ist die letzte Phase Ihrer Migration. In dieser Phase iterieren Sie Optimierungsaufgaben, bis Ihre Umgebung Ihre Optimierungsanforderungen erfüllt. Die Iteration umfasst folgende Schritte:

1. Aktuelle Umgebung und Ihre Teams bewerten.
2. Optimierungsanforderungen und -ziele festlegen.
3. Umgebung und Teams optimieren.
4. Optimierungsprozess anpassen.

Wiederholen Sie diese Sequenz, bis Sie Ihre Optimierungsziele erreicht haben.

Weitere Informationen zum Optimieren Ihrer Google Cloud-Umgebung finden Sie unter Migration zu Google Cloud: Umgebung optimieren und Leistungsoptimierungsprozess.

Optimierungsanforderungen festlegen

Prüfen Sie die folgenden Optimierungsanforderungen für Ihre Google Cloud-Umgebung und wählen Sie die Anforderungen aus, die sich am besten für Ihre Arbeitslasten eignet.

Zuverlässigkeit und Verfügbarkeit Ihrer Datenbank erhöhen

Mit Cloud SQL können Sie eine Hochverfügbarkeits- und Notfallwiederherstellungsstrategie implementieren, die Ihrem Recovery Time Objective (RTO) und dem Recovery Point Objective (RPO) entspricht. Um die Zuverlässigkeit und Verfügbarkeit zu erhöhen, überlegen Sie Folgendes:

• Fügen Sie bei leselastigen Arbeitslasten Lesereplikate hinzu, um die primäre Instanz zu entlasten.
• Verwenden Sie für geschäftskritische Arbeitslasten die Hochverfügbarkeitskonfiguration, Replikate für den regionalen Failover und eine robuste Notfallwiederherstellungskonfiguration.
• Für weniger kritische Arbeitslasten können automatische und On-Demand-Sicherungen ausreichen.
• Um ein versehentliches Löschen von Instanzen zu verhindern, verwenden Sie den Instanzlöschschutz.
• Aktivieren Sie die Wiederherstellung zu einem bestimmten Zeitpunkt für Ihre Cloud SQL for SQL Server-Instanz.
• Automatisieren Sie SQL-Datenbanksicherungen mit Wartungsplänen.

Kosteneffizienz Ihrer Datenbankinfrastruktur erhöhen

Für positive wirtschaftliche Auswirkungen müssen Ihre Arbeitslasten die verfügbaren Ressourcen und Dienstleistungen effizient nutzen. Sie haben jetzt folgende Möglichkeiten:

• Stellen Sie der Datenbank die erforderliche Mindestspeicherkapazität bereit, indem Sie Folgendes tun:

  • Um die Speicherkapazität automatisch zu skalieren, wenn Ihre Daten wachsen, aktivieren Sie die automatische Speichererweiterungen. Sie sollten jedoch sicherstellen, dass Sie Ihre Instanzen so konfigurieren, dass sie bei Spitzenauslastungen über einen gewissen Puffer verfügen. Beachten Sie, dass Datenbankarbeitslasten im Laufe der Zeit tendenziell zunehmen.

• Identifizieren Sie möglicherweise überschätzte Ressourcen:

  • Durch die Größenanpassung Ihrer Cloud-SQL-Instanzen können Sie die Infrastrukturkosten senken, ohne zusätzliche Risiken für die Kapazitätsmanagementstrategie einzugehen.
  • Cloud Monitoring bietet vordefinierte Dashboards, mit denen Sie die System- und Kapazitätsnutzung vieler Google Cloud-Komponenten ermitteln können, einschließlich Cloud SQL. Weitere Informationen finden Sie unter Benutzerdefinierte Dashboards erstellen und verwalten

• Ermitteln Sie Instanzen, die keine Hochverfügbarkeits- oder Notfallwiederherstellungskonfigurationen erfordern, und entfernen Sie sie aus Ihrer Infrastruktur.

• Entfernen Sie nicht mehr benötigte Tabellen und Objekte. Sie können sie in einem vollständigen Sicherungs- oder Archivierungs-Cloud Storage-Bucket speichern.

• Bestimmen Sie den kostengünstigsten Speichertyp (SSD oder HDD) für Ihren Anwendungsfall.

  • In den meisten Anwendungsfällen ist SSD die effizienteste und kostengünstigste Wahl.
  • Wenn Ihre Datasets groß (mindestens 10 TB), latenzunempfindlich sind oder nur selten darauf zugegriffen wird, ist eine HDD möglicherweise besser geeignet.
  • Weitere Informationen finden Sie unter Zwischen SSD- und HDD-Speicher wählen.

• Kaufen Sie für Arbeitslasten mit vorhersehbarem Ressourcenbedarf Rabatte für zugesicherte Nutzung.

• Verwenden Sie Active Assist, um Kosteninformationen und Empfehlungen zu erhalten.

Weitere Informationen und Optionen finden Sie unter Mit Active Assist mehr erreichen: Empfehlungen zur Kostenoptimierung in Cloud SQL mit Active Assist.

Um die Lizenzkosten insbesondere für Cloud SQL for SQL Server zu senken, sollten Sie Folgendes prüfen:

• Migrieren Sie zu SQL Server Standard Edition, wenn die SLAs Ihren Anforderungen entsprechen.
• Deaktivieren Sie das gleichzeitige Multithreading (SMT) und fügen Sie 25 % mehr Kerne hinzu. Die zusätzlichen Kerne können die Leistungseinbußen durch das Deaktivieren von SMT kompensieren. Diese Strategie kann die Lizenzkosten reduzieren, aber sie kann sich auf die Leistung Ihrer Instanz auswirken. Wir empfehlen Ihnen, Lasttests mit Ihrer Instanz durchzuführen, um sicherzustellen, dass Ihre SLAs nicht betroffen sind.
• Ziehen Sie je nach Arbeitslast eine heterogene Migration von Cloud SQL for SQL Server zu Cloud SQL for PostgreSQL oder AlloyDB for PostgreSQL in Betracht.

Leistung der Datenbankinfrastruktur erhöhen

Kleinere datenbankbezogene Leistungsprobleme können sich häufig auf den gesamten Vorgang auswirken. Beachten Sie die folgenden Richtlinien, um die Leistung Ihrer Cloud SQL-Instanz zu erhalten und zu erhöhen:

• Eine große Anzahl von Datenbanktabellen kann sich auf die Leistung und Verfügbarkeit der Instanz auswirken und dazu führen, dass die Instanz nicht mehr vom SLA abgedeckt ist.

• Achten Sie darauf, dass der Arbeitsspeicher oder die CPU für die Instanz nicht beschränkt ist.

  • Für leistungsintensive Arbeitslasten sollten Sie sicherstellen, dass Ihre Instanz über mindestens 60 GB Speicher verfügt.
  • Wenn das Einfügen, Aktualisieren und Löschen von Datenbankeinträgen langsam ist, prüfen Sie den Ausgangsort des Schreibbefehls in Bezug auf den Standort der Datenbank. Werden Daten über weite Strecken übertragen, führt dies zu längeren Latenzzeiten.

• Verbessern Sie die Abfrageleistung mithilfe des vordefinierten Query Insights-Dashboards in Cloud Monitoring (oder ähnlicher integrierte Features des Datenbankmoduls). Ermitteln Sie die teuersten Befehle und versuchen Sie, sie zu optimieren.

• Verhindern, dass Datenbankdateien unnötig groß werden. Legen Sie autogrow in MB und nicht als Prozentsatz fest, indem Sie die Schritte verwenden, die für die Anforderung geeignet sind.

• Prüfen Sie den Leser- und Datenbankstandort. Latenz wirkt sich auf die Leseleistung mehr aus als auf die Schreibleistung.

• Daten- und Indexfragmentierung verhindern. Legen Sie einen Zeitplan zur Neuerstellung Ihrer Indexe in SQL Server fest, je nachdem, wie oft sich Ihre Daten ändern.

• Ändern Sie die Spezifischen Einstellungen für die SQL Server-Engine, damit sie optimal für Cloud SQL funktionieren.

• Informationen zur Wartung von Index und Statistiken finden Sie unter SQL Server-Wartungslösung.

• Aktualisieren Sie Statistiken regelmäßig zu Cloud SQL for SQL Server.

• ETL-Vorgänge sollten Sie auf einem Lesereplikat ausführen, da diese sich auf den Cache Ihrer Instanz auswirken können.

Weitere Informationen zur Erhöhung der Leistung finden Sie unter Leistung in „Probleme diagnostizieren“ und Cloud SQL – SQL Server-Leistungsanalyse und Abfrageoptimierung.

Beobachtbarkeit von Datenbanken optimieren

Die Diagnose und Behebung von Problemen in Anwendungen, die sich mit Datenbankinstanzen verbinden, kann schwierig und zeitaufwendig sein. Aus diesem Grund ist es unerlässlich, einen zentralen Ort zu haben, an dem alle Teammitglieder sehen können, was auf Datenbank- und Instanzebene passiert. Sie können Cloud SQL-Instanzen auf folgende Arten überwachen:

• Cloud SQL verwendet integrierte, benutzerdefinierte Arbeitsspeicheragenten, um Abfragetelemetriedaten zu sammeln.

  • Verwenden Sie Cloud Monitoring, um Messungen Ihres Dienstes und der Google Cloud-Ressourcen, die Sie nutzen, zu sammeln.
  • Sie können benutzerdefinierte Dashboards erstellen, um Messwerte zu überwachen und Benachrichtigungsrichtlinien einrichten, damit Sie rechtzeitig Benachrichtigungen erhalten.

• Cloud Logging erfasst Logging-Daten von gängigen Anwendungskomponenten. Sie können auch Logs für Ihre Cloud SQL-Instanz ansehen und abfragen.

• Cloud Trace erfasst Latenzdaten und ausgeführte Abfragepläne aus Anwendungen, damit Sie verfolgen können, wie Anfragen Ihre Anwendung durchlaufen.

• Datenbankcenter bietet eine KI-gestützte, zentralisierte Datenbankflotte. Sie können den Zustand Ihrer Datenbanken, die Verfügbarkeitskonfiguration, den Datenschutz, die Sicherheit und die Branchencompliance überwachen.

Allgemeine Best Practices und Betriebsrichtlinien für Cloud SQL

Wenden Sie die Best Practices für Cloud SQL an, um die Datenbank zu konfigurieren und zu optimieren.

Wichtige allgemeine Empfehlungen für Cloud SQL:

• Wenn Sie große Instanzen haben, empfehlen wir, diese nach Möglichkeit in kleinere Instanzen aufzuteilen.
• Konfigurieren Sie den Speicher für eine kritische Datenbankwartung. Achten Sie darauf, dass mindestens 20 % Speicherplatz für alle kritischen Datenbankwartungsvorgänge zur Verfügung stehen, die von Cloud SQL ausgeführt werden.
• Zu viele Datenbanktabellen können sich auf die Zeit für das Datenbankupgrade auswirken. Idealerweise sollten weniger als 10.000 Tabellen pro Instanz vorhanden sein.
• Wählen Sie die geeignete Größe für Ihre Instanzen aus, um die Aufbewahrung von (binären) Transaktionslogs zu berücksichtigen, insbesondere für Instanzen mit hoher Schreibaktivität.

Verwenden Sie die folgenden Richtlinien, um alle auftretenden Leistungsprobleme von Datenbanken effizient verarbeiten zu können, bis das Problem behoben ist:

Infrastruktur hochskalieren: Erhöhen Sie die Ressourcen (z. B. Laufwerkdurchsatz, vCPU, und RAM). Je nach Dringlichkeit und Verfügbarkeit und Erfahrung Ihres Teams können Sie die meisten Leistungsprobleme beheben, indem Sie die Instanz vertikal skalieren. Später können Sie die Ursache des Problems in einer Testumgebung weiter untersuchen und Optionen zur Beseitigung des Problems prüfen.

Datenbankwartungsvorgänge ausführen und planen: Indexdefragmentierung, Aktualisierungen von Statistiken, Vakuumanalyse und Neuindexierung stark aktualisierter Tabellen. Prüfen Sie, ob und wann diese Wartungsvorgänge zuletzt ausgeführt wurden, insbesondere für die betroffenen Objekte (Tabellen, Indexe). Finden Sie heraus, ob sich die normalen Datenbankaktivitäten geändert haben. Dies kann beispielsweise der Fall sein, wenn Sie kürzlich eine neue Spalte hinzugefügt haben oder viele Aktualisierungen für eine Tabelle haben.

Datenbankoptimierung und -optimierung durchführen: Sind die Tabellen in Ihrer Datenbank ordnungsgemäß strukturiert? Enthalten die Spalten die richtigen Datentypen? Ist Ihr Datenmodell für die Art der Arbeitslast das Richtige? Prüfen Sie Ihre langsamen Abfragen und deren Ausführungspläne. Verwenden sie die verfügbaren Indexe? Prüfen Sie, ob Indexscans, Sperren und Warten auf andere Ressourcen durchgeführt wurden. Fügen Sie gegebenenfalls Indexe hinzu, um Ihre kritischen Abfragen zu unterstützen. Entfernen Sie nicht kritische Indexe und Fremdschlüssel. Erwägen Sie, komplexe Abfragen und Joins neu zu schreiben. Die Dauer der Lösung des Problems hängt von der Erfahrung und der Verfügbarkeit Ihres Teams ab und kann zwischen Stunden und Tagen dauern.

Lesevorgänge skalieren: Nutzen Sie Lesereplikate. Wenn die vertikale Skalierung für Ihre Anforderungen nicht ausreicht und die Maßnahmen zur Feinabstimmung und Optimierung der Datenbank nicht hilfreich sind, sollten Sie eine horizontale Skalierung in Betracht ziehen. Die Weiterleitung von Leseabfragen aus Ihren Anwendungen an ein Lesereplikat verbessert die Gesamtleistung Ihrer Datenbanklast. Es ist jedoch möglicherweise mit zusätzlichem Aufwand verbunden, Ihre Anwendungen zu ändern, damit sie eine Verbindung zum Lesereplikat herstellen.

Umstrukturierung der Datenbank: Erwägen Sie die Partitionierung und Indexierung der Datenbank. Dieser Vorgang erfordert wesentlich mehr Aufwand als die Datenbankabstimmung und -optimierung und kann eine Datenmigration erfordern, aber er kann eine langfristige Lösung sein. Manchmal kann ein schlechtes Design des Datenmodells zu Leistungsproblemen führen, die dies teilweise durch vertikale Skalierung kompensieren können. Ein richtiges Datenmodell ist jedoch eine langfristige Lösung. Ziehen Sie eine Partitionierung Ihrer Tabellen in Betracht. Archivieren Sie nicht benötigte Daten, wenn möglich. Normalisieren Sie die Datenbankstruktur. Beachten Sie jedoch, dass die Denormalisierung auch die Leistung verbessern kann.

Datenbankfragmentierung: Sie können Ihre Schreibvorgänge horizontal skalieren, indem Sie Ihre Datenbank fragmentieren. Die Fragmentierung ist ein komplizierter Vorgang. Bei der Fragmentierung müssen Sie Ihre Datenbank und Anwendungen auf eine bestimmte Weise neu strukturieren sowie Datenmigrationen durchführen. Sie teilen Ihre Datenbankinstanz mithilfe bestimmter Partitionierungskriterien in mehrere kleinere Instanzen auf. Die Kriterien können auf Kunde oder Thema basieren. Mit dieser Option können Sie Schreib- und Lesevorgänge horizontal skalieren. Dadurch wird jedoch die Komplexität Ihrer Datenbank- und Anwendungsarbeitslasten erhöht. Es kann auch zu unausgeglichenen Shards führen, die als Hotspots bezeichnet werden und den Vorteil der Fragmentierung aufwiegen.

Beachten Sie insbesondere für Cloud SQL for SQL Server die folgenden Best Practices:

• Zum Aktualisieren der SQL Server-Einstellungen für optimale Leistung mit Cloud SQL, siehe SQL Server-Einstellungen
• Bestimmen Sie die Kapazität des E/A-Subsystems, bevor Sie SQL Server bereitstellen.

• Wenn Sie große Instanzen haben, teilen Sie sie nach Möglichkeit in kleinere Instanzen auf:

  • Eine Laufwerkgröße von 4 TB oder mehr bietet mehr Durchsatz und IOPS.
  • Eine höhere vCPU bietet mehr IOPS und Durchsatz. Überwachen Sie bei Verwendung einer höheren vCPU die Datenbankwartezeit auf Parallelität, was auch zunehmen kann.

• Deaktivieren Sie SMT, wenn die Leistung in einigen Situationen vermindert ist. Zum Beispiel, wenn eine Anwendung Threads ausführt, die zu einem Engpass werden und die Architektur der CPU dies nicht effektiv verarbeitet.

• Legen Sie einen Zeitplan für die Reorganisierung oder Neuerstellung Ihrer Indexe fest, je nachdem, wie häufig Sie Daten ändern.

• Legen Sie einen geeigneten Füllfaktor fest, um die Fragmentierung zu reduzieren. Überwachen Sie SQL Server auf fehlende Indexe, die möglicherweise eine bessere Leistung bieten.

• Verhindern, dass Datenbankdateien unnötig groß werden. Legen Sie autogrow in MB und nicht als Prozentsatz fest, indem Sie die Schritte verwenden, die für die Anforderung geeignet sind. Verwalten Sie außerdem das Datenbankwachstum proaktiv, bevor der Schwellenwert autogrow erreicht wird.

• Wenn Sie die Speicherkapazität automatisch skalieren möchten, aktivieren Sie automatische Speichererweiterungen. Cloud SQL kann Speicherplatz hinzufügen, wenn der Speicherplatz der Datenbank und der Instanz aufgebraucht ist.

• Stellen Sie sicher, dass Sie die Sprachanforderungen, die Sortierreihenfolge sowie die Berücksichtigung der Groß- und Kleinschreibung sowie der Akzente der Daten, mit denen Sie arbeiten, verstehen. Wenn Sie eine Sortierung für Ihren Server, Ihre Datenbank, Ihre Spalte oder Ihren Ausdruck auswählen, weisen Sie Ihren Daten bestimmte Merkmale zu.

• Rekursive Hash-Joins oder Hash-Bailouts führen zu einer geringeren Leistung auf einem Server. Wenn in einem Trace viele Hash-Warnungsereignisse angezeigt werden, aktualisieren Sie die Statistiken zu den zu verknüpfenden Spalten. Weitere Informationen finden Sie unter Hash-Warnungsereignisklasse.

Weitere Informationen finden Sie unter Allgemeine Best Practices und Betriebsrichtlinien für Cloud SQL for SQL Server.

Nächste Schritte

• Von Amazon EC2 zu Compute Engine migrieren
• Von Amazon S3 zu Cloud Storage migrieren
• Informationen zu anderen Migrationspfaden von AWS zu Google Cloud
• AWS- und Azure-Dienste mit Google Cloud vergleichen
• Hilfe für Migrationen erhalten
• Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.

Beitragende

Autoren:

• Alex Cârciu | Solutions Architect
• Marco Ferrari | Cloud Solutions Architect

Weitere Beitragende:

• Derek Downey | Developer Relations Engineer
• Paweł Krentowski | Technical Writer
• Matthew Smith | Strategic Cloud Engineer
• Somdyuti Paul | Data Management Specialist
• Zach Seils | Networking Specialist

Wenn Sie nicht öffentliche LinkedIn-Profile sehen möchten, melden Sie sich bei LinkedIn an.