Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Phase 3 : Migration

L'une des principales tâches des migrations de bases de données consiste à effectuer la migration avec un minimum de temps d'arrêt. Comme les deux bases de données doivent utiliser le même langage de programmation et les mêmes protocoles de communication, vous devrez peut-être convertir le code et le schéma pour obtenir des syntaxes, des procédures et des fonctions de requête similaires. Lors de la conversion d'un schéma, tenez compte des aspects suivants :

Vous pouvez utiliser n'importe quel outil de migration tiers pour convertir le code de schéma, tel que la base de données SAP ASE et Amazon RDS for SQL Server. Il se peut que vous deviez convertir du code manuellement car le SQL non ANSI n'est pas pris en charge dans SQL Server.

Après avoir converti le code, convertissez le code de votre application ou votre application Dynamic SQL, puis effectuez des tests unitaires et fonctionnels. Pour plus d'informations, voir Tester des objets de base de données migrés (SybaseToSQL).

Conversion des données

Transformez les données brutes pour les rendre plus utiles en les nettoyant, en les normalisant, en les vérifiant et en les triant. Dans les migrations de bases de données, les processus d'extraction, de transformation et de chargement (ETL) sont utilisés de la manière suivante :

Informatica et Talend sont AWS Glue des exemples d'outils ETL. Pour les migrations de SAP ASE vers SQL Server, certains outils gratuits peuvent convertir automatiquement les procédures et les fonctions stockées.

Validation des objets de base de données

La validation de votre base de données permet d'éviter les problèmes lors des étapes de migration suivantes. Après la conversion du code, validez le schéma de votre base de données en comparant les éléments suivants entre SAP ASE et RDS SQL Server :

Vérifiez que chaque objet a migré correctement. Si vous trouvez des différences, identifiez la raison de l'échec. Vous devrez peut-être créer manuellement des objets manquants dans la base de données cible ou convertir le code Transact-SQL. Pour plus d'informations, consultez la section Valider les objets de base de données après la migration de SAP ASE vers Amazon RDS for SQL Server ou Microsoft SQL Server.

Migration de données à l'aide de AWS DMS

Si vous avez plusieurs utilisateurs de base de données, il se peut que votre application doive être migrée selon un calendrier. En fonction de la taille de la base de données et de la fenêtre de migration, ces migrations de données nécessitent la connaissance des chargements complets et des chargements incrémentiels. Pour cette raison, AWS DMS vous pouvez connecter les bases de données source et cible pour répliquer le contenu des bases de données conformément aux processus suivants :

Vous devrez peut-être optimiser la gestion AWS DMS de certains types de données. Pour plus d'informations, consultez la section Utilisation d'une base de données SAP ASE comme source pour AWS DMS.

Migration de données hors ligne

Vous pouvez l'utiliser AWS Storage Gateway pour intégrer votre base de données SAP ASE à Amazon Simple Storage Service (Amazon S3), qui fournit un stockage rentable, évolutif et sécurisé pour les sauvegardes de base de données SAP ASE sur site. Pour plus d'informations, consultez Intégrer une base de données SAP ASE à Amazon S3 à l'aide de AWS Storage Gateway.

Utilisation d'outils tiers

Certaines applications font office de point de contact unique (SPOC) qui assure l'interface avec d'autres applications. Lors de la migration vers une plate-forme de base de données SQL Server, ces interconnexions peuvent être affectées, et la surveillance des bases de données peut nécessiter des outils natifs ou tiers utilisant des protocoles de communication spécifiques au serveur. Il est important de déterminer si ces applications et outils dépendants prennent déjà en charge SQL Server ou s'ils doivent être modifiés pour fonctionner correctement.

Pour les applications packagées, consultez les fournisseurs afin de déterminer s'ils prennent en charge Amazon RDS for SQL Server. Pour les applications personnalisées, vous devrez peut-être modifier le code pour garantir la compatibilité avec la base de données migrée.

Surveillance de la base de données

Quel que soit le chemin de migration que vous avez choisi, Amazon CloudWatch joue un rôle dans la collecte de statistiques, telles que le type de processeur, la mémoire et I/O les fonctions. Il est également capable de définir des seuils de métriques et de lancer des actions lorsque des seuils sont déclenchés.

Par exemple, vous pouvez créer des alarmes pour les métriques, les notifications et les actions du cluster Amazon RDS afin de détecter et d'arrêter les instances de lecteur inutilisées ou sous-utilisées. La définition d'alarmes en fonction des métriques et des événements peut contribuer à minimiser les temps d'arrêt et les impacts commerciaux. Services AWS comme Amazon S3, Amazon RDS Performance Insights, Amazon CloudWatch, et AWS CloudTrail sont déjà intégrés à la plate-forme de base de données RDS, et nous les recommandons pour surveiller les performances.

Validation des données

Une fois la migration des données de SAP ASE vers Amazon RDS for SQL Server terminée, validez les données pour garantir leur précision et leur cohérence. Utilisez les requêtes SQL suivantes pour générer des instructions de métadonnées pour chaque table de votre base de données.

Étape 1 : générer des instructions de métadonnées et des listes de colonnes

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;

Le tableau suivant répertorie des exemples de sorties :

Étape 2 : générer des requêtes de comparaison à l'aide des résultats des métadonnées et créer des instructions SELECT

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

Voici un exemple de requête générée :

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

Étape 3 : Validation

Étape 4 : valider le nombre de lignes

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

Étape 5 : mettez à jour la configuration de votre application pour qu'elle pointe vers la nouvelle base de données

Tester la migration

Le processus de test peut vous aider à identifier les problèmes négligés lors du développement, tels que les requêtes mal converties ou les index manquants. Et cela peut révéler la nécessité de régler le moteur de base de données ou de modifier les requêtes en fonction des performances de la charge de travail.

Les tests fonctionnels, qui incluent des tests unitaires pour les flux de travail des applications, contribuent à garantir une intégration parfaite avec votre nouvelle base de données. Les tests de performance permettent d'optimiser votre base de données en vérifiant les temps de réponse acceptables et en identifiant les goulets d'étranglement.

Bien qu'il existe des méthodes de test manuelles et automatisées, nous recommandons une méthode automatisée car elle est plus efficace, en particulier pour les cycles de test supplémentaires.