Informations de référence sur l'outil de migration d'Oracle NoSQL Database

Découvrez les paramètres de modèle de configuration de source, de puits et de transformation disponibles pour Oracle NoSQL Database Migrator.

Cet article contient les rubriques suivantes :

Paramètres

NoSQL Database Migrator nécessite un fichier de configuration dans lequel vous définissez tous les paramètres pour effectuer l'activité de migration. Quelques paramètres sont communs à plusieurs sources et puits. Cette rubrique fournit une liste de ces paramètres communs. Pour obtenir la liste des autres paramètres uniques à des sources ou à des puits individuels, consultez les sections de modèle de configuration correspondantes.

Paramètres de configuration communs

Voici les paramètres de configuration courants. Voir les sections du modèle de configuration individuel pour des exemples.

bucket

taille de tranche de mémoire

credentials

credentialsProfile

Point d'extrémité

format

namespace

prefix

requestTimeoutMs

sécurité

type

useDelegationToken

useInstancePrincipal

useOKEWorkloadIdentity

Pour un exemple de cas d'utilisation, voir Migrer du service de stockage d'objets OCI vers Oracle NoSQL Database Cloud Service à l'aide de l'authentification OKE.

Note : Vous ne pouvez sélectionner qu'une seule des options d'authentification. Par conséquent, spécifiez un seul de ces paramètres : données d'identification, useInstancePrincipal, useDelegationToken, useSessionToken ou useOKEWorkloadIdentity dans le modèle de configuration.

useSessionToken

Pour utiliser l'authentification basée sur un jeton de session, vous devez générer un jeton de session à l'aide des commandes CLI (OCI Command Line Interface). Pour un exemple de cas d'utilisation, voir Migrer d'Oracle NoSQL Database vers le service de stockage d'objets pour OCI à l'aide de l'authentification par jeton de session.

Note :

Modèles de configuration de source

Découvrez les formats de fichier de configuration source pour chaque source valide et l'objectif de chaque paramètre de configuration.

Pour le modèle de fichier de configuration, voir Fichier de configuration dans Terminologie utilisée avec NoSQL Data Migrator.

Pour plus de détails sur les formats de puits valides pour chaque source, voir Modèles de configuration de puits.

Rubriques

Les rubriques suivantes décrivent les modèles de configuration source référencés par Oracle NoSQL Database Migrator pour copier les données de la source indiquée vers un récepteur valide.

Source du fichier JSON

Le format de fichier de configuration pour le fichier JSON en tant que source de NoSQL Database Migrator est indiqué ci-dessous.

Vous pouvez migrer un fichier source JSON en spécifiant le chemin d'accès au fichier ou un répertoire dans le modèle de configuration source.

Un exemple de fichier source JSON est le suivant :

