Référence Oracle NoSQL Database Migrator

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

Cet article comprend les rubriques suivantes :

Paramètres

NoSQL Database Migrator requiert 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 la liste de ces paramètres communs. Pour obtenir la liste des autres paramètres propres à des sources ou des puits individuels, reportez-vous aux sections correspondantes du modèle de configuration.

Paramètres de configuration communs

Les paramètres de configuration communs sont les suivants. Consultez les sections des modèles de configuration individuels pour obtenir des exemples.

bucket

chunkSize

My Oracle Support

credentialsProfile

endpoint

format

espace de noms

préfixe

requestTimeoutMs

sécurité,

type

useDelegationToken

useInstancePrincipal

useOKEWorkloadIdentity

Pour obtenir un exemple de cas d'utilisation, reportez-vous à Migration d'OCI Object Storage vers Oracle NoSQL Database Cloud Service à l'aide de l'authentification OKE.

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

jeton de session

Pour utiliser l'authentification basée sur un jeton de session, vous devez générer un jeton de session à l'aide des commandes de l'interface de ligne de commande OCI. Pour obtenir un exemple de cas d'utilisation, reportez-vous à Migration d'Oracle NoSQL Database vers OCI Object Storage à l'aide de l'authentification par jeton de session.

Remarque :

Modèles de configuration 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, reportez-vous à Fichier de configuration dans Terminologie utilisée avec NoSQL Data Migrator.

Pour plus d'informations sur les formats de récepteur valides pour chaque source, reportez-vous à la section Sink Configuration Templates.

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 donnée vers un récepteur valide.

Source de fichier JSON

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

Vous pouvez migrer un fichier source JSON en indiquant le chemin du 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 d'origine

Paramètres de configuration communs

Paramètres de configuration uniques

dataPath

schemaInfo

chemaInfo.schemaPath

Fichier JSON dans le bucket OCI Object Storage

Le format du fichier de configuration pour le fichier JSON dans le bucket OCI Object Storage en tant que source de NoSQL Database Migrator est indiqué ci-dessous.

Vous pouvez migrer un fichier JSON dans le bucket OCI Object Storage en indiquant le nom du bucket dans le modèle de configuration source.

Un exemple de fichier source JSON dans le bucket OCI Object Storage 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"}}

Remarque : les types de récepteur valides pour le type de source OCI Object Storage 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 d'origine

Paramètres de configuration communs

Paramètres de configuration uniques

schemaInfo

schemaInfo.schemaObject

Fichier JSON formaté MongoDB

Le format du 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 indiquant le fichier ou le répertoire dans le modèle de configuration source.

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

Pour plus d'informations sur le fichier JSON étendu MongoDB (v2), reportez-vous à mongoexport_formats.

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

Un exemple de fichier JSON Relaxed mode au format MongoDB est le suivant :

{"_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 d'origine

Paramètres de configuration communs

Paramètres de configuration uniques

dataPath

schemaInfo

chemaInfo.schemaPath

Fichier JSON formaté MongoDB dans le bucket OCI Object Storage

Le format de fichier de configuration pour le fichier JSON formaté MongoDB dans le bucket OCI Object Storage en tant que source de NoSQL Database Migrator est indiqué ci-dessous.

Vous pouvez migrer les données JSON exportées MongoDB dans le bucket OCI Object Storage en indiquant le nom du bucket dans le modèle de configuration source.

Extrayez les données de MongoDB à l'aide de l'utilitaire mongoexport et téléchargez-les vers le bucket OCI Object Storage. Pour plus d'informations, reportez-vous à mongoexport. MongoDB prend en charge deux types d'extensions au format JSON des fichiers : le mode canonique et le mode détendu. Les deux formats sont pris en charge dans le bucket OCI Object Storage.

Un exemple de fichier JSON au format MongoDB Relaxed mode est le suivant :

{"_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"}]}

Remarque : les types de récepteur valides pour le type de source OCI Object Storage 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 d'origine

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 formaté DynamoDB stocké dans AWS S3

Le format du 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 indiquant 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 de récepteur valides pour le format DynamoDB JSON stocké 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 d'origine

Paramètres de configuration communs

Paramètres de configuration uniques

