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 3: Migrieren

Eine Hauptaufgabe von Datenbankmigrationen besteht darin, die Migration mit minimalen Ausfallzeiten abzuschließen. Da beide Datenbanken dieselbe Programmiersprache und dieselben Kommunikationsprotokolle verwenden sollten, müssen Sie möglicherweise den Code und das Schema für ähnliche Abfragesyntaxen, -prozeduren und -funktionen konvertieren. Beachten Sie bei der Konvertierung eines Schemas die folgenden Aspekte:

Sie können jedes Migrationstool eines Drittanbieters für die Schemacode-Konvertierung verwenden, z. B. die SAP ASE-Datenbank und Amazon RDS for SQL Server. Möglicherweise müssen Sie einen Teil des Codes manuell konvertieren, da Nicht-ANSI-SQL in SQL Server nicht unterstützt wird.

Nachdem Sie den Code konvertiert haben, konvertieren Sie Ihren Anwendungscode oder Ihre dynamische SQL-Anwendung und führen Sie dann Einheiten- und Funktionstests durch. Weitere Informationen finden Sie unter Testen von migrierten Datenbankobjekten (SybaseToSQL).

Die Daten werden konvertiert

Transformieren Sie Rohdaten, um sie nützlicher zu machen, indem Sie sie bereinigen, standardisieren, verifizieren und sortieren. Bei Datenbankmigrationen werden ETL-Prozesse (Extrahieren, Transformieren und Laden) auf folgende Weise verwendet:

Beispiele für ETL-Tools sind AWS Glue Informatica und Talend. Bei Migrationen von SAP ASE zu SQL Server können einige kostenlose Tools gespeicherte Prozeduren und Funktionen automatisch konvertieren.

Datenbankobjekte validieren

Die Validierung Ihrer Datenbank trägt dazu bei, Probleme in nachfolgenden Migrationsphasen zu vermeiden. Überprüfen Sie nach der Codekonvertierung Ihr Datenbankschema, indem Sie die folgenden Elemente zwischen SAP ASE und RDS SQL Server vergleichen:

Überprüfen Sie, ob jedes Objekt korrekt migriert wurde. Wenn Sie Unterschiede feststellen, ermitteln Sie den Grund für den Fehler. Möglicherweise müssen Sie fehlende Objekte in der Zieldatenbank manuell erstellen oder Transact-SQL-Code konvertieren. Weitere Informationen finden Sie unter Validieren von Datenbankobjekten nach der Migration von SAP ASE zu Amazon RDS for SQL Server oder Microsoft SQL Server.

Daten migrieren mit AWS DMS

Wenn Sie mehrere Datenbankbenutzer haben, muss Ihre Anwendung möglicherweise gemäß einem Zeitplan migriert werden. Abhängig von der Datenbankgröße und dem Migrationsfenster erfordern solche Datenmigrationen Kenntnisse über Volllasten und inkrementelle Lasten. Aus diesem Grund AWS DMS können Quell- und Zieldatenbanken miteinander verbunden werden, um Datenbankinhalte gemäß den folgenden Prozessen zu replizieren:

Möglicherweise müssen Sie den Umgang mit bestimmten Datentypen optimieren AWS DMS . Weitere Informationen finden Sie unter Verwenden einer SAP ASE-Datenbank als Quelle für AWS DMS.

Offline-Daten migrieren

Sie können AWS Storage Gateway Ihre SAP ASE-Datenbank mit Amazon Simple Storage Service (Amazon S3) integrieren, der kostengünstigen, skalierbaren und sicheren Speicher für lokale SAP ASE-Datenbanksicherungen bietet. Weitere Informationen finden Sie unter Integrieren einer SAP ASE-Datenbank in Amazon S3 mithilfe von AWS Storage Gateway.

Verwenden von Tools von Drittanbietern

Einige Anwendungen dienen als zentrale Anlaufstelle (SPOC), die mit anderen Anwendungen verbunden ist. Bei der Migration zu einer SQL Server-Datenbankplattform können diese Verbindungen beeinträchtigt werden, und für die Datenbanküberwachung sind möglicherweise native Tools oder Tools von Drittanbietern erforderlich, die serverspezifische Kommunikationsprotokolle verwenden. Es ist wichtig zu beurteilen, ob diese abhängigen Anwendungen und Tools SQL Server bereits unterstützen oder ob sie geändert werden müssen, damit sie ordnungsgemäß funktionieren.

Wenden Sie sich bei Anwendungspaketen an die Anbieter, um zu erfahren, ob sie Amazon RDS for SQL Server unterstützen. Bei benutzerdefinierten Anwendungen müssen Sie möglicherweise den Code ändern, um die Kompatibilität mit der migrierten Datenbank sicherzustellen.

Überwachung der Datenbank

Unabhängig von Ihrem gewählten Migrationspfad CloudWatch spielt Amazon eine Rolle bei der Erfassung von Metriken wie CPU-Typ, Arbeitsspeicher und I/O Funktionen. Es ist auch in der Lage, Schwellenwerte für Metriken festzulegen und Aktionen einzuleiten, wenn Schwellenwerte ausgelöst werden.

