Fehlerbehebung
Im Migrationsjobprozess können während der Laufzeit Fehler auftreten.
- Bei einigen Fehlern wiederholt Database Migration Service die fehlerhaften Vorgänge automatisch, um den Migrationsprozess fortzusetzen und Unterbrechungen zu vermeiden. Der Status des Migrationsjobs ändert sich zu Wird mit Fehlern ausgeführt. Dieser Status gibt an, dass Database Migration Service weiterhin Daten migriert, die nicht von den Fehlern betroffen sind.
- Einige Fehler lassen sich nicht beheben. Wenn in Database Migration Service ein nicht behebbarer Fehler auftritt, ändert sich der Status des Migrationsjobs in Fehler. In solchen Fällen muss der Migrationsjob neu gestartet werden, nachdem das Problem behoben wurde.
Rufen Sie zur Fehlerbehebung den betroffenen Migrationsjob auf, sehen Sie sich den Fehler an und folgen Sie der Anleitung in der Fehlermeldung. Weitere Informationen finden Sie in den Cloud Monitoring-Logs für Ihre Cloud SQL-Zielinstanz. Verwenden Sie den Cloud Monitoring-Link auf der Detailseite des Migrationsjobs.
In der folgenden Tabelle finden Sie einige Beispiele für Probleme und wie sie behoben werden können:
| Problem | Mögliche Ursache | Lösungsvorschlag |
|---|---|---|
Fehlermeldung: The BAK file's database major version number
{backup_version_num} must not be higher than the current database
major version number {your Cloud SQL for SQL Server version number}. |
Sie versuchen, Sicherungsdateien aus einer neueren SQL Server-Version als der Version zu importieren, die Sie in Ihrer Cloud SQL for SQL Server-Zielinstanz verwenden.
Der Database Migration Service unterstützt versionsübergreifende Migrationen von niedrigeren zu späteren Versionen nur, wenn Sie die Richtlinien zur versionsübergreifenden Kompatibilität einhalten. Weitere Informationen finden Sie unter Unterstützte Quell- und Zieldatenbanken. |
Erstellen Sie die Cloud SQL for SQL Server-Zielinstanz neu, um eine neuere SQL Server-Version zu verwenden, und wiederholen Sie den Migrationsprozess mit der neuen Instanz. |
Fehlermeldung:
The following database already exists in destination: {database_name}.
|
Ihre Cloud SQL-Zielinstanz enthält bereits eine Datenbank, die denselben Namen wie eine der Datenbanken in Ihrem Migrationsjob verwendet. | Entfernen Sie den Namenskonflikt. Weitere Informationen finden Sie unter Fehler: Datenbank ist bereits im Ziel vorhanden . |
Fehlermeldung:
Permission denied for {cloudsql.databases.get} on the Database Migration Service service account. |
Dem Dienstkonto von Database Migration Service fehlen Berechtigungen. | Fügen Sie dem Dienstkonto des Database Migration Service die fehlenden Berechtigungen hinzu. Weitere Informationen finden Sie unter Zugriffssteuerung mit IAM. |
Fehlermeldung:
Missing WAL file at Log Sequence Number (LSN) {log_number_here} |
Ihre Dateien mit Transaktionslogs enthalten möglicherweise falsche Epoch-Zeitstempel in Bezug auf die Reihenfolge der darin enthaltenen Updates. Database Migration Service verwendet Logfolgenummern und Epochen-Zeitstempel, um die Reihenfolge zu steuern, in der Transaktionslogdateien in die Cloud SQL-Zielinstanz repliziert werden. | Prüfen und passen Sie die in den Dateinamen Ihrer neuesten Transaktionslogdateien verwendeten Epoch-Zeitstempel an. Siehe Fehlerhafte Namen von Transaktionslogs anpassen. |
| Wenn Sie ausgewählte Datenbanken migrieren und Daten nicht in eine oder mehrere Datenbanken repliziert werden können, wird in der Liste der Datenbanken der Status Fehler angezeigt. | Verschiedene Fehler bei Migrationsjobs. | Klicken Sie in der Spalte Fehler auf Fehler ansehen und beheben Sie die Fehler. Klicken Sie nach dem Beheben der Fehler auf Neu starten. |
Fehler: Datenbank ist bereits im Ziel vorhanden
Die folgende Fehlermeldung wird angezeigt:
The following database already exists in destination: {database_name}.
Mögliche Ursache
Ihre Cloud SQL-Zielinstanz enthält bereits eine Datenbank, die denselben Namen wie eine der Datenbanken in Ihrem Migrationsjob verwendet.
Lösungsvorschlag
Je nach Migrationsszenario gibt es verschiedene Möglichkeiten, das Problem doppelter Datenbanken zu beheben. Führen Sie eine der folgenden Aktionen aus:
Benennen Sie den Cloud Storage-Quell-Bucket um, um Ihre Datenbank mit einem anderen Namen zu migrieren.
Der Name der Datenbank, die Database Migration Service in Ihrer Ziel-Cloud SQL-Instanz erstellt, wird aus den Ordnernamen in Cloud Storage abgeleitet, in denen Sie die Sicherungsdateien speichern. Wenn Sie zwei verschiedene Datenbanken haben, die denselben Namen haben und die Sie beide in Ihrem Cloud SQL-Ziel benötigen, können Sie die Ordner umbenennen und den Migrationsjob neu erstellen, um den Namenskonflikt zu vermeiden.
Führen Sie diese Schritte aus:
- Erstellen Sie neue Ordner für die Quelldatenbank, die vom Namenskonflikt betroffen ist. Weitere Informationen finden Sie unter Sicherungsdateien in einem Cloud Storage-Bucket speichern .
- Erstellen Sie den Migrationsjob neu. Weitere Informationen finden Sie unter
Migrationsjob erstellen.
Sie können einem vorhandenen Migrationsjob neue Datenbanken hinzufügen, aber keine Datenbanken daraus entfernen. Daher müssen Sie den gesamten Migrationsjob neu erstellen.
Löschen Sie die doppelte Datenbank aus Ihrer Cloud SQL for SQL Server-Instanz.
Wenn die Datenbank in Ihrer Cloud SQL-Zielinstanz ein Duplikat ist, können Sie sie aus Ihrer Instanz löschen und mit dem Migrationsjob fortfahren. Weitere Informationen finden Sie in der Dokumentation zu Cloud SQL for SQL Server unter Datenbank löschen.
Dateinamen von Transaktionslogs für WAL-Dateien anpassen, die nicht in der richtigen Reihenfolge sind
Mögliche Ursache
Ihre Dateien mit Transaktionslogs enthalten möglicherweise falsche Epoch-Zeitstempel in Bezug auf die Reihenfolge der darin enthaltenen Updates. Database Migration Service verwendet Logfolgenummern und Epochen-Zeitstempel, um die Reihenfolge zu steuern, in der Transaktionslogdateien in die Cloud SQL-Zielinstanz repliziert werden.
Lösungsvorschlag
Der Upload Ihrer Dateien kann sich verzögern oder die Dateien werden in der falschen Reihenfolge hochgeladen. Warten Sie einige Minuten, bis das Problem behoben ist, oder prüfen Sie, ob in Ihrem Cloud Storage-Bucket Dateien fehlen.
Wenn das Problem dadurch nicht behoben wird, überprüfen und korrigieren Sie die Epoch-Zeitstempel in den Dateinamen Ihrer Transaktionsprotokolle.
Führen Sie diese Schritte aus:
- Prüfen Sie die Liste der Importvorgänge für Transaktionslogs in der Cloud SQL for SQL Server-Zielinstanz. Wechseln Sie in der Google Cloud Console zur Seite Cloud SQL-Instanzen.
- Klicken Sie auf Alle Vorgänge ansehen> SQL Server-Fehlerlogs ansehen.
- Sehen Sie sich alle Importvorgänge für Transaktionslogdateien an und prüfen Sie, ob die Dateinamen korrekte Epoch-Zeitstempel enthalten.
- Wenn Sie feststellen, dass in den Namen der aktuellen Transaktionslogdateien Epoch-Zeitstempel in falscher Reihenfolge verwendet werden, rufen Sie Ihren Cloud Storage-Bucket auf und benennen Sie die Datei um. Der Database Migration Service erkennt die Änderung automatisch und versucht, die relevanten Transaktionsprotokolldateien zu importieren.
- Nur Amazon RDS: Möglicherweise wurden einige Transaktionslogdateien beim Export nach S3 nicht berücksichtigt. Führen Sie die Exportfunktion für Transaktionsprotokolle für den Zeitraum um die fehlenden WAL-Dateien noch einmal aus.