s3URL

My Oracle Support

credentialsProfile

ttlAttributeName

Fichier JSON formaté DynamoDB

Le format du 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 par DynamoDB à partir d'un système de fichiers en indiquant 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 à partir du stockage AWS S3 vers un système de fichiers monté local.

Les types de récepteur 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 d'origine

Paramètres de configuration communs

Paramètre de configuration unique

dataPath

ttlAttributeName

Oracle NoSQL Database

Le format du fichier de configuration pour 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 indiquant le nom de la table dans le modèle de configuration source.

Voici un exemple de table 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 d'origine

Paramètre de configuration commun

Paramètres de configuration uniques

storeName

helperHosts

Table

includeTTL

queryFilter

Expressions prises en charge :

L'utilitaire Migrator prend en charge les expressions suivantes dans le prédicat de requête. Pour obtenir des exemples et une syntaxe détaillés, reportez-vous au 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 de requête valides pour différentes expressions et les données exportées résultantes.

Remarque :

Table - Exemples de prédicats de requête

Requête/Prédicat Données exportées
"id=10" Lignes de la table indiquée avec id=10.
"name='John'" Lignes de la table proposée avec le nom "John".
"âge>30 ans et genre='homme" Lignes de la table donnée avec age supérieur à 30 et gender = 'mâle'.
"$row.address.state = 'CA'" Lignes 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 requise à partir d'un champ JSON.
"$row.expenses.keys(valeur $ > 1000) = 'nourriture'" Lignes de la table donnée où la catégorie expenses = 'food' 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 carte/d'enregistrement.
"$row.expenses.keys($value > $.clothes) = 'food'" Lignes de la table donnée où la catégorie expenses = 'food' et le montant expenses sont supérieurs à ceux dépensés pour clothes.
"[$row.address.phones[$element.area = 650].kind] = 'travail'" Lignes de la table donnée où l'indicatif régional du téléphone dans le tableau = 650 et le type = 'travail'. Ici, vous utilisez l'expression d'étape de filtre de tableau car le champ address est un tableau JSON.
"[connections[$element > 100 et $pos < 10]] > 100" Lignes de la table donnée avec un maximum de 10 connexions et un nombre de connexions supérieur à 100. Ici, vous utilisez une expression d'étape de filtre de tableau car le champ connections est un tableau.
"$row. income IS NULL" Lignes de la table donnée qui n'ont pas de revenu connu. Pour plus d'informations, voir Opérateurs IS NULL et IS NOT NULL.
"a dans (1, 5, 4)" Lignes de la table donnée, où a est égal à 1, 5 ou 4. Pour plus de détails, reportez-vous à Opérateur IN.
"(a, b) en (1,"a"), (5,"g"), (4,"t"))" Lignes de la table donnée où (a est 1 et b est 'a') OR (a est 5 et b est 'g') OR (a est 4 et b est 't').
"regex_like(name, 'j.*')" Lignes de la table indiquée dont le nom commence par j. Pour plus d'informations, reportez-vous à Expressions régulières.
"EXISTE $row.person.address.zipcode" Lignes de la table indiquée où la colonne json person contient zipcode dans l'adresse. Pour plus d'informations, reportez-vous à Opérateur Existe.
"$row.address est de type (chaîne)" Lignes de la table donnée où la colonne address est de type chaîne. Pour plus d'informations, reportez-vous à Opérateur de type Est.
"lastLogin > CAST('2022-10-01' AS TIMESTAMP)" Lignes de la table donnée avec la dernière connexion après le 1er octobre 2022. Pour plus d'informations, reportez-vous à Expressions de flux.
"$row.connections[ ]=any 1" Lignes de la table indiquée dont la colonne de tableau connections comporte l'élément 1. Pour plus d'informations, voir Opérateurs de comparaison de séquences.
"modification_time($row) >= 2022-10-01'' Lignes de la table donnée modifiées le 1er octobre 2022 ou après. Pour plus d'informations, reportez-vous à Fonctions sur les lignes.
"expiration_time_millis($row) > 0" Lignes de la table donnée n'ayant pas expiré. Pour plus d'informations, reportez-vous à Fonctions sur les lignes.

