Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Phase 1: Vorbereiten
Die erste Phase des Datenbankmigrationsprozesses ist die Vorbereitung. Während der Vorbereitung identifizieren Sie die Interdependenzen zwischen Ihren Anwendungen und Datenbanken. Sie analysieren auch die Datenbank-Workloads, um die Migrationskategorien zu bestimmen: von der einfachen Rehost-Migration (homogen) bis hin zur Re-Architect-Migration (heterogen). Ohne Abschluss dieser Phase besteht die Gefahr, dass Sie auf verzögerte Migrationszeitpläne stoßen.
Diese Aufgaben werden in den folgenden Abschnitten behandelt:
+ [Identifizieren von Abhängigkeiten](id-dependencies.md)
+ [Qualifizierung von Workloads](qualify-workloads.md)
# Identifizieren Sie Abhängigkeiten
Sie beginnen mit der Identifizierung von Anwendungs- und Datenbankabhängigkeiten, indem Sie Fragen wie die folgenden stellen:
+ Wird von einer anderen Anwendung direkt auf diese Datenbank zugegriffen?
Falls ja, sollten Sie herausfinden, wie sich die Migration der Datenbank auf diese Anwendung auswirkt. Wenn Sie die Datenbank erneut hosten, müssen Sie sicherstellen, dass die Anwendung weiterhin mit akzeptabler Leistung auf die Datenbank zugreifen kann.
+ Greift die Anwendung direkt auf eine andere Datenbank zu?
Falls ja, legen Sie den Migrationsplan für die andere Datenbank fest. Wenn sie ebenfalls migriert wird, müssen Sie die Anwendung entsprechend aktualisieren. Wenn es nicht migriert wird, müssen Sie sicherstellen, dass die Anwendung weiterhin mit akzeptabler Latenz eine Verbindung zu ihr herstellen kann.
+ Verwendet die Datenbank Datenbanklinks, um Daten aus anderen Datenbanken abzurufen?
Legen Sie wie im vorherigen Punkt den Migrationsplan für die andere Datenbank fest und behandeln Sie die Links entsprechend.
+ Ist die Anwendung von lokaler Software abhängig?
Wenn ja, sollten Sie den Migrationsplan für diese Software festlegen. Wenn es sich um eine Migration handelt, müssen Sie Ihre Anwendung entsprechend aktualisieren. Ist dies nicht der Fall, stellen Sie sicher, dass die Anwendung weiterhin eine Verbindung zur Software herstellen kann und die Latenz akzeptabel ist.
+ Gibt es irgendwelche Hardwareabhängigkeiten?
Wenn ja, überlegen Sie sich einen Plan, um diese zu beheben.
+ Gibt es strenge Bandbreiten- oder Netzwerkanforderungen?
Wenn ja, wählen Sie die AWS Dienste aus, die Ihnen helfen können, diese Anforderungen zu erfüllen.
+ Verwendet die Anwendung spezielle Datenbank-Engine-Optionen oder -Funktionen?
Wenn Sie zu einer anderen Datenbank-Engine migrieren, müssen Sie die Anwendung entsprechend aktualisieren.
Wenn die Antworten auf diese Fragen komplex sind, ist es besser, die Datenbank mithilfe von Microservices von der Anwendung zu entkoppeln. Auf diese Weise kann eine Anwendung Daten abrufen, indem sie den Microservice aufruft, anstatt sich direkt mit der Datenbank zu verbinden.
# Qualifizieren Sie Workloads
Um die beste Migrationsstrategie für Ihre Datenbank zu ermitteln, ist es wichtig, die aktuelle Datenbank-Arbeitslast zu verstehen. Sie müssen Ihre Datenbank analysieren, um festzustellen, welche Funktionen Sie derzeit verwenden und was mit der Migration zu einer anderen Cloud-nativen Datenbank-Engine wie [Amazon Aurora](https://aws.amazon.com/rds/aurora/) PostgreSQL verbunden ist.
AWS bietet ein Tool zur Workload-Qualifizierung namens Workload Qualification Framework ( AWS WQF).AWS Mit diesem Tool können Sie die Komplexität Ihrer Oracle- und Microsoft SQL Server-Datenbankmigration ermitteln, indem es Datenbankschemas und Codeobjekte, Anwendungscode, Abhängigkeiten, Leistungsmerkmale und ähnliche Eingaben analysiert. WQF bietet Empfehlungen zur Zieldatenbank-Engine. Außerdem werden die Art der verbundenen Arbeitsschritte und der erforderliche Aufwand geschätzt.
WQF bewertet Ihren Migrations-Workload und ordnet ihn in eine von fünf Workload-Kategorien ein, die in der folgenden Tabelle zusammengefasst sind.
![\[Five migration workload categories reported by WQF\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/strategy-database-migration/images/wqf-categories.png)
+ **Kategorie 1:** Workloads, die Open Database Connectivity (ODBC) oder Java Database Connectivity (JDBC) anstelle von proprietären Treibern verwenden, um eine Verbindung zur Datenbank herzustellen. Diese Kategorie umfasst in der Regel einfache gespeicherte Prozeduren, die für Zugriffskontrollen verwendet werden. Die Konvertierung erfordert weniger als 50 manuelle Änderungen.
+ **Kategorie 2:** Workloads, bei denen nur wenig proprietäre Funktionen genutzt werden und die keine erweiterten SQL-Sprachfunktionen verwenden. Für diese Art von Workload sind weniger als 200 manuelle Änderungen erforderlich.
+ **Kategorie 3:** Workloads, bei denen häufig proprietäre Funktionen genutzt werden. Workloads in dieser Kategorie werden vollständig durch erweiterte gespeicherte Prozedurlogik oder proprietäre Funktionen gesteuert. Diese Art von Arbeitslast erfordert mehr als 200 manuelle Änderungen, die datenbankeigenen Code und Funktionen beinhalten.
+ **Kategorie 4:** Engine-spezifische Workloads. Workloads in dieser Kategorie verwenden Frameworks, die nur mit einer bestimmten kommerziellen Datenbank-Engine funktionieren. Zu diesen Frameworks können beispielsweise Oracle Forms, Oracle Reports, Oracle Application Development Framework (ADF), Oracle Application Express (APEX) oder Anwendungen gehören, die .NET ausgiebig verwenden. ActiveRecord
+ **Kategorie 5:** Nicht übertragbare Workloads, inakzeptable Risiken oder „Lift-and-Shift“ -Workloads. Workloads in dieser Kategorie können in Datenbank-Engines implementiert werden, die über kein Cloud-basiertes Äquivalent verfügen. In einigen Fällen verfügen Sie möglicherweise nicht über den Quellcode für diese Programme.
Diese Kategorisierung kann Ihnen dabei helfen, den Migrationspfad für Ihre Anwendung zu bestimmen, worauf wir im Abschnitt [Phase 2: Planung](planning-phase.md) eingehen werden.
AWS stellt derzeit kein AWS WQF zum Herunterladen bereit. Wenn Sie Hilfe bei der Bewertung einer Migration zu AWS AWS WQF benötigen, empfehlen wir Ihnen, ein Support-Ticket zu eröffnen. AWS wird sich direkt mit Ihnen in Verbindung setzen, damit der Prozess für Sie funktioniert.