{"id":6,"val_json":{"array":["q","r","s"],"date":"2023-02-04T02:38:
57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-03-04T02:38:57.520Z","numfield":30,"strfield":"foo54"},{"datefield":"2023-02-04T02:38:57.520Z","numfield":56,"strfield":"bar23"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}}
{"id":3,"val_json":{"array":["g","h","i"],"date":"2023-02-02T02:38:57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-02-02T02:38:57.520Z","numfield":28,"strfield":"foo3"},{"datefield":"2023-02-02T02:38:57.520Z","numfield":38,"strfield":"bar"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}}

Modèle de configuration source

"source": {
  "type": "file",
  "format": "json",
  "dataPath": "<path/to/JSON/[file|dir]>",
  "schemaInfo": {
    "schemaPath": "<path/to/schema/file>"
  }
},

Paramètres sources

Paramètres de configuration communs

Paramètres de configuration uniques

Chemin de données

schemaInfo

schemaInfo.schemaPath

Fichier JSON dans le seau de stockage d'objets OCI

Le format de fichier de configuration du fichier JSON dans le seau de stockage d'objets OCI en tant que source de NoSQL Database Migrator est indiqué ci-dessous.

Vous pouvez migrer un fichier JSON dans le seau de stockage d'objets OCI en spécifiant le nom du seau dans le modèle de configuration source.

Un exemple de fichier source JSON dans le seau de stockage d'objets OCI est le suivant :

{"id":6,"val_json":{"array":["q","r","s"],"date":"2023-02-04T02:38:57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-02-04T02:38:57.520Z","numfield":30,"strfield":"foo54"},{"datefield":"2023-02-04T02:38:57.520Z","numfield":56,"strfield":"bar23"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}}
{"id":3,"val_json":{"array":["g","h","i"],"date":"2023-02-04T02:38:57.520Z","nestarray":[[1,2,3],[10,20,30]],"nested":{"arrayofobjects":[{"datefield":"2023-02-04T02:38:57.520Z","numfield":28,"strfield":"foo3"},{"datefield":"2023-02-04T02:38:57.520Z","numfield":38,"strfield":"bar"}],"nestNum":10,"nestString":"bar"},"num":1,"string":"foo"}}

Note : Les types de récepteur valides pour le type de source du service de stockage d'objets OCI sont nosqldb et nosqldb_cloud.

Modèle de configuration source

"source" : {
  "type" : "object_storage_oci",
  "format" : "json",
  "endpoint" : "<OCI Object Storage service endpoint URL or region ID>",
  "namespace" : "<OCI Object Storage namespace>",
  "bucket" : "<bucket name>",
  "prefix" : "<object prefix>",
  "schemaInfo" : {
     "schemaObject" : "<object name>"
  },
  "credentials" : "</path/to/oci/config/file>",
  "credentialsProfile" : "<profile name in oci config file>",
  "useInstancePrincipal" : <true|false>,
  "useDelegationToken" : <true|false>,
  "useSessionToken" : <true|false>,
  "useOKEWorkloadIdentity" : <true|false>
}

Paramètres sources

Paramètres de configuration communs

Paramètres de configuration uniques

schemaInfo

schemaInfo.schemaObject

Fichier JSON formaté MongoDB

Le format de fichier de configuration pour le fichier JSON au format MongoDB en tant que source de NoSQL Database Migrator est indiqué ci-dessous.

Vous pouvez migrer des données JSON exportées par MongoDB en spécifiant le fichier ou le répertoire dans le modèle de configuration source.

MongoDB prend en charge deux types d'extension au format JSON des fichiers, Mode canonique et Mode assoupli. Vous pouvez fournir le fichier JSON au format MongoDB qui est généré à l'aide de l'outil mongoexport en mode Canonical ou Relaxed. Les deux modes sont pris en charge par NoSQL Database Migrator pour la migration.

Pour plus d'informations sur le fichier MongoDB Extended JSON (v2), voir mongoexport_formats.

Pour plus d'informations sur la génération du fichier JSON au format MongoDB, voir mongoexport pour plus d'informations.

Voici un exemple de fichier JSON de mode détendu au format MongoDB :

{"_id":0,"name":"Aimee Zank","scores":[{"score":
1.463179736705023,"type":"exam"},{"score":11.78273309957772,"type":"quiz"},{"score":35.8740349954354,"type":"homework"}]}
{"_id":1,"name":"Aurelia Menendez","scores":[{"score":60.06045071030959,"type":"exam"},{"score":52.79790691903873,"type":"quiz"},{"score":71.76133439165544,"type":"homework"}]}
{"_id":2,"name":"Corliss Zuk","scores":[{"score":67.03077096065002,"type":"exam"},{"score":6.301851677835235,"type":"quiz"},{"score":66.28344683278382,"type":"homework"}]}
{"_id":3,"name":"Bao Ziglar","scores":[{"score":71.64343899778332,"type":"exam"},{"score":24.80221293650313,"type":"quiz"},{"score":42.26147058804812,"type":"homework"}]}
{"_id":4,"name":"Zachary Langlais","scores":[{"score":78.68385091304332,"type":"exam"},{"score":90.2963101368042,"type":"quiz"},{"score":34.41620148042529,"type":"homework"}]}

Modèle de configuration source

"source": {
  "type": "file",
  "format": "mongodb_json",
  "dataPath": "</path/to/json/[file|dir]>",
  "schemaInfo": {
    "schemaPath": "</path/to/schema/file>"
  }
}

Paramètres sources

Paramètres de configuration communs

Paramètres de configuration uniques

Chemin de données

schemaInfo

schemaInfo.schemaPath

Fichier JSON au format MongoDB dans le seau de stockage d'objets OCI

Le format de fichier de configuration pour le fichier JSON formaté MongoDB dans le seau de stockage d'objets OCI en tant que source de NoSQL Database Migrator est indiqué ci-dessous.

Vous pouvez migrer les données JSON exportées par MongoDB dans le seau de stockage d'objets OCI en spécifiant le nom du seau dans le modèle de configuration source.

Extraire les données de MongoDB à l'aide de l'utilitaire mongoexport et les charger dans le seau de stockage d'objets OCI. Pour plus d'informations, voir mongoexport. MongoDB prend en charge deux types d'extension au format JSON des fichiers, Mode canonique et Mode assoupli. Les deux formats sont pris en charge dans le seau de stockage d'objets OCI.

Voici un exemple de fichier JSON de mode détendu au format MongoDB :

{"_id":0,"name":"Aimee Zank","scores":[{"score":1.463179736705023,"type":"exam"},{"score":11.78273309957772,"type":"quiz"},{"score":35.8740349954354,"type":"homework"}]}
{"_id":1,"name":"Aurelia Menendez","scores":[{"score":60.06045071030959,"type":"exam"},{"score":52.79790691903873,"type":"quiz"},{"score":71.76133439165544,"type":"homework"}]}
{"_id":2,"name":"Corliss Zuk","scores":[{"score":67.03077096065002,"type":"exam"},{"score":6.301851677835235,"type":"quiz"},{"score":66.28344683278382,"type":"homework"}]}
{"_id":3,"name":"Bao Ziglar","scores":[{"score":71.64343899778332,"type":"exam"},{"score":24.80221293650313,"type":"quiz"},{"score":42.26147058804812,"type":"homework"}]}
{"_id":4,"name":"Zachary Langlais","scores":[{"score":78.68385091304332,"type":"exam"},{"score":90.2963101368042,"type":"quiz"},{"score":34.41620148042529,"type":"homework"}]}

Note : Les types de récepteur valides pour le type de source du service de stockage d'objets OCI sont nosqldb et nosqldb_cloud.

Modèle de configuration source

"source" : {
  "type" : "object_storage_oci",
  "format" : "mongodb_json",
  "endpoint" : "<OCI Object Storage service endpoint URL or region ID>",
  "namespace" : "<OCI Object Storage namespace>",
  "bucket" : "<bucket name>",
  "prefix" : "<object prefix>",
  "schemaInfo" : {
     "schemaObject" : "<object name>"
  },
  "credentials" : "</path/to/oci/config/file>",
  "credentialsProfile" : "<profile name in oci config file>",
  "useInstancePrincipal" : <true|false>,
  "useDelegationToken" : <true|false>,
  "useSessionToken" : <true|false>,
  "useOKEWorkloadIdentity" : <true|false>
}

Paramètres sources

Paramètres de configuration communs

  1. "credentials" : "/home/user/.oci/config"

  2. "credentials" : "/home/user/security/config"

Paramètres de configuration uniques

schemaInfo

schemaInfo.schemaObject

Fichier JSON au format DynamoDB stocké dans AWS S3

Le format de fichier de configuration pour le fichier JSON au format DynamoDB dans AWS S3 en tant que source de NoSQL Database Migrator est indiqué ci-dessous.

Vous pouvez migrer un fichier contenant les données JSON exportées par DynamoDB à partir du stockage AWS S3 en spécifiant le chemin dans le modèle de configuration source.

Un exemple de fichier JSON au format DynamoDB est le suivant :

{"Item":{"Id":{"N":"101"},"Phones":{"L":[{"L":[{"S":"555-222"},{"S":"123-567"}]}]},"PremierCustomer":{"BOOL":false},"Address":{"M":{"Zip":{"N":"570004"},"Street":{"S":"21 main"},"DoorNum":{"N":"201"},"City":{"S":"London"}}},"FirstName":{"S":"Fred"},"FavNumbers":{"NS":["10"]},"LastName":{"S":"Smith"},"FavColors":{"SS":["Red","Green"]},"Age":{"N":"22"},"ttl": {"N": "1734616800"}}}
{"Item":{"Id":{"N":"102"},"Phones":{"L":[{"L":[{"S":"222-222"}]}]},"PremierCustomer":{"BOOL":false},"Address":{"M":{"Zip":{"N":"560014"},"Street":{"S":"32 main"},"DoorNum":{"N":"1024"},"City":{"S":"Wales"}}},"FirstName":{"S":"John"},"FavNumbers":{"NS":["10"]},"LastName":{"S":"White"},"FavColors":{"SS":["Blue"]},"Age":{"N":"48"},"ttl": {"N": "1734616800"}}}

Vous devez exporter la table DynamoDB vers le stockage AWS S3 comme indiqué dans Exportation des données de la table DynamoDB vers Amazon S3.

Les types d'évier valides pour DynamoDB-formatted JSON stockés dans AWS S3 sont nosqldb et nosqldb_cloud.

Modèle de configuration source

"source" : {
  "type" : "aws_s3",
  "format" : "dynamodb_json",
  "ttlAttributeName" : "<DynamoDB exported TTL attribute name>",
  "s3URL" : "<S3 object url>",
  "credentials" : "</path/to/aws/credentials/file>",
  "credentialsProfile" : "<profile name in aws credentials file>"
}

Paramètres sources

Paramètres de configuration communs

Paramètres de configuration uniques

s3URL

credentials

credentialsProfile

ttlAttributeName

Fichier JSON au format DynamoDB

Le format de fichier de configuration pour le fichier JSON au format DynamoDB en tant que source de NoSQL Database Migrator est indiqué ci-dessous.

Vous pouvez migrer un fichier ou un répertoire contenant les données JSON exportées DynamoDB à partir d'un système de fichiers en spécifiant le chemin dans le modèle de configuration source.

Un exemple de fichier JSON au format DynamoDB est le suivant :

{"Item":{"Id":{"N":"101"},"Phones":{"L":[{"L":[{"S":"555-222"},{"S":"123-567"}]}]},"PremierCustomer":{"BOOL":false},"Address":{"M":{"Zip":{"N":"570004"},"Street":{"S":"21 main"},"DoorNum":{"N":"201"},"City":{"S":"London"}}},"FirstName":{"S":"Fred"},"FavNumbers":{"NS":["10"]},"LastName":{"S":"Smith"},"FavColors":{"SS":["Red","Green"]},"Age":{"N":"22"},"ttl": {"N": "1734616800"}}}
{"Item":{"Id":{"N":"102"},"Phones":{"L":[{"L":[{"S":"222-222"}]}]},"PremierCustomer":{"BOOL":false},"Address":{"M":{"Zip":{"N":"560014"},"Street":{"S":"32 main"},"DoorNum":{"N":"1024"},"City":{"S":"Wales"}}},"FirstName":{"S":"John"},"FavNumbers":{"NS":["10"]},"LastName":{"S":"White"},"FavColors":{"SS":["Blue"]},"Age":{"N":"48"},"ttl": {"N": "1734616800"}}}

Vous devez copier les données de table DynamoDB exportées du stockage AWS S3 vers un système de fichiers monté local.

Les types d'évier valides pour le fichier JSON DynamoDB sont nosqldb et nosqldb_cloud.

Modèle de configuration source

"source" : {
  "type" : "file",
  "format" : "dynamodb_json",
  "ttlAttributeName" : <DynamoDB exported TTL attribute name>,
  "dataPath" : "<path/to/[file|dir]/containing/exported/DDB/tabledata>"
}

Paramètres sources

Paramètres de configuration communs

Paramètre de configuration unique

Chemin de données

ttlAttributeName

Oracle NoSQL Database

Le format de fichier de configuration d'Oracle NoSQL Database en tant que source de NoSQL Database Migrator est indiqué ci-dessous.

Vous pouvez migrer une table à partir d'Oracle NoSQL Database en spécifiant son nom dans le modèle de configuration source.

Voici un exemple de tableau Oracle NoSQL Database :

{"id":20,"firstName":"Jane","lastName":"Smith","otherNames":[{"first":"Jane","last":"teacher"}],"age":25,"income":55000,"address":{"city":"San Jose","number":201,"phones":[{"area":608,"kind":"work","number":6538955},{"area":931,"kind":"home","number":9533341},{"area":931,"kind":"mobile","number":9533382}],"state":"CA","street":"Atlantic Ave","zip":95005},"connections":[40,75,63],"expenses":null}
{"id":10,"firstName":"John","lastName":"Smith","otherNames":[{"first":"Johny","last":"chef"}],"age":22,"income":45000,"address":{"city":"Santa Cruz","number":101,"phones":[{"area":408,"kind":"work","number":4538955},{"area":831,"kind":"home","number":7533341},{"area":831,"kind":"mobile","number":7533382}],"state":"CA","street":"Pacific Ave","zip":95008},"connections":[30,55,43],"expenses":null}
{"id":30,"firstName":"Adam","lastName":"Smith","otherNames":[{"first":"Adam","last":"handyman"}],"age":45,"income":75000,"address":{"city":"Houston","number":301,"phones":[{"area":618,"kind":"work","number":6618955},{"area":951,"kind":"home","number":9613341},{"area":981,"kind":"mobile","number":9613382}],"state":"TX","street":"Indian Ave","zip":95075},"connections":[60,45,73],"expenses":null}

Modèle de configuration source

"source" : {
  "type": "nosqldb",
  "storeName" : "<store name>",
  "helperHosts" : ["hostname1:port1","hostname2:port2,..."],
  "table" : "<fully qualified table name>",
  "queryFilter" : "<query predicate>",
  "includeTTL": <true|false>,
  "security" : "</path/to/store/security/file>",
  "requestTimeoutMs" : 5000
}

Paramètres sources

Paramètre de configuration commun

Paramètres de configuration uniques

storeName

Hôtes d'assistance

table

includeTTL

filtre de requête

Expressions prises en charge :

L'utilitaire Migrator prend en charge les expressions suivantes dans le prédicat d'interrogation. Pour obtenir une syntaxe détaillée et des exemples, voir Guide de référence SQL.

Field step expressions
Map-filter step expressions
Array-filter step expressions
Array-slice step expressions
Arithmetic operators
Value comparison operators
Sequence comparison operators
Logical operators AND, OR and NOT
IS NULL and IS NOT NULL operators
IN operator
Regular expression
EXISTS operator
IS OF TYPE operator
CONCAT operator
CAST expression
Row functions

Le tableau suivant fournit des exemples de prédicats d'interrogation valides pour différentes expressions et les données exportées résultantes.

Note :

Table - Exemples de prédicats d'interrogation

Interrogation/prédicat Données exportées
"id=10" Rangées de la table indiquée avec l'ID = 10.
"name='John'" Rangées de la table indiquée avec le nom = 'John'.
" âge > 30 ans et sexe = homme " Rangées de la table indiquée avec age supérieur à 30 et gender = 'male'.
"$row.address.state = 'CA' Rangées de la table indiquée avec le champ state dans la colonne JSON address = 'CA'. Ici, vous utilisez une expression d'étape de champ dans le prédicat pour accéder à la valeur de champ obligatoire à partir d'un champ JSON.
"$row.expenses.keys($value > 1000) = 'food'" Rangées de la table indiquée où la catégorie expenses = 'aliment' et le montant expenses sont supérieurs à 1000. Ici, vous utilisez une expression d'étape de filtre de carte pour sélectionner les noms de champ (clés) ou les valeurs de champ des champs de mappage/d'enregistrement.
"$row.expenses.keys($value > $.clothes) = 'food'" Rangées de la table indiquée où la catégorie expenses = 'aliment' et le montant expenses sont supérieurs à ceux dépensés pour clothes.
"[$row.address.phones[$element.area = 650].kind] = 'work'" Rangées de la table indiquée où l'indicatif régional du téléphone dans le tableau = 650 et type = 'travail'. Ici, vous utilisez une expression d'étape de filtre de tableau car le champ address est un tableau JSON.
"[connexions[$element > 100 et $pos < 10]] > 100" Rangées de la table indiquée avec un maximum de 10 connexions et un nombre de connexions > 100. Ici, vous utilisez une expression d'étape de filtre de tableau car le champ connections est un tableau.
"$row. Income EST NULL" Rangées de la table indiquée qui n'ont pas de revenu connu. Pour plus de détails, voir Opérateurs IS NULL et IS NOT NULL.
"a in (1, 5, 4)" Rangées de la table indiquée où a est 1, 5 ou 4. Pour plus d'informations, voir Opérateur IN.
"a, b) au point (1, a), (5, g), (4, t))" Rangées de la table indiquée où (a est 1 et b est 'a') OU (a est 5 et b est 'g') OU (a est 4 et b est 't').
"regex_like(name, 'j.*')" Rangées de la table indiquée dont le nom commence par j. Pour plus d'informations, voir Expressions standard.
"EXISTE $row.person.address.zipcode" Rangées de la table indiquée où la colonne json person contient zipcode dans l'adresse. Pour plus d'informations, voir Opérateur Existe.
"$row.address est de type (chaîne)" Rangées de la table indiquée où la colonne address est de type chaîne. Pour plus de détails, voir Opérateur Is-Of-Type.
"lastLogin > CAST('2022-10-01' AS TIMESTAMP)" Rangées de la table indiquée avec la dernière connexion après le 1er octobre 2022. Pour plus d'informations, voir Expressions de flux.
"$row.connections[ ]=any 1" Rangées de la table indiquée dont la colonne de tableau connections contient l'élément 1. Pour plus de détails, voir Opérateurs de comparaison de séquences.
"modification_time($row) >= 2022-10-01'' Rangées de la table indiquée qui sont modifiées le 1er octobre 2022 ou après cette date. Pour plus de détails, voir Fonctions sur les rangées.
"expiration_time_millis($row) > 0" Rangées de la table indiquée qui ne sont pas expirées. Pour plus de détails, voir Fonctions sur les rangées.

Service Oracle NoSQL Database Cloud

Le format de fichier de configuration pour Oracle NoSQL Database Cloud Service en tant que source de NoSQL Database Migrator est indiqué ci-dessous.

Vous pouvez migrer une table à partir d'Oracle NoSQL Database Cloud Service en spécifiant le nom ou l'OCID du compartiment dans lequel réside la table dans le modèle de configuration source.

Voici un exemple de tableau pour Oracle NoSQL Database Cloud Service :

{"id":20,"firstName":"Jane","lastName":"Smith","otherNames":[{"first":"Jane","last":"teacher"}],"age":25,"income":55000,"address":{"city":"San Jose","number":201,"phones":[{"area":608,"kind":"work","number":6538955},{"area":931,"kind":"home","number":9533341},{"area":931,"kind":"mobile","number":9533382}],"state":"CA","street":"Atlantic Ave","zip":95005},"connections":[40,75,63],"expenses":null}
{"id":10,"firstName":"John","lastName":"Smith","otherNames":[{"first":"Johny","last":"chef"}],"age":22,"income":45000,"address":{"city":"Santa Cruz","number":101,"phones":[{"area":408,"kind":"work","number":4538955},{"area":831,"kind":"home","number":7533341},{"area":831,"kind":"mobile","number":7533382}],"state":"CA","street":"Pacific Ave","zip":95008},"connections":[30,55,43],"expenses":null}
{"id":30,"firstName":"Adam","lastName":"Smith","otherNames":[{"first":"Adam","last":"handyman"}],"age":45,"income":75000,"address":{"city":"Houston","number":301,"phones":[{"area":618,"kind":"work","number":6618955},{"area":951,"kind":"home","number":9613341},{"area":981,"kind":"mobile","number":9613382}],"state":"TX","street":"Indian Ave","zip":95075},"connections":[60,45,73],"expenses":null}

Modèle de configuration source

"source" : {
  "type" : "nosqldb_cloud",
  "endpoint" : "<Oracle NoSQL Cloud Service endpoint URL or region ID>",
  "table" : "<table name>",
  "queryFilter" : "<query predicate>",
  "compartment" : "<OCI compartment name or id>",
  "credentials" : "<path/to/oci/credential/file>",
  "credentialsProfile" : "<profile name in oci config file>",
  "useInstancePrincipal" : <true|false>,
  "useDelegationToken" : <true|false>,
  "useSessionToken" : <true|false>,
  "useOKEWorkloadIdentity" : <true|false>,
  "readUnitsPercent" : <table readunits percent>,
  "includeTTL": <true|false>,
  "requestTimeoutMs" : <timeout in milli seconds>
}

Paramètres sources

Paramètres de configuration communs

Paramètres de configuration uniques

table

compartiment

Note : Si le paramètre useInstancePrincipal est réglé à Vrai, le compartiment doit spécifier l'OCID du compartiment et non son nom.

readUnitsPercent

includeTTL

filtre de requête

Expressions prises en charge :

L'utilitaire Migrator prend en charge les expressions suivantes dans le prédicat d'interrogation. Pour obtenir une syntaxe détaillée et des exemples, voir Guide de référence SQL.

Field step expressions
Map-filter step expressions
Array-filter step expressions
Array-slice step expressions
Arithmetic operators
Value comparison operators
Sequence comparison operators
Logical operators AND, OR and NOT
IS NULL and IS NOT NULL operators
IN operator
Regular expression
EXISTS operator
IS OF TYPE operator
CONCAT operator
CAST expression
Row functions

Le tableau suivant fournit des exemples de prédicats d'interrogation valides pour différentes expressions et les données exportées résultantes.

Note :

Table - Exemples de prédicats d'interrogation

Interrogation/prédicat Données exportées
"id=10" Rangées de la table indiquée avec l'ID = 10.
"name='John'" Rangées de la table indiquée avec le nom = 'John'.
" âge > 30 ans et sexe = homme " Rangées de la table indiquée avec age supérieur à 30 et gender = 'male'.
"$row.address.state = 'CA' Rangées de la table indiquée avec le champ state dans la colonne JSON address = 'CA'. Ici, vous utilisez une expression d'étape de champ dans le prédicat pour accéder à la valeur de champ obligatoire à partir d'un champ JSON.
"$row.expenses.keys($value > 1000) = 'food'" Rangées de la table indiquée où la catégorie expenses = 'aliment' et le montant expenses sont supérieurs à 1000. Ici, vous utilisez une expression d'étape de filtre de carte pour sélectionner les noms de champ (clés) ou les valeurs de champ des champs de mappage/d'enregistrement.
"$row.expenses.keys($value > $.clothes) = 'food'" Rangées de la table indiquée où la catégorie expenses = 'aliment' et le montant expenses sont supérieurs à ceux dépensés pour clothes.
"[$row.address.phones[$element.area = 650].kind] = 'work'" Rangées de la table indiquée où l'indicatif régional du téléphone dans le tableau = 650 et type = 'travail'. Ici, vous utilisez une expression d'étape de filtre de tableau car le champ address est un tableau JSON.
"[connexions[$element > 100 et $pos < 10]] > 100" Rangées de la table indiquée avec un maximum de 10 connexions et un nombre de connexions > 100. Ici, vous utilisez une expression d'étape de filtre de tableau car le champ connections est un tableau.
"$row. Income EST NULL" Rangées de la table indiquée qui n'ont pas de revenu connu. Pour plus de détails, voir Opérateurs IS NULL et IS NOT NULL.
"a in (1, 5, 4)" Rangées de la table indiquée où a est 1, 5 ou 4. Pour plus d'informations, voir Opérateur IN.
"a, b) au point (1, a), (5, g), (4, t))" Rangées de la table indiquée où (a est 1 et b est 'a') OU (a est 5 et b est 'g') OU (a est 4 et b est 't').
"regex_like(name, 'j.*')" Rangées de la table indiquée dont le nom commence par j. Pour plus d'informations, voir Expressions standard.
"EXISTE $row.person.address.zipcode" Rangées de la table indiquée où la colonne json person contient zipcode dans l'adresse. Pour plus d'informations, voir Opérateur Existe.
"$row.address est de type (chaîne)" Rangées de la table indiquée où la colonne address est de type chaîne. Pour plus de détails, voir Opérateur Is-Of-Type.
"lastLogin > CAST('2022-10-01' AS TIMESTAMP)" Rangées de la table indiquée avec la dernière connexion après le 1er octobre 2022. Pour plus d'informations, voir Expressions de flux.
"$row.connections[ ]=any 1" Rangées de la table indiquée dont la colonne de tableau connections contient l'élément 1. Pour plus de détails, voir Opérateurs de comparaison de séquences.
"modification_time($row) >= 2022-10-01'' Rangées de la table indiquée qui sont modifiées le 1er octobre 2022 ou après cette date. Pour plus de détails, voir Fonctions sur les rangées.
"expiration_time_millis($row) > 0" Rangées de la table indiquée qui ne sont pas expirées. Pour plus de détails, voir Fonctions sur les rangées.

Source du fichier CSV

Le format du fichier de configuration pour le fichier CSV en tant que source de NoSQL Database Migrator est indiqué ci-dessous. Le fichier CSV doit être conforme au format RFC4180.

Vous pouvez migrer un fichier CSV ou un répertoire contenant les données CSV en spécifiant le nom ou le répertoire du fichier dans le modèle de configuration source.

Voici un exemple de fichier CSV :

1,"Computer Science","San Francisco","2500"
2,"Bio-Technology","Los Angeles","1200"
3,"Journalism","Las Vegas","1500"
4,"Telecommunication","San Francisco","2500"

Modèle de configuration source

"source" : {
  "type" : "file",
  "format" : "csv",
  "dataPath": "</path/to/a/csv/[file|dir]>",
  "hasHeader" : <true | false>,
  "columns" : ["column1", "column2", ....],
  "csvOptions": {
    "encoding": "<character set encoding>",
    "trim": "<true | false>"
 }
}

Paramètres sources

Paramètres de configuration communs

Paramètres de configuration uniques

Chemin de données

Note : Les fichiers CSV ne doivent contenir que des valeurs scalaires. L'importation de fichiers CSV contenant des types complexes tels que MAP, RECORD, ARRAY et JSON n'est pas prise en charge. L'outil NoSQL Database Migrator ne vérifie pas l'exactitude des données dans le fichier CSV d'entrée. L'outil NoSQL Database Migrator prend en charge l'importation de données CSV conformes au format RFC4180. Les fichiers CSV contenant des données non conformes à la norme RFC4180 risquent de ne pas être copiés correctement ou d'entraîner une erreur. Si les données d'entrée sont corrompues, l'outil NoSQL Database Migrator n'analyse pas les enregistrements CSV. Si des erreurs se produisent lors de la migration, l'outil NoSQL Database Migrator enregistre les informations sur les enregistrements d'entrée en échec à des fins de débogage et d'information. Pour plus de détails, voir Progression de l'outil de migration de journalisation dans Utilisation d'Oracle NoSQL Data Migrator.

hasHeader

colonnes

csvOptions

csvOptions.encoding

csvOptions.trim

Fichier CSV dans le seau de stockage d'objets OCI

Le format de fichier de configuration du fichier CSV dans le seau de stockage d'objets OCI en tant que source de NoSQL Database Migrator est indiqué ci-dessous. Le fichier CSV doit être conforme au format RFC4180.

Vous pouvez migrer un fichier CSV dans le seau de stockage d'objets OCI en spécifiant le nom du seau dans le modèle de configuration source.

Voici un exemple de fichier CSV dans le seau de stockage d'objets OCI :

1,"Computer Science","San Francisco","2500"
2,"Bio-Technology","Los Angeles","1200"
3,"Journalism","Las Vegas","1500"
4,"Telecommunication","San Francisco","2500"

Note : Les types de récepteur valides pour le type de source du service de stockage d'objets OCI sont nosqldb et nosqldb_cloud.

Modèle de configuration source

"source" : {
  "type" : "object_storage_oci",
  "format" : "csv",
  "endpoint" : "<OCI Object Storage service endpoint URL or region ID>",
  "namespace" : "<OCI Object Storage namespace>",
  "bucket" : "<bucket name>",
  "prefix" : "<object prefix>",
  "credentials" : "</path/to/oci/config/file>",
  "credentialsProfile" : "<profile name in oci config file>",
  "useInstancePrincipal" : <true|false>,
  "useDelegationToken" : <true|false>,
  "useSessionToken" : <true|false>,
  "useOKEWorkloadIdentity" : <true|false>,
   "hasHeader" : <true | false>,
   "columns" : ["column1", "column2", ....],
   "csvOptions" : {
     "encoding" : "<character set encoding>",
     "trim" : <true | false>
   }
 }

Paramètres sources

Paramètres de configuration communs

Paramètres de configuration uniques

hasHeader

colonnes

csvOptions

csvOptions.encoding

csvOptions.trim

Modèles de configuration de récepteur

Découvrez les formats de fichier de configuration de l'évier pour chaque évier valide et l'objectif de chaque paramètre de configuration.

Pour le modèle de fichier de configuration, voir Fichier de configuration dans Terminologie utilisée avec NoSQL Data Migrator.

Pour plus de détails sur les formats sources valides pour chacun des puits, voir Modèles de configuration de la source.

Rubriques

Les rubriques suivantes décrivent les modèles de configuration de puits référencés par Oracle NoSQL Database Migrator pour copier les données d'une source valide vers le puits indiqué.

Lavabo de fichier JSON

Le format de fichier de configuration pour le fichier JSON en tant que récepteur de NoSQL Database Migrator est indiqué ci-dessous.

Modèle de configuration de l'évier

"sink" : {
  "type" : "file",
  "format" : "json",
  "dataPath": "</path/to/a/directory>",
  "schemaPath" : "<path/to/a/file>",
  "pretty" : <true|false>,
  "useMultiFiles" : <true|false>,
  "chunkSize" : <size in MB>
}

Paramètres du puits

Paramètres de configuration communs

Paramètres de configuration uniques

Chemin de données

schemaPath

jolie

useMultiFiles

Fichier Parquet

Le format de fichier de configuration pour Parquet File en tant que récepteur de NoSQL Database Migrator est indiqué ci-dessous.

Modèle de configuration de l'évier

"sink" : {
  "type" : "file",
  "format" : "parquet",
  "dataPath": "</path/to/a/dir>",
  "chunkSize" : <size in MB>,
  "compression": "<SNAPPY|GZIP|NONE>",
  "parquetOptions": {
    "useLogicalJson": <true|false>,
    "useLogicalEnum": <true|false>,
    "useLogicalUUID": <true|false>,
    "truncateDoubleSpecials": <true|false>
  }
}

Paramètres du puits

Paramètres de configuration communs

Paramètres de configuration uniques

Chemin de données

compression

parquetOptions

parquetOptions.useLogicalJson

parquetOptions.useLogicalEnum

parquetOptions.useLogicalUUID

parquetOptions.truncateDoubleSpecials

Fichier JSON dans le seau de stockage d'objets OCI

Le format de fichier de configuration pour le fichier JSON dans le seau de stockage d'objets OCI en tant que récepteur de l'outil de migration de base de données NoSQL est indiqué ci-dessous.

Note : Les types de source valides pour le service de stockage d'objets OCI en tant que récepteur sont nosqldb et nosqldb_cloud.

Modèle de configuration de l'évier

"sink" : {
  "type" : "object_storage_oci",
  "format" : "json",
  "endpoint" : "<OCI Object Storage service endpoint URL or region ID>",
  "namespace" : "<OCI Object Storage namespace>",
  "bucket" : "<bucket name>",
  "prefix" : "<object prefix>",
  "chunkSize" : <size in MB>,
  "pretty" : <true|false>,
  "credentials" : "</path/to/oci/config/file>",
  "credentialsProfile" : "<profile name in oci config file>",
  "useInstancePrincipal" : <true|false>,
  "useDelegationToken" : <true|false>,
  "useSessionToken" : <true|false>,
  "useOKEWorkloadIdentity" : <true|false>
}

Paramètres du puits

Paramètres de configuration communs

Paramètre de configuration unique

jolie

Fichier Parquet dans le seau de stockage d'objets OCI

Le format de fichier de configuration pour le fichier Parquet dans le seau du service de stockage d'objets pour OCI en tant que dissipateur de l'outil de migration de base de données NoSQL est indiqué ci-dessous.

Note : Les types de source valides pour le type de source du service de stockage d'objets OCI sont nosqldb et nosqldb_cloud.

Modèle de configuration de l'évier

"sink" : {
  "type" : "object_storage_oci",
  "format" : "parquet",
  "endpoint" : "<OCI Object Storage service endpoint URL or region ID>",
  "namespace" : "<OCI Object Storage namespace>",
  "bucket" : "<bucket name>",
  "prefix" : "<object prefix>",
  "chunkSize" : <size in MB>,
  "compression": "<SNAPPY|GZIP|NONE>",
  "parquetOptions": {
    "useLogicalJson": <true|false>,
    "useLogicalEnum": <true|false>,
    "useLogicalUUID": <true|false>,
    "truncateDoubleSpecials": <true|false>
  },
  "credentials" : "</path/to/oci/config/file>",
  "credentialsProfile" : "<profile name in oci config file>",
  "useInstancePrincipal" : <true|false>,
  "useDelegationToken" : <true|false>,
  "useSessionToken" : <true|false>,
  "useOKEWorkloadIdentity" : <true|false>
}

Paramètres du puits

Paramètres de configuration communs

Paramètre de configuration unique

compression

parquetOptions

parquetOptions.useLogicalJson

parquetOptions.useLogicalEnum

parquetOptions.useLogicalUUID

parquetOptions.truncateDoubleSpecials

Oracle NoSQL Database

Le format de fichier de configuration d'Oracle NoSQL Database en tant que récepteur de NoSQL Database Migrator est indiqué ci-dessous.

Modèle de configuration de l'évier

"sink" : {
  "type": "nosqldb",
  "storeName" : "<store name>",
  "helperHosts" : ["hostname1:port1","hostname2:port2,..."],
  "security" : "</path/to/store/credentials/file>",
  "table" : "<fully qualified table name>",
  "includeTTL": <true|false>,
  "ttlRelativeDate": "<date-to-use in UTC>",
  "schemaInfo" : {
    "schemaPath" : "</path/to/a/schema/file>",
    "defaultSchema" : <true|false>,
    "useSourceSchema" : <true|false>,
    "DDBPartitionKey" : <"name:type">,
    "DDBSortKey" : "<name:type>"
  },
  "overwrite" : <true|false>,
  "requestTimeoutMs" : <timeout in milli seconds>
}

Paramètres du puits

Paramètre de configuration commun

Paramètre de configuration unique

storeName

Hôtes d'assistance

table

includeTTL

ttlRelativeDate

schemainfo

schemaInfo.schemaPath

schemaInfo.defaultSchema

schemaInfo.useSourceSchema

schemaInfo.DDBPartitionKey

schemaInfo.DDBSortKey

remplacer

Service Oracle NoSQL Database Cloud

Le format de fichier de configuration pour Oracle NoSQL Database Cloud Service en tant que récepteur de NoSQL Database Migrator est indiqué ci-dessous.

Modèle de configuration de l'évier

"sink" : {
  "type" : "nosqldb_cloud",
  "endpoint" : "<Oracle NoSQL Cloud Service Endpoint>",
  "table" : "<table name>",
  "compartment" : "<OCI compartment name or id>",
  "includeTTL": <true|false>,
  "ttlRelativeDate" : "<date-to-use in UTC>",
  "schemaInfo" : {
    "schemaPath" : "</path/to/a/schema/file>",
    "defaultSchema" : <true|false>,
    "useSourceSchema" : <true|false>,
    "DDBPartitionKey" : <"name:type">,
    "DDBSortKey" : "<name:type>",
    "onDemandThroughput" : <true|false>,
    "readUnits" : <table read units>,
    "writeUnits" : <table write units>,
    "storageSize" : <storage size in GB>
   },
  "credentials" : "</path/to/oci/credential/file>",
  "credentialsProfile" : "<profile name in oci config file>",
  "useInstancePrincipal" : <true|false>,
  "useDelegationToken" : <true|false>,
  "useSessionToken" : <true|false>,
  "useOKEWorkloadIdentity" : <true|false>,
  "writeUnitsPercent" : <table writeunits percent>,
  "requestTimeoutMs" : <timeout in milli seconds>,
  "overwrite" : <true|false>
}

Paramètres du puits

Paramètres de configuration communs

Paramètre de configuration unique


table


compartiment


includeTTL


ttlRelativeDate


schemaInfo


schemaInfo.schemaPath

Note : defaultSchema et schemaPath s'excluent mutuellement.


schemaInfo.defaultSchema


schemaInfo.useSourceSchema


schemaInfo.DDBPartitionKey


schemaInfo.DDBSortKey


débit schemaInfo.onDemandThroughput

Note : Ce paramètre ne s'applique pas aux tables enfants car elles partagent le débit de la table parent de niveau supérieur.


schemaInfo.readUnits


schemaInfo.writeUnits


schemaInfo.storageSize


writeUnitsPercent


remplacer

Modèles de configuration de transformation

Cette rubrique décrit les paramètres de configuration des différentes transformations prises en charge par Oracle NoSQL Database Migrator. Pour obtenir le modèle de fichier de configuration complet, voir Fichier de configuration dans Terminologie utilisée avec NoSQL Data Migrator.

Oracle NoSQL Database Migrator vous permet de modifier les données, c'est-à-dire d'ajouter des transformations de données dans le cadre de l'activité de migration. Vous pouvez définir plusieurs transformations en une seule migration. Dans un tel cas, l'ordre des transformations est vital car les données sources subissent chaque transformation dans l'ordre donné. La sortie d'une transformation devient l'entrée de la suivante dans le pipeline de migration.

Les différentes transformations prises en charge par NoSQL Data Migrator sont les suivantes :

Table - Transformations

Attribut de configuration de transformation Vous pouvez utiliser cette transformation pour...
ignoreFields Ignorez les colonnes identifiées de la ligne source avant d'écrire dans le puits.
includeFields Incluez les colonnes identifiées de la rangée source avant d'écrire dans le puits.
renameFields Renommez les colonnes identifiées à partir de la ligne source avant d'écrire dans le puits.
aggregateFields Agréger plusieurs colonnes de la source en une seule colonne dans le puits. Dans le cadre de cette transformation, vous pouvez également identifier les colonnes à exclure dans l'agrégation. Ces champs seront ignorés de la colonne agrégée.

Vous trouverez ci-dessous le modèle de configuration pour chaque transformation prise en charge.

ignoreFields

Le format du fichier de configuration pour la transformation ignoreFields est indiqué ci-dessous.

Modèle de configuration de transformation

"transforms" : {
  "ignoreFields" : ["<field1>","<field2>",...]
}

Paramètre de transformation

ignoreFields

Inclure les champs

Le format du fichier de configuration pour la transformation includeFields est indiqué ci-dessous.

Modèle de configuration de transformation

"transforms" : {
  "includeFields" : ["<field1>","<field2>",...]
}

Paramètre de transformation

Inclure les champs

renameFields

Le format du fichier de configuration pour la transformation renameFields est indiqué ci-dessous.

Modèle de configuration de transformation

"transforms" : {
  "renameFields" : {
    "<old_name>" : "<new_name>",
    "<old_name>" : "<new_name>,"
    .....
  }
}

Paramètre de transformation

renameFields

champs d'agrégation

Le format du fichier de configuration pour la transformation aggregateFields est indiqué ci-dessous.

Modèle de configuration de transformation

"transforms" : {
  "aggregateFields" : {
    "fieldName" : "name of the new aggregate field",
    "skipFields" : ["<field1>","<field2">,...]
  }
}

Paramètre de transformation

champs d'agrégation

Mappage de types DynamoDB à des types NoSQL Oracle

Le tableau ci-dessous présente le mappage des types DynamoDB aux types NoSQL Oracle.

Tableau - Mappage du type DynamoDB au type NoSQL Oracle

# Type DynamoDB Type JSON pour colonne NoSQL JSON Type Oracle NoSQL
1 Chaîne (S) Chaîne JSON STRING
2 Type de nombre (N) Numéro JSON ENTIER/LONGUE/PLATEAU/DOUBLE/NOMBRE
3 Booléen (BOOL) Booléen JSON BOOLEAN
4 Type binaire (B) - Tampon octet Chaîne JSON encodée en BASE-64 BINARY
5 NULL JSON nul NULL
6 Jeu de chaînes (SS) Tableau JSON de chaînes TABLEAU (CHAÎNE)
7 Jeu de numéros (NS) Tableau de nombres JSON TABLEAU (ENTIER/LONG/FLOT/DOUBLE/NOMBRE)
8 Jeu binaire (BS) Tableau JSON de chaînes encodées en base-64 TABLEAU (BINAIRE)
9 LISTE (L) Tableau de JSON TABLEAU (JSON)
10 CARTE (M) Objet JSON JSON
11 CLÉ DE PARTITIONNEMENT S.O. CLÉ PRIMAIRE ET CLÉ FIXE
12 CLÉ DE TRI S.O. CLÉ PRIMAIRE
13 Noms d'attribut avec tiret et point Noms de champ JSON avec trait de soulignement Noms de colonne avec trait de soulignement

Quelques points supplémentaires à prendre en compte lors du mappage des types DynamoDB aux types NoSQL Oracle :

Mappage des types de données Oracle NoSQL et Parquet

Décrit le mappage des types de données NoSQL Oracle aux types de données Parquet.

Type NoSQL Type de parquet
BOOLEAN BOOLEAN
INTEGER INT32
LONG INT64
FLOAT DOUBLE
DOUBLE DOUBLE
BINARY BINARY
FIX_BINAIRE BINARY
STRING BINAIRE (CHAÎNE)
ENUM BINAIRE (CHAÎNE)

ou

BINARY(ENUM), si ENUM logique est configuré
UUID BINAIRE (CHAÎNE)

ou

FIXED_BINARY(16), si l'UUID logique est configuré
TIMESTAMP(p) INT64(TIMESTAMP(p))
NUMBER DOUBLE
field_name ARRAY(T) 
group field_name(LIST) { repeated group list { required T element } }
field_name MAP(T) 
group field_name (MAP) { repeated group key_value (MAP_KEY_VALUE) { required binary key (STRING); required T value; } }
field_name RECORD(K1 T1 N1, Kٖ2 T2 N2, ....)

Où :

K = nom de clé

T = Type

N = Pouvant être nul ou non

 
group field_name { ni == true ? optional Ti ki : required Ti ki  }
JSON BINAIRE (CHAÎNE)

ou

BINARY(JSON), si JSON logique est configuré

Note : Lorsque le type Numéro NoSQL est converti en type Parquet double, il peut y avoir une certaine perte de précision au cas où la valeur ne peut pas être représentée en type Double. Si le nombre est trop grand pour représenter Double, il est converti en Double.NEGATIVE_INFINITY ou Double.POSITIVE_INFINITY.

Mappage d'une table DynamoDB à une table Oracle NoSQL

Dans DynamoDB, une table est une collection d'éléments, et chaque élément est une collection d'attributs. Chaque élément de la table a un identificateur unique ou une clé primaire. En dehors de la clé primaire, la table est sans schéma. Chaque élément peut avoir ses propres attributs distincts.

DynamoDB prend en charge deux types de clés primaires différents :

En revanche, les tables Oracle NoSQL prennent en charge les modèles de données flexibles avec des schémas et une conception sans schéma.

Il existe deux façons différentes de modéliser une table DynamoDB :

  1. Modélisation d'une table DynamoDB en tant que document JSON (recommandé) : Dans cette modélisation, vous mappez tous les attributs des tables Dynamo DB dans une colonne JSON de la table NoSQL, à l'exception de la clé de partition et de la clé de tri. Vous modéliserez la clé de partition et la clé de tri en tant que colonnes de clé primaire de la table NoSQL. Vous utiliserez la transformation AggregateFields pour agréger les données de clé non principale dans une colonne JSON.

    Note : Migrator fournit une configuration conviviale defaultSchema pour créer automatiquement une table LDD sans schéma qui agrège également les attributs dans une colonne JSON.

  2. Modélisation d'une table DynamoDB en tant que colonnes fixes dans une table NoSQL : Dans cette modélisation, pour chaque attribut de la table DynamoDB, vous allez créer une colonne dans la table NoSQL comme spécifié dans Mappage des types DynamoDB aux types NoSQL Oracle. Vous modéliserez la clé de partition et trierez les attributs de clé en tant que clé(s) principale(s). Cette option ne doit être utilisée que lorsque vous êtes certain que l'importation du schéma de table DynamoDB est fixe et que chaque élément a des valeurs pour la plupart des attributs. Si les éléments DynamoDB n'ont pas d'attributs communs, cela peut entraîner un lot de colonnes NoSQL avec des valeurs vides.

    Note : Nous vous recommandons fortement d'utiliser des tables sans schéma lors de la migration des données de DynamoDB vers Oracle NoSQL Database en raison de la nature des tables DynamoDB sans schéma. Cela est particulièrement vrai pour les tables volumineuses où le contenu de chaque enregistrement peut ne pas être uniforme sur l'ensemble de la table.

Dépannage d'Oracle NoSQL Database Migrator

Découvrez les défis généraux auxquels vous pouvez faire face lors de l'utilisation du , et comment les résoudre.

La migration a échoué. Comment résoudre ce problème?

Une défaillance de la migration des données peut être due à plusieurs raisons sous-jacentes. Les causes importantes sont énumérées ci-dessous :

Table - Causes d'échec de migration

Message d'erreur Signification Résolution
Failed to connect to Oracle NoSQL Database L'outil de migration n'a pas pu établir de connexion à la base de données NoSQL.
  • Vérifiez si les valeurs des attributs storeName et helperHosts dans le fichier JSON de configuration sont valides et si les hôtes sont accessibles.
  • Pour un magasin sécurisé, vérifiez si le fichier de sécurité est valide avec des valeurs de nom d'utilisateur et de mot de passe correctes.
Failed to connect to Oracle NoSQL Database Cloud Service L'outil de migration n'a pas pu établir de connexion avec Oracle NoSQL Database Cloud Service.
  • Vérifiez si l'URL du point d'extrémité ou le nom de région indiqué dans le fichier JSON de configuration est correct.
  • Vérifiez si le fichier de données d'identification OCI est disponible dans le chemin indiqué dans le fichier JSON de configuration.
  • Assurez-vous que les données d'identification OCI fournies dans les données d'identification OCI sont valides.
Table not found La table identifiée pour la migration n'a pas pu être localisée par NoSQL Database Migrator.

Pour la source :

  • Vérifiez si la table est présente dans la base de données source.
  • Assurez-vous que la table est qualifiée avec son espace de noms dans le fichier JSON de configuration, si la table est créée dans un espace de noms autre que celui par défaut.
  • Vérifiez si vous disposez de l'autorisation de lecture/écriture requise pour accéder à la table.
  • Si la source est Oracle NoSQL Database Cloud Service, vérifiez si le nom de compartiment valide est spécifié dans le fichier JSON de configuration et assurez-vous de disposer de l'autorisation requise pour accéder à la table.

Pour l'évier :

  • Vérifiez si la table est présente dans le puits. S'il n'existe pas, vous devez créer la table manuellement ou utiliser la configuration schemaInfo pour la créer au moyen de la migration.
DDL Execution failed Les commandes LDD fournies dans le fichier de définition de schéma d'entrée ne sont pas valides.
  • Vérifiez la syntaxe des commandes LDD dans le fichier schemaPath.
  • Assurez-vous qu'il n'y a qu'un seul énoncé LDD par ligne dans le fichier schemaPath.
failed to write record to the sink table with java.lang.IllegalArgumentException L'enregistrement d'entrée ne correspond pas au schéma de table du puits.
  • Vérifiez si les types de données et les noms de colonne spécifiés dans la table de puits cible correspondent au schéma de la table de puits.
  • Si vous avez appliqué une transformation, vérifiez si les enregistrements transformés correspondent au schéma de la table de puits.
Request timeout L'opération de la source ou de l'évier ne s'est pas terminée dans le délai prévu.
  • Vérifiez la connexion réseau.
  • Vérifiez si le service Base de données NoSQL est opérationnel.
  • Essayez d'augmenter la valeur requestTimeout dans le fichier JSON de configuration.

Que dois-je considérer avant de redémarrer une migration en échec?

Lorsqu'une tâche de migration de données échoue, le puits est à un état intermédiaire contenant les données importées jusqu'au point d'échec. Vous pouvez identifier les détails de l'erreur et de l'échec à partir des journaux et redémarrer la migration après avoir diagnostiqué et corrigé l'erreur. Une migration redémarrée redémarre et traite toutes les données depuis le début. Il n'y a aucun moyen de vérifier et de redémarrer la migration à partir du point d'échec. Par conséquent, NoSQL Database Migrator remplace tout enregistrement qui a déjà été migré vers le puits.

Meilleures pratiques

Le temps nécessaire à la migration des données dépend de plusieurs facteurs tels que le volume des données migrées, la vitesse du réseau et la charge courante sur la base de données. Dans le cas d'un service en nuage, la vitesse de migration dépend également du débit de lecture et du débit d'écriture provisionnés. Ainsi, pour améliorer la vitesse de migration, vous pouvez :

L'utilitaire Migrator est intrinsèquement conçu pour augmenter la vitesse de migration en traitant plusieurs flux en parallèle. Les points suivants suggèrent comment tirer parti de cette capacité pour divers scénarios de migration :

J'ai une migration de longue durée impliquant d'énormes jeux de données. Comment suivre la progression de la migration?

Vous pouvez activer la journalisation supplémentaire pour suivre la progression d'une migration de longue durée. Pour contrôler le comportement de journalisation d'Oracle NoSQL Database Migrator, vous devez définir le niveau de journalisation souhaité dans le fichier logging.properties. Ce fichier est fourni avec l'ensemble NoSQL Database Migrator et disponible dans le répertoire dans lequel Oracle NoSQL Database Migrator a été décompressé. Les différents niveaux de journalisation dans l'ordre d'augmentation de la verbosité sont OFF, SEVERE, WARNING, INFO, FINE, et ALL.

Le réglage du niveau de journal à OFF désactive toutes les informations de journalisation, tandis que le réglage du niveau de journal à ALL fournit les informations de journal complètes.

Le niveau de journal par défaut est WARNING. Toutes les sorties de journalisation sont configurées pour accéder à la console par défaut.

Vous pouvez voir des commentaires dans le fichier logging.properties pour connaître chaque niveau de journal.