Oracle NoSQL Database Cloud Service

Le format du 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 indiquant le nom ou l'OCID du compartiment dans lequel la table réside dans le modèle de configuration source.

Voici un exemple de table 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 d'origine

Paramètres de configuration communs

Paramètres de configuration uniques

Table

compartiment

Remarque : si le paramètre useInstancePrincipal est défini sur True, le compartiment doit indiquer l'OCID du compartiment et non son nom.

readUnitsPercent

includeTTL

queryFilter

Expressions prises en charge :

L'utilitaire Migrator prend en charge les expressions suivantes dans le prédicat de requête. Pour obtenir des exemples et une syntaxe détaillés, reportez-vous au 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 de requête valides pour différentes expressions et les données exportées résultantes.

Remarque :

Table - Exemples de prédicats de requête

Requête/Prédicat Données exportées
"id=10" Lignes de la table indiquée avec l'ID = 10.
"name='John'" Lignes de la table proposée avec le nom "John".
"âge>30 ans et genre='homme" Lignes de la table donnée avec age supérieur à 30 et gender = 'mâle'.
"$row.address.state = 'CA'" Lignes 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 requise à partir d'un champ JSON.
"$row.expenses.keys(valeur $ > 1000) = 'nourriture'" Lignes de la table donnée où la catégorie expenses = 'food' 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 carte/d'enregistrement.
"$row.expenses.keys($value > $.clothes) = 'food'" Lignes de la table donnée où la catégorie expenses = 'food' et le montant expenses sont supérieurs à ceux dépensés pour clothes.
"[$row.address.phones[$element.area = 650].kind] = 'travail'" Lignes de la table donnée où l'indicatif régional du téléphone dans le tableau = 650 et le type = 'travail'. Ici, vous utilisez l'expression d'étape de filtre de tableau car le champ address est un tableau JSON.
"[connections[$element > 100 et $pos < 10]] > 100" Lignes de la table donnée avec un maximum de 10 connexions et un nombre de connexions supérieur à 100. Ici, vous utilisez une expression d'étape de filtre de tableau car le champ connections est un tableau.
"$row. income IS NULL" Lignes de la table donnée qui n'ont pas de revenu connu. Pour plus d'informations, voir Opérateurs IS NULL et IS NOT NULL.
"a dans (1, 5, 4)" Lignes de la table donnée, où a est égal à 1, 5 ou 4. Pour plus d'informations, reportez-vous à Opérateur IN.
"(a, b) en (1,"a"), (5,"g"), (4,"t"))" Lignes de la table donnée où (a est 1 et b est 'a') OR (a est 5 et b est 'g') OR (a est 4 et b est 't').
"regex_like(name, 'j.*')" Lignes de la table indiquée dont le nom commence par j. Pour plus d'informations, reportez-vous à Expressions régulières.
"EXISTE $row.person.address.zipcode" Lignes de la table indiquée où la colonne json person contient zipcode dans l'adresse. Pour plus d'informations, reportez-vous à Opérateur Exists.
"$row.address est de type (chaîne)" Lignes de la table donnée où la colonne address est de type chaîne. Pour plus d'informations, reportez-vous à Opérateur de type Est.
"lastLogin > CAST('2022-10-01' AS TIMESTAMP)" Lignes de la table donnée avec la dernière connexion après le 1er octobre 2022. Pour plus d'informations, reportez-vous à Expressions de flux.
"$row.connections[ ]=any 1" Lignes de la table indiquée dont la colonne de tableau connections comporte l'élément 1. Pour plus d'informations, voir Opérateurs de comparaison de séquences.
"modification_time($row) >= 2022-10-01'' Lignes de la table donnée modifiées le 1er octobre 2022 ou après. Pour plus d'informations, reportez-vous à Fonctions sur les lignes.
"expiration_time_millis($row) > 0" Lignes de la table donnée n'ayant pas expiré. Pour plus d'informations, reportez-vous à Fonctions sur les lignes.

Source du fichier CSV

Le format de fichier de configuration du 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 indiquant 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 d'origine

Paramètres de configuration communs

Paramètres de configuration uniques

dataPath

