Cette rubrique explique comment utiliser le service de transmission de données pour migrer des données d'une instance ApsaraDB RDS for PostgreSQL vers une base de données OceanBase en mode compatible Oracle.
Si une tâche de migration de données reste inactive pendant une période prolongée (avec un statut Failed, Paused ou Completed), il se peut qu'elle ne puisse pas être reprise en raison de facteurs tels que la période de rétention des journaux incrémentiels. Pour libérer des ressources, le service de transmission de données libère les tâches de migration de données qui sont restées inactives pendant plus de trois jours. Nous vous recommandons de configurer des alertes pour vos tâches et de traiter rapidement toute exception.
Prérequis
Le service de transmission de données dispose des privilèges nécessaires pour accéder aux ressources cloud. Pour plus d'informations, consultez la rubrique Autorisation de rôle pour la transmission et la migration de données.
Vous avez créé un compte privilégié dédié à la migration des données dans l'instance source ApsaraDB RDS for PostgreSQL. Pour plus d'informations, consultez la rubrique Source de données PostgreSQL.
Vous avez créé un utilisateur de base de données dédié à la migration des données dans la base de données OceanBase en mode compatible Oracle et vous lui avez accordé les privilèges requis. Pour plus d'informations, consultez la rubrique Créer un utilisateur de base de données.
-
Si vous devez effectuer une synchronisation incrémentielle, effectuez d'abord les opérations suivantes :
-
Le service de transmission de données ne prend pas en charge la synchronisation automatique des instructions DDL lors de la synchronisation incrémentielle. Si une instruction DDL doit être exécutée sur la table à migrer, exécutez manuellement l'instruction DDL au niveau de la cible, puis exécutez-la dans l'instance source ApsaraDB RDS for PostgreSQL.
Pour analyser correctement les opérations DML incrémentielles effectuées après l'exécution de l'instruction DDL, vous devez créer un déclencheur correspondant ainsi qu'une table pour enregistrer l'instruction DDL. Pour plus d'informations, consultez la rubrique Créer un déclencheur.
Si vous sélectionnez Incremental Synchronization, vous devez définir le paramètre wal_level sur logical.
Pour plus d'informations, consultez la rubrique Modifier le niveau de journalisation d'une instance ApsaraDB RDS for PostgreSQL.
-
Limitations
-
Limitations relatives à la base de données source
N'effectuez pas d'opérations DDL modifiant les schémas de la base de données ou des tables lors de la migration du schéma ou de la migration complète. Sinon, la tâche de migration des données risque d'être interrompue.
Seules les instances ApsaraDB RDS for PostgreSQL versions 11.x et 12.x sont prises en charge.
Le service de transmission de données ne prend pas en charge la migration des tables partitionnées, des tables non journalisées (unlogged) ou des tables temporaires depuis une instance ApsaraDB RDS for PostgreSQL.
Le service de transmission de données ne prend pas en charge les déclencheurs lorsque la cible est une base de données. Si des déclencheurs existent dans la base de données cible, la migration des données peut échouer.
Le service de transmission de données prend en charge la migration d'un objet uniquement si les conditions suivantes sont remplies : le nom de la base de données, le nom de la table et le nom de la colonne de l'objet sont encodés en ASCII sans caractères spéciaux. Les caractères spéciaux incluent les sauts de ligne, les espaces et les caractères suivants : . | " ' ` ( ) = ; / & \.
Le service de transmission de données prend en charge la synchronisation incrémentielle uniquement à partir de la base de données principale.
Considérations
-
Si vous sélectionnez Incremental Synchronization, l'option REPLICA IDENTITY au niveau de la table doit respecter les exigences suivantes :
Si vous sélectionnez Specify Objects pour spécifier les objets de migration, les tables spécifiées doivent disposer d'une clé primaire ou vous devez définir l'option
REPLICA IDENTITYau niveau de la table sur FULL. Sinon, les opérations de mise à jour et de suppression des données métier échoueront.Si vous sélectionnez Match Rules pour spécifier les objets de migration, l'instance ApsaraDB RDS for PostgreSQL doit s'abonner aux modifications de toutes les tables (y compris les tables sélectionnées, non sélectionnées et nouvelles) des bases de données sélectionnées, et toutes les tables doivent disposer d'une clé primaire ou vous devez définir l'option
REPLICA IDENTITYau niveau de la table sur FULL. Sinon, les opérations de mise à jour et de suppression des données métier échoueront.Si les clés primaires ou uniques des tables source et cible ne sont pas entièrement alignées, l'option
REPLICA IDENTITYau niveau de la table doit être définie sur FULL pour ces tables.Les images avant complètes ne sont pas renvoyées pour les tables dont l'option REPLICA IDENTITY est définie sur DEFAULT dans l'instance ApsaraDB RDS for PostgreSQL. Pour garantir la qualité des données, le service de transmission de données migre les tables correspondantes en mode série, ce qui compromet l'efficacité de la synchronisation incrémentielle. Par conséquent, nous vous recommandons de définir l'option
REPLICA IDENTITYau niveau de la table sur FULL pour toutes les tables.
Vous pouvez exécuter l'instruction suivante pour définir l'option
REPLICA IDENTITYau niveau de la table sur FULL :ImportantSi des conditions de filtrage de lignes ont été définies pour un objet table à migrer, l'option
REPLICA IDENTITYdoit être définie sur FULL pour cette table.ALTER TABLE table_name REPLICA IDENTITY FULL; Lorsque vous migrez des schémas ou des opérations DDL incrémentielles d'une instance ApsaraDB RDS for PostgreSQL vers une base de données OceanBase en mode compatible Oracle, les lettres minuscules des noms de tables et de champs sont converties en majuscules selon les stratégies par défaut du service de transmission de données. Par exemple, le nom de table source « a » est converti en « A » par défaut au niveau de la cible. Vous pouvez spécifier un nom de table ou de champ au format a, A ou « A », mais pas « a ».
-
Le composant Incr-Sync d'une instance ApsaraDB RDS for PostgreSQL crée automatiquement des publications et des slots, mais vous devez surveiller l'utilisation du disque des journaux de l'instance. Par défaut, le service de transmission de données notifie l'instance, à un intervalle de 10 minutes, de mettre à jour la valeur
confirmed_flush_lsnd'un slot avec le dernier numéro de séquence de journal (LSN) datant d'il y a 10 minutes. Ainsi, chaque composant Incr-Sync conserve au moins 10 minutes de journaux de l'instance ApsaraDB RDS for PostgreSQL.RemarqueSi vous souhaitez modifier l'intervalle de notification ou la période de rétention des fichiers journaux générés par l'instance ApsaraDB RDS for PostgreSQL, contactez le support technique d'OceanBase.
Si les journaux de l'instance ApsaraDB RDS for PostgreSQL ne peuvent pas être purgés pendant la migration des données en raison de l'existence de slots, vous devez supprimer la tâche de migration des données, puis purger les journaux. La plus petite valeur
slot restart_lsnparmi tous les slots détermine si les fichiers journaux de l'instance ApsaraDB RDS for PostgreSQL peuvent être recyclés. Si la plus petite valeur se situe dans la plage des fichiers journaux, ceux-ci ne sont pas recyclés. Lorsque vous synchronisez des données vers la cible, des données en double peuvent exister si la table cible ne possède pas de clé primaire ou de clé unique non nulle.
-
Lors de l'incrémentation inverse de tables sans clé primaire, si la migration des données est effectuée en mode de correspondance de colonnes complètes pour les opérations UPDATE et DELETE, les problèmes suivants peuvent survenir :
-
Problèmes de performances
En l'absence d'index de clé primaire, chaque opération UPDATE ou DELETE sera effectuée après une analyse complète de la table.
-
Incohérence des données
La clause LIMIT n'est pas prise en charge pour les opérations UPDATE et DELETE dans l'instance ApsaraDB RDS for PostgreSQL. Dans ce cas, si plusieurs enregistrements correspondent en mode de correspondance de colonnes complètes, le nombre d'enregistrements de données affectés par une opération UPDATE ou DELETE peut être supérieur à celui attendu. Supposons que la table t1 sans clé primaire possède deux colonnes, c1 et c2. Deux enregistrements de données où c1 = 1 et c2 = 2 existent à la source. Lorsque vous supprimez un seul enregistrement de données à la source selon la condition where c1 = 1 and c2 = 2, les deux enregistrements de données à la cible seront supprimés car ils correspondent tous deux à la condition. Cela entraîne une incohérence des données entre la source et la cible.
-
-
Le service de transmission de données prend en charge l'incrémentation inverse des champs tsvector depuis OceanBase Database vers une instance ApsaraDB RDS for PostgreSQL. Les champs tsvector doivent être écrits dans OceanBase Database selon les formats pris en charge. Voici quelques exemples :
Les données écrites dans OceanBase Database au format 'a b c' seront converties au format "'a' 'b' 'c'" dans l'instance ApsaraDB RDS for PostgreSQL.
Les données écrites dans OceanBase Database au format 'a:1 b:2 c:3' seront converties au format "'a':1 'b':2 'c':3" dans l'instance ApsaraDB RDS for PostgreSQL.
Les données écrites dans OceanBase Database dans un format non tsvector tel que "'a':cccc" ne peuvent pas être migrées vers l'instance ApsaraDB RDS for PostgreSQL. Pour plus d'informations sur les formats pris en charge, consultez la documentation 8.11. Text Search Types in PostgreSQL documentation.
Si le jeu de caractères UTF-8 est utilisé dans la base de données source, nous vous recommandons d'utiliser un jeu de caractères compatible, tel que UTF-8 ou UTF-16, dans la base de données cible pour éviter les caractères illisibles.
Vérifiez si la précision de migration du service de transmission de données pour les colonnes de types de données tels que DECIMAL, FLOAT et DOUBLE correspond à vos attentes. Si la précision du type de champ cible est inférieure à celle du type de champ source, la valeur ayant une précision plus élevée peut être tronquée. Cela peut entraîner une incohérence des données entre les champs source et cible.
Si vous modifiez un index unique au niveau de la cible, vous devez redémarrer la tâche de migration des données pour éviter toute incohérence des données.
-
Si les horloges entre les nœuds ou entre le client et le serveur ne sont pas synchronisées, la latence peut être imprécise lors de la synchronisation incrémentielle ou de l'incrémentation inverse.
Par exemple, si l'horloge est en avance par rapport à l'heure standard, la latence peut être négative. Si l'horloge est en retard par rapport à l'heure standard, la latence peut être positive.
-
Tenez compte des considérations suivantes si vous souhaitez regrouper plusieurs tables :
Nous vous recommandons de configurer les mappages entre la source et la cible en spécifiant des règles de correspondance.
Nous vous recommandons de créer manuellement les schémas au niveau de la cible. Si vous créez un schéma à l'aide du service de transmission de données, ignorez les objets ayant échoué lors de l'étape de migration du schéma.
-
Si vous sélectionnez uniquement Incremental Synchronization lors de la création de la tâche de migration des données, le service de transmission de données exige que les journaux incrémentiels locaux de la base de données source soient conservés pendant au moins 48 heures.
Si vous sélectionnez Full Migration et Incremental Synchronization lors de la création de la tâche de migration des données, le service de transmission de données exige que les journaux incrémentiels locaux de la base de données source soient conservés pendant au moins 7 jours. Si le service de transmission de données ne peut pas obtenir les journaux incrémentiels, la tâche de migration des données peut échouer, voire entraîner une incohérence des données entre la source et la cible après la migration.
Si la source ou la cible contient des objets de table qui ne diffèrent que par la casse, les résultats de la migration des données peuvent ne pas être conformes aux attentes en raison de l'insensibilité à la casse au niveau de la source ou de la cible.
Une perte de données peut survenir si une colonne avec une contrainte UNIQUE autorise les valeurs NULL. Plus précisément, si plusieurs valeurs NULL de la colonne existent dans l'instance ApsaraDB RDS for PostgreSQL, seule la première est synchronisée avec succès et les valeurs NULL suivantes sont ignorées en raison de la violation de la contrainte UNIQUE.
Types d'instances source et cible pris en charge
Dans le tableau suivant, OB_Oracle désigne une base de données OceanBase en mode compatible Oracle.
|
Source |
Target |
|
PostgreSQL (instance ApsaraDB RDS) |
OB_Oracle (instance de cluster OceanBase) |
|
PostgreSQL (instance ApsaraDB RDS) |
OB_Oracle (base de données gérée par l'utilisateur dans un VPC) |
Correspondance des types de données
Type de données dans une instance ApsaraDB RDS for PostgreSQL | Type de données dans une base de données OceanBase en mode compatible Oracle |
int | NUMBER(10) |
smallint | NUMBER(5) |
bigint | NUMBER(20) |
decimal | NUMBER(p,s) |
numeric | NUMBER(p,s) |
real | BINARY_FLOAT |
double precision | BINARY_DOUBLE |
smallserial | NUMBER(5) |
serial | NUMBER(10) |
bigserial | NUMBER(20) |
char | CHAR(n) Remarque La longueur par défaut et la longueur maximale d'une colonne du type de données |
varchar | VARCHAR2(n) |
text | CLOB |
timestamp | TIMESTAMP(p) |
timestamp with time zone | TIMESTAMP(p) WITH TIME ZONE |
time | DATE |
time with time zone | TIMESTAMP(p) WITH TIME ZONE |
boolean | NUMBER(1) |
bytea | BLOB |
citext | CLOB |
tsvector | CLOB |
Procédure
-
Connectez-vous à la console OceanBase Management et achetez une tâche de migration de données.
Pour plus d'informations, consultez la rubrique Acheter une tâche de migration de données.
-
Sélectionnez Data Transmission > Data Migration. Sur la page qui s'affiche, cliquez sur Configuration pour la tâche de migration de données.

Si vous souhaitez réutiliser les configurations d'une tâche existante, cliquez sur Reference Configuration. Pour plus d'informations, consultez la rubrique Réutiliser la configuration d'une tâche de migration de données.
-
Sur la page Select Source and Target, configurez les paramètres associés.
Parameter
Description
Migration Task Name
Nous vous recommandons de définir un nom composé de chiffres et de lettres. Il ne doit contenir aucun espace et sa longueur ne peut pas dépasser 64 caractères.
Source
Si vous avez déjà créé une source de données PostgreSQL, sélectionnez-la dans la liste déroulante. Sinon, cliquez sur New Data Source dans la liste déroulante et créez-en une dans la boîte de dialogue qui s'affiche à droite. Pour plus d'informations, consultez la rubrique Créer une source de données PostgreSQL.
Target
Si vous avez déjà créé une base de données OceanBase en mode compatible Oracle comme source de données, sélectionnez-la dans la liste déroulante. Sinon, cliquez sur New Data Source dans la liste déroulante et créez-en une dans la boîte de dialogue qui s'affiche à droite. Pour plus d'informations sur les paramètres, consultez la rubrique Créer une source de données OceanBase.
Tag (Optional)
Sélectionnez un tag cible dans la liste déroulante. Vous pouvez également cliquer sur Manage Tags pour créer, modifier et supprimer des tags. Pour plus d'informations, consultez la rubrique Gérer les tâches de migration de données avec des tags.
-
Cliquez sur Next. Sur la page Select Migration Type, spécifiez les types de migration pour la tâche de migration de données actuelle.
Les options disponibles pour Migration Type sont Schema Migration, Full Migration, Incremental Synchronization, Full Verification et Reverse Increment.

Type de migration
Description
Migration de schéma
Une fois la tâche de migration de schéma lancée, le service de transmission de données migre les définitions des objets de base de données (tables, index, contraintes, commentaires et vues) de la base de données source vers la base de données cible et filtre automatiquement les tables temporaires.
Migration complète
Après le démarrage d'une tâche de migration complète, le service de transmission de données migre les données existantes des tables de la base de données source vers les tables correspondantes de la base de données cible.
Synchronisation incrémentielle
Une fois la tâche de synchronisation incrémentielle démarrée, le service de transmission de données synchronise les données modifiées (ajoutées, modifiées ou supprimées) de la base de données source vers les tables correspondantes de la base de données cible.
DML Synchronization est pris en charge pour Incremental Synchronization. Vous pouvez sélectionner les opérations selon vos besoins. Pour plus d'informations, consultez la rubrique Configurer la synchronisation DDL/DML.
Vérification complète
Une fois les tâches de migration complète et de synchronisation incrémentielle terminées, le service de transmission de données lance automatiquement une tâche de vérification complète pour vérifier les tables des bases de données source et cible.
RemarqueSi vous avez sélectionné Incremental Synchronization sans toutefois choisir toutes les opérations DML dans la section DML synchronization, le service de transmission de données ne prend pas en charge la vérification complète.
Le service de transmission de données prend en charge la vérification complète uniquement pour les tables disposant de clés primaires ou de clés uniques non nulles.
Incrémentation inverse
Les modifications de données apportées à la base de données cible après le basculement de la base de données métier sont synchronisées avec la base de données source en temps réel via l'incrémentation inverse.
En général, les configurations de synchronisation incrémentielle sont réutilisées pour l'incrémentation inverse. Vous pouvez également personnaliser les configurations d'incrémentation inverse selon vos besoins.
-
Cliquez sur Next. Sur la page Select Migration Objects, spécifiez les objets à migrer pour la tâche de migration de données.
Vous pouvez sélectionner Specify Objects ou Match Rules pour définir les objets de migration. Cette rubrique explique comment spécifier les objets de migration à l'aide de l'option Specify Objects. Pour obtenir des informations sur les règles de correspondance, consultez la rubrique Configurer et modifier les règles de correspondance.
ImportantLes noms des tables à migrer, ainsi que les noms des colonnes dans ces tables, ne doivent pas contenir de caractères chinois.
Si un nom de base de données ou de table contient des doubles signes dollar ($$), vous ne pouvez pas créer la tâche de migration.

Dans la section Select Migration Objects, sélectionnez Specify Objects.
Dans la liste Source Object(s) de la section Specify Migration Scope, sélectionnez les objets à migrer. Vous pouvez sélectionner des tables et des vues d'une ou plusieurs bases de données.
Cliquez sur > pour les ajouter à la liste Target Object(s).
Le service Data Transmission Service vous permet d'importer des objets à partir de fichiers texte. Il vous permet également de renommer les objets de destination, de définir des filtres de ligne, d'afficher les informations sur les colonnes et de supprimer un objet unique ou tous les objets.
RemarqueLorsque vous sélectionnez des objets de migration à l'aide de la méthode Matching Rules, la syntaxe des règles de correspondance remplace la fonctionnalité de renommage et la section Actions se limite à la définition de conditions de filtrage. Pour plus d'informations, consultez la rubrique Configurer et modifier les règles de correspondance.
Opération
Description
Importer un objet
Dans la liste à droite de la zone de sélection, cliquez sur Import Object dans le coin supérieur droit.
Dans la boîte de dialogue qui s'affiche, cliquez sur OK.
ImportantL'opération d'importation écrase les sélections précédentes. Procédez avec prudence.
Dans la boîte de dialogue Import Migration Objects, importez les objets à migrer.
Vous pouvez importer un fichier CSV pour renommer les tables de la base de données, définir des conditions de filtrage de ligne et effectuer d'autres opérations. Pour plus d'informations, consultez la rubrique Télécharger et importer les configurations des objets de migration.
Cliquez sur Check Validity.
Après avoir importé les objets de migration, vérifiez d'abord leur validité. Le mappage des champs de colonne n'est pas actuellement pris en charge.
Une fois la vérification réussie, cliquez sur OK.
Renommer
Le service Data Transmission Service vous permet de renommer les objets de migration. Pour plus d'informations, consultez la rubrique Renommer les objets de base de données et de table.
Paramètres
Le service Data Transmission Service prend en charge le filtrage des lignes à l'aide des conditions
WHERE. Pour plus d'informations, consultez la rubrique Filtrer les données avec des conditions SQL.Vous pouvez également afficher les informations sur les colonnes des objets de migration dans la zone View Columns.
Supprimer/Supprimer tout
Le service Data Transmission Service vous permet de supprimer un ou plusieurs objets temporairement sélectionnés pour la destination lors du mappage des données.
Supprimer un seul objet de migration
Dans la liste à droite de la zone de sélection, placez le curseur sur l'objet cible et cliquez sur le bouton Remove qui s'affiche pour supprimer l'objet de migration.
Supprimer tous les objets de migration
Dans la liste à droite de la zone de sélection, cliquez sur Remove All dans le coin supérieur droit. Dans la boîte de dialogue qui s'affiche, cliquez sur OK pour supprimer tous les objets de migration.
-
Cliquez sur Next. Sur la page Migration Options, configurez les paramètres.
-
Migration complète
Les paramètres suivants s'affichent uniquement si vous sélectionnez Full Migration sur la page Select Migration Types.

Parameter
Description
Read Concurrency
Ce paramètre définit le nombre de threads simultanés utilisés pour lire les données depuis la source lors de la migration complète. La valeur maximale est 512. Un niveau de simultanéité élevé peut exercer une pression excessive sur la base de données source et affecter votre activité.
Write Concurrency
Ce paramètre définit le nombre de threads simultanés utilisés pour écrire les données dans la destination lors de la migration complète. La valeur maximale est 512. Un niveau de simultanéité élevé peut exercer une pression excessive sur la base de données de destination et affecter votre activité.
Full Migration Rate Limit
Vous pouvez activer la limitation du débit de migration complète selon vos besoins. Si vous l'activez, définissez les valeurs RPS (nombre maximal de lignes de données pouvant être migrées vers la destination par seconde lors de la migration complète) et BPS (volume maximal de données pouvant être migré vers la destination par seconde lors de la migration complète).
RemarqueLes paramètres RPS et BPS servent uniquement de limites de throttling. Les performances réelles de la migration complète dépendent de plusieurs facteurs, tels que la source, la destination et les spécifications de l'instance.
Policy for Existing Records in Destination Table Objects
Les politiques disponibles sont Ignore et Stop Migration :
Sélectionnez Ignore : si des données existent déjà dans l'objet table de destination et qu'un conflit survient entre les données d'origine et celles à écrire, DTS enregistre les données conflictantes dans les journaux et conserve les données d'origine sans modification.
ImportantSi vous sélectionnez Ignore, la vérification complète utilise le mode IN pour extraire les données. Elle ne permet pas de vérifier les scénarios où la destination contient des données absentes de la source. Les performances de vérification sont également légèrement dégradées.
Sélectionnez la valeur par défaut Stop Migration : si des données existent dans l'objet table de destination, la migration complète génère une erreur et s'interrompt. Traitez les données présentes dans la destination, puis reprenez la migration.
ImportantSi vous cliquez sur Resume après une erreur, DTS ignore ce paramètre et poursuit la migration des données de table. Procédez avec prudence.
Allow index suffixes
Vous pouvez indiquer si la création d'index doit être autorisée après la fin de la migration complète des données. Cette fonctionnalité permet de réduire la durée nécessaire à la migration complète. Pour plus d'informations sur la création d'index post-migration, consultez la description située sous le tableau.
ImportantCe paramètre n'est affiché que si vous sélectionnez à la fois Schema Migration et Full Migration sur la page Select Migration Types.
Seuls les index non uniques prennent en charge la création post-migration.
Lors de la création d'un index, si la base de données OceanBase de destination renvoie l'une des erreurs suivantes, DTS ignore l'erreur et considère l'index comme créé avec succès. Aucune nouvelle tentative de création ne sera effectuée.
Le locataire MySQL de la base de données OceanBase renvoie une erreur
Duplicate key name.Le locataire Oracle de la base de données OceanBase renvoie une erreur
name is already used by an existing object.
Si la destination est une base de données OceanBase et que vous sélectionnez Allow, configurez les paramètres suivants :
Simultanéité pour une seule instruction DDL d'index : un degré de parallélisme plus élevé consomme davantage de ressources et accélère la migration.
Nombre maximal d'instructions DDL d'index simultanées : nombre maximal d'instructions DDL de création d'index post-migration que le système peut invoquer simultanément.
Si vous autorisez la création d'index après la migration, nous vous recommandons d'utiliser un client en ligne de commande pour ajuster les paramètres de locataire métier suivants en fonction du matériel et du trafic de service de la base de données OceanBase.
// File memory buffer limit alter system set _temporary_file_io_area_size = '10' tenant = 'xxx'; // V4.x disable throttling alter system set sys_bkgd_net_percentage = 100; -
Synchronisation incrémentielle
Le tableau suivant décrit les paramètres de synchronisation incrémentielle, qui ne s'affichent que si vous avez sélectionné Incremental Synchronization sur la page Select Migration Type.

Parameter
Description
Write Concurrency
Simultanéité des écritures de données vers la cible lors de la synchronisation incrémentielle. La valeur maximale est 512. Une simultanéité d'écriture élevée peut exercer une pression excessive sur la cible et affecter votre activité.
Incremental Synchronization Rate Limit
Vous pouvez choisir de limiter ou non le débit de synchronisation incrémentielle selon vos besoins. Si vous optez pour cette limitation, vous devez spécifier les valeurs RPS (records per second) et BPS (bytes per second). Le paramètre RPS définit le nombre maximal de lignes de données synchronisées vers la cible par seconde lors de la synchronisation incrémentielle, tandis que le paramètre BPS définit le volume maximal de données (en octets) synchronisé vers la cible par seconde.
RemarqueLes valeurs RPS et BPS indiquées ici servent uniquement de limites de throttling. Les performances réelles de la synchronisation incrémentielle dépendent de facteurs tels que la configuration de la source et de la cible, ainsi que des spécifications de l'instance.
Incremental Synchronization Start Timestamp
Ce paramètre n'est affiché que si vous n'avez pas sélectionné Full Migration sur la page Select Migration Type. Ce paramètre n'est pas disponible lorsque la source est une base de données PostgreSQL. Dans ce cas, l'heure de début de la synchronisation incrémentielle est utilisée par défaut.
-
Incrémentiel inverse
Les paramètres de cette section n'apparaissent que si vous sélectionnez Reverse Incremental Synchronization sur la page Select Migration Types. Par défaut, l'option Reuse Incremental Synchronization Configuration est sélectionnée.

Vous pouvez également désactiver cette option et configurer les paramètres selon vos besoins.
Parameter
Description
Write Concurrency
Ce paramètre définit le nombre de threads simultanés utilisés pour écrire les données dans la source lors de la synchronisation incrémentielle inverse. La valeur maximale est 512. Un niveau de simultanéité élevé peut exercer une pression excessive sur la base de données source et affecter votre activité.
Reverse Incremental Synchronization Rate Limit
Vous pouvez activer la limitation du débit de synchronisation incrémentielle inverse selon vos besoins. Si vous l'activez, définissez les valeurs RPS (nombre maximal de lignes de données pouvant être synchronisées vers la source par seconde lors de la synchronisation incrémentielle inverse) et BPS (volume maximal de données pouvant être synchronisé vers la source par seconde lors de la synchronisation incrémentielle inverse).
RemarqueLes paramètres RPS et BPS servent uniquement de limites de throttling. Les performances réelles de la synchronisation incrémentielle inverse dépendent de plusieurs facteurs, tels que la source, la destination et les spécifications de l'instance.
Incremental Synchronization Start Offset
Ce paramètre n'est pas affiché si vous sélectionnez Full Migration comme type de migration.
Si vous ne sélectionnez pas Full Migration mais que vous sélectionnez Incremental Synchronization, le décalage de départ est basé sur le basculement avant (le cas échéant) par défaut et ne peut pas être modifié.
-
Paramètres avancés
Cette section s'affiche uniquement si la cible est une base de données OceanBase version 4.3.0 ou ultérieure en mode compatible Oracle et que vous avez sélectionné Schema Migration sur la page Select Migration Type.

Les types de stockage pris en charge pour les objets tables cibles sont Default, Row storage, Column storage et Hybrid columnar storage. Pour plus d'informations, consultez default_table_store_format.
RemarqueLa valeur Default signifie que les autres paramètres sont automatiquement configurés en fonction des réglages de la cible. Les objets tables issus de la migration de schéma sont écrits dans les schémas correspondants selon le type de stockage spécifié.
-
-
Cliquez sur Precheck pour effectuer la prévérification de la tâche de migration de données.
À l'étape Precheck, Data Transmission Service vérifie si les éléments répondent aux exigences, telles que les autorisations de lecture et d'écriture de l'utilisateur de base de données et la connectivité réseau de la base de données. Vous ne pouvez démarrer la tâche de migration de données qu'une fois tous les contrôles réussis. En cas d'échec de la prévérification :
Identifiez et résolvez le problème, puis relancez la prévérification jusqu'à ce qu'elle aboutisse.
Vous pouvez également cliquer sur Skip dans la colonne Actions pour un élément de prévérification ayant échoué. Une boîte de dialogue apparaît pour décrire l'impact de cette opération. Pour continuer, cliquez sur OK.
-
Une fois la prévérification réussie, cliquez sur Start Task.
Si vous ne souhaitez pas démarrer la tâche immédiatement, cliquez sur Save. Vous pourrez ensuite démarrer la tâche manuellement depuis la page Data Migration Task List ou via des opérations par lot. Pour plus d'informations sur les opérations par lot, consultez Batch Operations on Data Migration Tasks.
Data Transmission Service vous permet de modifier les objets de migration et leurs conditions de filtrage de lignes pendant l'exécution d'une tâche de migration de données. Pour plus d'informations, consultez View and modify migration objects and their filter conditions. Une fois la tâche de migration de données démarrée, elle exécute les étapes de migration séquentiellement en fonction des types de migration sélectionnés. Pour plus d'informations, consultez View migration details.