Sie können beispielsweise Alarme für Amazon RDS-Cluster-Metriken, Benachrichtigungen und Aktionen erstellen, um ungenutzte oder nicht ausgelastete Reader-Instances zu erkennen und herunterzufahren. Das Einrichten von Alarmen für Metriken und Ereignisse kann dazu beitragen, Ausfallzeiten und geschäftliche Auswirkungen zu minimieren. AWS-Services wie Amazon S3, Amazon RDS Performance Insights und Amazon CloudWatch AWS CloudTrail sind bereits in die RDS-Datenbankplattform integriert, und wir empfehlen ihnen, die Leistung zu überwachen.

Validierung der Daten

Nachdem die Datenmigration von SAP ASE zu Amazon RDS for SQL Server abgeschlossen ist, validieren Sie die Daten, um Genauigkeit und Konsistenz sicherzustellen. Verwenden Sie die folgenden SQL-Abfragen, um Metadatenanweisungen für jede Tabelle in Ihrer Datenbank zu generieren.

Schritt 1: Generieren Sie Metadatenanweisungen und Spaltenlisten

SELECT dt.schema_name, dt.table_name,
    STRING_AGG(dt.column_name, ',') AS column_name,
    STRING_AGG(dt.cname, ',') AS column_order
FROM (
    SELECT 
        object_name(a.id) AS table_name,
        a.name colname,
        c.name col_type,
        a.isnullable,
        a.name AS cname,
        schema_name(b.uid) AS schema_name,
        CASE 
            WHEN a.isnullable = 1 THEN
                CASE 
                    WHEN c.name LIKE '%char%' 
                        THEN 'coalesce(ltrim(rtrim('+a.name+')),''X'') as '+a.name
                    WHEN (c.name LIKE '%int%' OR c.name = 'numeric') 
                        THEN 'coalesce('+a.name+',0) as '+a.name
                    WHEN c.name IN ('decimal','float','money') 
                        THEN 'coalesce('+a.name+',0.0) as '+a.name
                    WHEN c.name LIKE 'datetime%' 
                        THEN 'coalesce(convert(nvarchar(30),'+a.name+',112),''99991231'') as '+a.name
                    ELSE a.name 
                END
            WHEN c.name LIKE 'datetime%' 
                THEN 'coalesce(convert(nvarchar(30),'+a.name+',112),''99991231'') as '+a.name
            WHEN c.name LIKE '%char%' 
                THEN 'coalesce(ltrim(rtrim('+a.name+')),''X'') as '+a.name
            ELSE a.name
        END AS column_name
    FROM syscolumns a
    INNER JOIN sysobjects b
        ON a.id = b.id 
        AND b.type = 'U'
    INNER JOIN systypes c
        ON a.usertype = c.usertype
        AND a.xusertype = c.xusertype
        AND c.name != 'varbinary'
    INNER JOIN (
        SELECT 
            OBJECT_NAME(ic.OBJECT_ID) AS table_name,
            COL_NAME(ic.OBJECT_ID, ic.column_id) AS column_name
        FROM sys.indexes AS i
        INNER JOIN sys.index_columns AS ic
            ON i.OBJECT_ID = ic.OBJECT_ID
            AND i.index_id = ic.index_id
            AND i.is_primary_key = 1
    ) pk
        ON pk.table_name = object_name(a.id)
        AND pk.column_name = a.name
) dt 
GROUP BY dt.schema_name, dt.table_name;

In der folgenden Tabelle sind Beispiele für Ausgaben aufgeführt:

Schritt 2: Generieren Sie Vergleichsabfragen anhand der Metadatenergebnisse und erstellen Sie SELECT-Anweisungen

SELECT <column_name>
FROM [schema_name].[table_name]
ORDER BY <column_order>;

Im Folgenden finden Sie ein Beispiel für eine generierte Abfrage:

SELECT BusinessEntityID, AddressID, AddressTypeID
FROM [Person].[BusinessEntityAddress]
ORDER BY BusinessEntityID, AddressID, AddressTypeID;

Schritt 3: Validierung

Schritt 4: Überprüfen Sie die Zeilenanzahl

SELECT COUNT(1) AS total_rows
FROM [schema_name].[table_name];

Schritt 5: Aktualisieren Sie die Konfiguration Ihrer Anwendung, sodass sie auf die neue Datenbank verweist

Testen der Migration

Der Testprozess kann Ihnen helfen, Probleme zu identifizieren, die während der Entwicklung übersehen wurden, wie z. B. falsch konvertierte Abfragen oder fehlende Indizes. Und es kann aufzeigen, dass eine Optimierung der Datenbank-Engine oder Abfrageänderungen auf der Grundlage der Workload-Leistung erforderlich sind.

Funktionstests, zu denen auch Komponententests für Anwendungsworkflows gehören, tragen dazu bei, eine nahtlose Integration in Ihre neue Datenbank sicherzustellen. Leistungstests helfen dabei, Ihre Datenbank zu optimieren, indem akzeptable Antwortzeiten überprüft und Engpässe identifiziert werden.

Es gibt zwar sowohl manuelle als auch automatisierte Testmethoden, wir empfehlen jedoch eine automatisierte Methode, da sie effizienter ist, insbesondere für zusätzliche Testzyklen.