Remarque : les fichiers CSV ne doivent contenir que des valeurs scalaires. L'import de fichiers CSV contenant des types complexes tels que MAP, RECORD, ARRAY et JSON n'est pas pris en charge. L'outil NoSQL Database Migrator ne vérifie pas si les données du fichier CSV d'entrée sont correctes. L'outil NoSQL Database Migrator prend en charge l'import de données CSV conformes au format RFC4180. Les fichiers CSV contenant des données qui ne sont pas conformes à la norme RFC4180 peuvent ne pas être copiés correctement ou générer une erreur. Si les données d'entrée sont endommagées, l'outil NoSQL Database Migrator n'analyse pas les enregistrements CSV. Si des erreurs sont détectées lors de la migration, l'outil NoSQL Database Migrator consigne les informations relatives aux enregistrements d'entrée en échec à des fins de débogage et d'information. Pour plus d'informations, reportez-vous à Progression du migrateur de journalisation dans Utilisation d'Oracle NoSQL Data Migrator.

hasHeader

colonnes

csvOptions

csvOptions.encoding

csvOptions.trim

Fichier CSV dans le bucket OCI Object Storage

Le format du fichier de configuration pour le fichier CSV dans le bucket OCI Object Storage 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 bucket OCI Object Storage en indiquant le nom du bucket dans le modèle de configuration source.

Un exemple de fichier CSV dans le bucket OCI Object Storage est le suivant :

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

Remarque : les types de récepteur valides pour le type de source OCI Object Storage 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 d'origine

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 du récepteur pour chaque récepteur valide et l'objectif de chaque paramètre de configuration.

Pour le modèle de fichier de configuration, reportez-vous à Fichier de configuration dans Terminologie utilisée avec NoSQL Data Migrator.

Pour plus d'informations sur les formats source valides pour chacun des puits, reportez-vous à la section Source Configuration Templates.

Rubriques

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

Récepteur de fichiers JSON

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

Modèle de configuration d'é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 d'évier

Paramètres de configuration communs

Paramètres de configuration uniques

dataPath

cheminschema

pretty

useMultiFiles

Fichier de parquet

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

Modèle de configuration d'é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 d'évier

Paramètres de configuration communs

Paramètres de configuration uniques

dataPath

compression

parquetOptions

parquetOptions.useLogicalJson

parquetOptions.useLogicalEnum

parquetOptions.useLogicalUUID

parquetOptions.truncateDoubleSpecials

Fichier JSON dans le bucket OCI Object Storage

Le format du fichier de configuration pour le fichier JSON dans le bucket OCI Object Storage en tant que récepteur de NoSQL Database Migrator est indiqué ci-dessous.

Remarque : les types de source valides pour OCI Object Storage en tant que récepteur sont nosqldb et nosqldb_cloud.

Modèle de configuration d'é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 d'évier

Paramètres de configuration communs

Paramètre de configuration unique

pretty

Fichier de parquet dans le bucket OCI Object Storage

Le format du fichier de configuration pour le fichier Parquet dans le bucket OCI Object Storage en tant que récepteur de NoSQL Database Migrator est indiqué ci-dessous.

Remarque : les types de source valides pour le type de source OCI Object Storage sont nosqldb et nosqldb_cloud.

Modèle de configuration d'é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 d'évier

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 du fichier de configuration pour Oracle NoSQL Database en tant que récepteur de NoSQL Database Migrator est indiqué ci-dessous.

Modèle de configuration d'é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 d'évier

Paramètre de configuration commun

Paramètre de configuration unique

storeName

helperHosts

Table

includeTTL

ttlRelativeDate

schemainfo

chemaInfo.schemaPath

schemaInfo.defaultSchema

schemaInfo.useSourceSchema

schemaInfo.DDBPartitionKey

schemaInfo.DDBSortKey

overwrite

Oracle NoSQL Database Cloud Service

Le format du 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 d'é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 d'évier

Paramètres de configuration communs

Paramètre de configuration unique


Table


compartiment


includeTTL


ttlRelativeDate


schemaInfo


chemaInfo.schemaPath

Remarque : defaultSchema et schemaPath s'excluent mutuellement.


schemaInfo.defaultSchema


schemaInfo.useSourceSchema


schemaInfo.DDBPartitionKey


schemaInfo.DDBSortKey


schemaInfo.onDemandThroughput

Remarque : ce paramètre n'est pas applicable aux tables enfant car elles partagent le débit de la table parent de niveau supérieur.


schemaInfo.readUnits


schemaInfo.writeUnits


schemaInfo.storageSize


writeUnitsPercent


overwrite

Modèles de configuration de transformation

Cette rubrique explique les paramètres de configuration des différentes transformations prises en charge par le processus de migration Oracle NoSQL Database. Pour obtenir le modèle de fichier de configuration complet, reportez-vous à Fichier de configuration dans Terminologie utilisée avec NoSQL Data Migrator.

Oracle NoSQL Database Migrator 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 ce cas, l'ordre des transformations est vital car les données source 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 ligne source avant d'écrire dans l'évier.
renameFields Renommez les colonnes identifiées de la ligne source avant d'écrire dans le puits.
aggregateFields Regroupez 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.

ignorerChamps

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

ignorerChamps

includeFields

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

includeFields

Renommer les champs

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

Renommer les champs

champs agrégés

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 agrégés

Mise en correspondance de types DynamoDB avec des types Oracle NoSQL

Le tableau ci-dessous présente la correspondance entre les types DynamoDB et les types Oracle NoSQL.

Table - Mise en correspondance du type DynamoDB avec le type Oracle NoSQL

# Type DynamoDB Type JSON pour la colonne JSON NoSQL Type Oracle NoSQL
1 Chaîne (S) Chaîne JSON STRING
2 Type de nombre (N) Numéro JSON NOMBRE ENTIER/LONG/FLOTTANT/DOUBLE/NOMBRE
3 Boolean (BOOL) Booléen JSON BOOLEAN
4 Type binaire (B) - Tampon d'octets Chaîne JSON encodée BASE-64 BINARY
5 NULL JSON NULL NULL
6 Jeu de chaînes (SS) Tableau JSON de variables String TABLEAU (CHAÎNE)
7 Ensemble de nombres (NS) Tableau JSON des nombres TABLEAU (ENTIER/LONG/FLOTTANT/DOUBLE/NOMBRE)
8 Ensemble binaire (BS) Tableau JSON de chaînes codé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É FARD
12 TRIER LA CLÉ S/O PRIMARY KEY
13 Noms d'attribut avec un tiret et un point Noms de champ JSON avec un trait de soulignement Noms de colonne avec trait de soulignement

Quelques points supplémentaires à prendre en compte lors de la mise en correspondance des types DynamoDB avec les types Oracle NoSQL :

Correspondance de type d'informations Oracle NoSQL vers Parquet

Décrit la correspondance entre les types de données Oracle NoSQL et Parquet.

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

ou

BINARY(ENUM), si l'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
nom_champ ARRAY(T) 
group field_name(LIST) { repeated group list { required T element } }
nom_champ MAP(T) 
group field_name (MAP) { repeated group key_value (MAP_KEY_VALUE) { required binary key (STRING); required T value; } }
nom_champ ENREGISTREMENT(K1 T1 N1, K ⁇ 2 T2 N2, ....)

où :

K = Nom de la clé

T = Type

N = Nullable ou non

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

ou

BINARY(JSON), si le JSON logique est configuré

Remarque : lorsque le type de nombre NoSQL est converti en type Parquet double, il peut y avoir une perte de précision si la valeur ne peut pas être représentée en double. Si le nombre est trop grand pour représenter Double, il est converti en Double.NEGATIVE_INFINITY ou Double.POSITIVE_INFINITY.

Mise en correspondance de la table DynamoDB avec la table Oracle NoSQL

Dans DynamoDB, une table est un ensemble d'éléments, et chaque élément est un ensemble d'attributs. Chaque élément de la table possède un identificateur unique ou une clé primaire. Outre 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é primaire différents :

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

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

  1. Modélisation de la table DynamoDB en tant que document JSON (recommandé) : dans cette modélisation, vous mettez en correspondance tous les attributs des tables Dynamo DB en une colonne JSON de la table NoSQL, à l'exception de la clé de partitionnement et de la clé de tri. Vous modéliserez la clé de partitionnement et la clé de tri en tant que colonnes de clé primaire de la table NoSQL. Vous allez utiliser la transformation AggregateFields afin d'agréger les données de clé secondaire en une colonne JSON.

    Remarque : le migrateur fournit une configuration conviviale defaultSchema permettant de créer automatiquement une table LDD sans schéma qui agrège également les attributs en une colonne JSON.

  2. Modélisation de la 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 indiqué dans la mise en correspondance des types DynamoDB avec les types Oracle NoSQL. Vous modéliserez les attributs de clé de partitionnement et de clé de tri en tant que clés primaires. Cela ne doit être utilisé que lorsque vous êtes certain que l'import 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 grand nombre de colonnes NoSQL avec des valeurs vides.

    Remarque : nous vous recommandons vivement d'utiliser des tables sans schéma lors de la migration de données de DynamoDB vers Oracle NoSQL Database en raison de la nature des tables DynamoDB sans schéma. C'est particulièrement le cas 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 que vous pouvez rencontrer lors de l'utilisation de , et comment les résoudre.

Echec de la migration. Comment résoudre ce problème ?

L'échec de la migration des données peut être dû à 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 Le migrateur 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 emplacement de stockage sécurisé, vérifiez que le fichier de sécurité est valide avec les valeurs de nom utilisateur et de mot de passe correctes.
Failed to connect to Oracle NoSQL Database Cloud Service Le migrateur n'a pas pu établir de connexion avec Oracle NoSQL Database Cloud Service.
  • Vérifiez si l'URL d'adresse ou le nom de région indiqué dans le fichier JSON de configuration est correct.
  • Vérifiez si le fichier d'informations d'identification OCI est disponible dans le chemin indiqué dans le fichier JSON de configuration.
  • Assurez-vous que les informations d'identification OCI fournies dans les informations 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 elle 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 indiqué dans le fichier JSON de configuration et assurez-vous que vous disposez 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 via la migration.
DDL Execution failed Les commandes LDD fournies dans le fichier de définition du 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'existe qu'une seule instruction 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 récepteur.
  • Vérifiez si les types de données et les noms de colonne indiqués dans la table de récepteur cible correspondent au schéma de la table de récepteur.
  • Si vous avez appliqué une transformation, vérifiez si les enregistrements transformés correspondent au schéma de la table d'extraction.
Request timeout L'opération de la source ou du récepteur ne s'est pas terminée dans le délai prévu.
  • Vérification de la connexion réseau.
  • Vérifiez que la base de données NoSQL Database est en fonctionnement.
  • Essayez d'augmenter la valeur requestTimeout dans le fichier JSON de configuration.

Que dois-je prendre en compte avant de redémarrer une migration qui a échoué ?

Lorsqu'une tâche de migration de données échoue, le récepteur se trouve à 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 recommence et traite toutes les données depuis le début. Il n'existe aucun moyen de point de reprise et de redémarrer la migration à partir du point d'échec. Par conséquent, NoSQL Database Migrator écrase tout enregistrement qui a déjà été migré vers le récepteur.

Meilleures pratiques

La durée de la migration des données dépend de plusieurs facteurs tels que le volume de données en cours de migration, la vitesse du réseau et la charge actuelle sur la base de données. Dans le cas d'un service cloud, 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 atteindre une vitesse de migration plus élevée en traitant plusieurs flux en parallèle. Les points suivants suggèrent comment exploiter cette fonctionnalité pour différents scénarios de migration :

J'ai une migration longue impliquant des ensembles de données volumineux. Comment suivre la progression de la migration ?

Vous pouvez activer la journalisation supplémentaire pour suivre la progression d'une migration longue. 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 le package NoSQL Database Migrator et disponible dans le répertoire dans lequel le package Oracle NoSQL Database Migrator a été décompressé. Les différents niveaux de journalisation dans l'ordre de niveau de détail croissant sont OFF, SEVERE, WARNING, INFO, FINE, et ALL.

La définition du niveau de journalisation sur OFF désactive toutes les informations de journalisation, tandis que la définition du niveau de journalisation sur ALL fournit les informations de journalisation complètes.

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

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