Générer des métadonnées pour la traduction et l'évaluation
Ce document explique comment créer des fichiers de métadonnées et des fichiers journaux de requêtes à l'aide de l'outil de ligne de commande d'extraction dwh-migration-dumper
. Les fichiers de métadonnées décrivent les objets SQL de votre système source.
Le service de migration BigQuery utilise ces informations pour améliorer la traduction de vos scripts SQL à partir de votre dialecte système source vers GoogleSQL.
L'évaluation de la migration BigQuery utilise des fichiers de métadonnées et des fichiers journaux de requêtes pour analyser votre entrepôt de données existant et vous aider à évaluer les efforts de migration de votre entrepôt de données vers BigQuery.
Présentation
Vous pouvez utiliser l'outil dwh-migration-dumper
pour extraire des informations de métadonnées de la plate-forme de base de données que vous migrez vers BigQuery. Bien que l'outil d'extraction ne soit pas requis pour la traduction, il est requis pour l'évaluation de la migration BigQuery. Nous vous recommandons vivement de l'utiliser pour toutes les tâches de migration.
Pour en savoir plus, consultez la section Créer des fichiers de métadonnées.
Vous pouvez utiliser l'outil dwh-migration-dumper
pour extraire les métadonnées des plates-formes de base de données suivantes :
- Teradata
- Amazon Redshift
- Apache Hive
- Apache Spark
- Azure Synapse
- Microsoft SQL Server
- IBM Netezza
- Oracle
- Snowflake
- Trino ou PrestoSQL
- Vertica
Pour la plupart de ces bases de données, vous pouvez également extraire des journaux de requêtes.
L'outil dwh-migration-dumper
interroge les tables système pour collecter des instructions LDD (langage de définition de données) liées aux bases de données utilisateur et système. Il n'interroge pas le contenu des bases de données utilisateur. L'outil enregistre les informations de métadonnées des tables système sous forme de fichiers CSV, puis compresse ces fichiers dans un seul package. Vous importez ensuite ce fichier ZIP dans Cloud Storage lorsque vous importez vos fichiers sources pour les traduire ou les évaluer.
Lorsque vous utilisez l'option de journaux de requêtes, l'outil dwh-migration-dumper
interroge les tables système pour obtenir des instructions LDD et des journaux de requêtes liés aux bases de données utilisateur et système. Ceux-ci sont enregistrés dans un sous-répertoire au format CSV ou YAML, puis compressés dans un package ZIP. À aucun moment le contenu des bases de données utilisateur n'est interrogé lui-même. Pour le moment, l'évaluation de la migration BigQuery nécessite des fichiers CSV, YAML et texte individuels pour les journaux de requêtes. Vous devez donc décompresser tous ces fichiers du fichier ZIP de journaux de requêtes, puis les importer pour les évaluer.
L'outil dwh-migration-dumper
peut s'exécuter sous Windows, macOS et Linux.
L'outil dwh-migration-dumper
est disponible sous la licence Apache 2.
Si vous choisissez de ne pas utiliser l'outil dwh-migration-dumper
pour la traduction, vous pouvez fournir manuellement des fichiers de métadonnées en collectant les instructions LDD (langage de définition de données) pour les objets SQL de votre système source dans des fichiers texte distincts.
Il est nécessaire de fournir les métadonnées et les journaux de requêtes extraits avec l'outil pour l'évaluation de la migration à l'aide de l'évaluation de la migration BigQuery.
Exigences de conformité
Nous fournissons le binaire de l'outil dwh-migration-dumper
compilé pour faciliter son utilisation. Si vous devez auditer l'outil pour vous assurer qu'il répond aux exigences de conformité, vous pouvez consulter le code source à partir du dépôt GitHub de l'outil dwh-migration-dumper
et compiler votre propre binaire.
Prérequis
Installer Java
Java 8 ou une version ultérieure doit être installé sur le serveur sur lequel vous prévoyez d'exécuter l'outil dwh-migration-dumper
. Si ce n'est pas le cas, téléchargez Java à partir de la page des téléchargements Java et installez-le.
Autorisations requises
Le compte utilisateur que vous spécifiez pour connecter l'outil dwh-migration-dumper
au système source doit être autorisé à lire les métadonnées de ce système.
Vérifiez que ce compte dispose de l'appartenance appropriée au rôle pour interroger les ressources de métadonnées disponibles pour votre plate-forme. Par exemple, INFORMATION_SCHEMA
est une ressource de métadonnées commune à plusieurs plates-formes.
Installez l'outil dwh-migration-dumper
Pour installer l'outil dwh-migration-dumper
, procédez comme suit :
- Sur la machine sur laquelle vous souhaitez exécuter l'outil
dwh-migration-dumper
, téléchargez le fichier ZIP à partir du dépôt GitHub de l'outildwh-migration-dumper
. - Téléchargez le fichier
SHA256SUMS.txt
et exécutez la commande suivante :sha256sum --check SHA256SUMS.txt
Si la validation échoue, consultez la section Dépannage. - Extrayez le fichier ZIP. Le fichier binaire de l'outil d'extraction se trouve dans le sous-répertoire
/bin
du dossier créé en extrayant le fichier ZIP. - Mettez à jour la variable d'environnement
PATH
pour inclure le chemin d'installation de l'outil d'extraction.
Exécuter l'outil dwh-migration-dumper
L'outil dwh-migration-dumper
utilise le format suivant :
dwh-migration-dumper [FLAGS]
L'exécution de l'outil dwh-migration-dumper
crée un fichier de sortie nommé dwh-migration-<source platform>-metadata.zip
, par exemple dwh-migration-teradata-metadata.zip
, dans votre répertoire de travail.
Suivez les instructions ci-dessous pour apprendre à exécuter l'outil dwh-migration-dumper
pour votre plate-forme source.
Teradata
Pour autoriser l'outil dwh-migration-dumper
à se connecter à Teradata, téléchargez son pilote JDBC à partir de la page de téléchargement de Teradata.
Le tableau suivant décrit les options couramment utilisées pour extraire les métadonnées et les journaux de requêtes Teradata à l'aide de l'outil d'extraction. Pour en savoir plus sur toutes les options compatibles, consultez la section Options globales.
Nom | Valeur par défaut | Description | Obligatoire |
---|---|---|---|
--assessment |
Activation du mode d'évaluation lors de la génération de journaux de base de données ou l'extraction de métadonnées.
L'outil |
Obligatoire pour exécuter une évaluation, non requis pour la traduction. | |
--connector |
Nom du connecteur à utiliser, dans ce cas teradata pour les métadonnées ou teradata-logs pour les journaux de requêtes. | Oui | |
--database |
Liste des bases de données à extraire, séparées par une virgule. Les noms de base de données peuvent être sensibles à la casse, en fonction de la configuration du serveur Teradata. Si cette option est utilisée conjointement avec le connecteur Cette option ne peut pas être utilisée conjointement avec le connecteur |
Non | |
--driver |
Chemin absolu ou relatif au fichier JAR du pilote à utiliser pour cette connexion. Vous pouvez spécifier plusieurs fichiers JAR de pilote en les séparant par une virgule. | Oui | |
--host |
localhost | Nom d'hôte ou adresse IP du serveur de base de données. | No |
--password |
Mot de passe à utiliser pour la connexion à la base de données. | S'il n'est pas spécifié, l'outil d'extraction utilise une invite sécurisée pour le demander. | |
--port |
1025 | Port du serveur de base de données. | No |
--user |
Nom d'utilisateur à utiliser pour la connexion à la base de données. |
Yes | |
--query-log-alternates |
Pour le connecteur Pour extraire les journaux de requête depuis un autre emplacement, nous vous recommandons d'utiliser plutôt les options
Par défaut, les journaux de requête sont extraits des tables Exemple : |
Non | |
-Dteradata.tmode |
Mode de transaction de la connexion. Les valeurs suivantes sont acceptées :
Exemple (Bash) : Exemple (Windows PowerShell) : |
Non | |
-Dteradata-logs.log-date-column |
Pour le connecteur
Pour améliorer les performances des tables de jointure spécifiées par les options Exemple (Bash) : Exemple (Windows PowerShell) : |
Non | |
-Dteradata-logs.query-logs-table |
Pour le connecteur
Par défaut, les journaux de requête sont extraits de la table Exemple (Bash) : Exemple (Windows PowerShell) : |
Non | |
-Dteradata-logs.sql-logs-table |
Pour le connecteur
Par défaut, les journaux de requête contenant le texte SQL sont extraits de la table Exemple (Bash) : Exemple (Windows PowerShell) : |
Non | |
-Dteradata-logs.utility-logs-table |
Pour le connecteur
Par défaut, les journaux utilitaires sont extraits de la table Exemple (Bash) : Exemple (Windows PowerShell) : |
Non | |
-Dteradata-logs.res-usage-scpu-table |
Pour le connecteur
Par défaut, les journaux d'utilisation des ressources SCPU sont extraits de la table Exemple (Bash) : Exemple (Windows PowerShell) : |
Non | |
-Dteradata-logs.res-usage-spma-table |
Pour le connecteur
Par défaut, les journaux d'utilisation des ressources SPMA sont extraits de la table Exemple (Bash) : Exemple (Windows PowerShell) : |
Non | |
--query-log-start |
Heure de début (inclusive) pour l'extraction des journaux de requête. La valeur est tronquée à l'heure. Cette option n'est disponible que pour le connecteur teradata-logs.
Exemple : |
Non | |
--query-log-end |
Heure de fin (exclusive) pour l'extraction des journaux de requête. La valeur est tronquée à l'heure. Cette option n'est disponible que pour le connecteur teradata-logs.
Exemple : |
Non | |
-Dteradata.metadata.tablesizev.max-rows |
Pour le connecteur Limitez le nombre de lignes extraites de la vue Exemple (Bash) : Exemple (Windows PowerShell) : |
Non | |
-Dteradata.metadata.diskspacev.max-rows |
Pour le connecteur Limitez le nombre de lignes extraites de la vue Exemple (Bash) : Exemple (Windows PowerShell) : |
Non | |
-Dteradata.metadata.databasesv.users.max-rows |
Pour le connecteur
Limitez le nombre de lignes représentant les utilisateurs ( Exemple (Bash) : Exemple (Windows PowerShell) : |
Non | |
-Dteradata.metadata.databasesv.dbs.max-rows |
Pour le connecteur Limitez le nombre de lignes représentant les bases de données ( Exemple (Bash) : Exemple (Windows PowerShell) : |
Non | |
-Dteradata.metadata.max-text-length |
Pour le connecteur Longueur maximale de la colonne de texte lors de l'extraction des données de la vue Exemple (Bash) : Exemple (Windows PowerShell) : |
Non | |
-Dteradata-logs.max-sql-length |
Pour le connecteur Longueur maximale de la colonne Exemple (Bash) : Exemple (Windows PowerShell) : |
Non |
Examples
L'exemple suivant montre comment extraire les métadonnées de deux bases de données Teradata sur l'hôte local :
dwh-migration-dumper \
--connector teradata \
--user user \
--password password \
--database database1,database2 \
--driver path/terajdbc4.jar
L'exemple suivant montre comment extraire les journaux de requêtes pour l'évaluation sur l'hôte local à des fins d'authentification :
dwh-migration-dumper \
--connector teradata-logs \
--assessment \
--user user \
--password password \
--driver path/terajdbc4.jar
Tables et vues extraites par l'outil dwh-migration-dumper
Les tables et les vues suivantes sont extraites lorsque vous utilisez le connecteur teradata
:
DBC.ColumnsV
DBC.DatabasesV
DBC.DBCInfo
DBC.FunctionsV
DBC.IndicesV
DBC.PartitioningConstraintsV
DBC.TablesV
DBC.TableTextV
Les tables et les vues supplémentaires suivantes sont extraites lorsque vous utilisez le connecteur teradata
avec l'option --assessment
:
DBC.All_RI_ChildrenV
DBC.All_RI_ParentsV
DBC.AllTempTablesVX
DBC.DiskSpaceV
DBC.RoleMembersV
DBC.StatsV
DBC.TableSizeV
Les tables et les vues suivantes sont extraites lorsque vous utilisez le connecteur teradata-logs
:
DBC.DBQLogTbl
(modifié parDBC.QryLogV
si l'option--assessment
est utilisée)DBC.DBQLSqlTbl
Les tables et les vues supplémentaires suivantes sont extraites lorsque vous utilisez le connecteur teradata-logs
avec l'option --assessment
:
DBC.DBQLUtilityTbl
DBC.ResUsageScpu
DBC.ResUsageSpma
Redshift
L'outil d'extraction vous permet d'utiliser l'un des mécanismes d'authentification et d'autorisation Amazon Redshift suivants :
- Un nom d'utilisateur et un mot de passe
- ID de la clé d'accès et clé secrète AWS Identity and Access Management (IAM)
- Un nom de profil AWS IAM
Pour vous authentifier avec le nom d'utilisateur et le mot de passe, utilisez le pilote JDBC PostgreSQL par défaut d'Amazon Redshift. Pour vous authentifier avec AWS IAM, utilisez le pilote JDBC Amazon Redshift, que vous pouvez télécharger depuis leur page de téléchargement.
Le tableau suivant décrit les options couramment utilisées pour extraire les métadonnées et les journaux de requêtes Amazon Redshift à l'aide de l'outil dwh-migration-dumper
. Pour en savoir plus sur tous les options compatibles, consultez la section Options globales.
Nom | Valeur par défaut | Description | Obligatoire |
---|---|---|---|
--assessment |
Activation du mode d'évaluation lors de la génération de journaux de base de données ou l'extraction de métadonnées. Il génère les statistiques de métadonnées requises pour l'évaluation de la migration BigQuery lorsqu'il est utilisé pour l'extraction de métadonnées. Lorsque le mode d'évaluation est utilisé pour extraire des journaux de requêtes, il génère des statistiques sur les métriques de requête pour l'évaluation de la migration BigQuery. |
Obligatoire lors de l'exécution en mode d'évaluation, non requis pour la traduction. | |
--connector |
Nom du connecteur à utiliser, dans ce cas redshift pour les métadonnées ou redshift-raw-logs pour les journaux de requêtes. | Yes | |
--database |
Si cette valeur n'est pas spécifiée, Amazon Redshift utilise la valeur --user comme nom de base de données par défaut. |
Nom de la base de données à laquelle se connecter. |
No |
--driver |
Si ce champ n'est pas spécifié, Amazon Redshift utilise le pilote JDBC PostgreSQL par défaut. | Chemin absolu ou relatif au fichier JAR du pilote à utiliser pour cette connexion. Vous pouvez spécifier plusieurs fichiers JAR de pilote en les séparant par une virgule. | Non |
--host |
localhost | Nom d'hôte ou adresse IP du serveur de base de données. | No |
--iam-accesskeyid |
ID de clé d'accès AWS IAM à utiliser pour l'authentification. La clé d'accès est une chaîne de caractères semblable à
Utilisez cette option conjointement avec l'option |
Pas explicitement, mais vous devez fournir des informations d'authentification via l'une des méthodes suivantes :
|
|
--iam-profile |
Profil AWS IAM à utiliser pour l'authentification. Pour récupérer une valeur de profil à utiliser, examinez le fichier
N'utilisez pas cette option avec les options |
Pas explicitement, mais vous devez fournir des informations d'authentification via l'une des méthodes suivantes :
|
|
--iam-secretaccesskey |
Clé d'accès secrète AWS IAM à utiliser pour l'authentification. La clé d'accès secrète est une chaîne de caractères semblable à
Utilisez cette option conjointement avec l'option |
Pas explicitement, mais vous devez fournir des informations d'authentification via l'une des méthodes suivantes :
|
|
--password |
Mot de passe à utiliser pour la connexion à la base de données.
N'utilisez pas cette option avec les options |
Pas explicitement, mais vous devez fournir des informations d'authentification via l'une des méthodes suivantes :
|
|
--port |
5439 | Port du serveur de base de données. | No |
--user |
Nom d'utilisateur à utiliser pour la connexion à la base de données. | Yes | |
--query-log-start |
Heure de début (inclusive) pour l'extraction des journaux de requête. La valeur est tronquée à l'heure. Cette option n'est disponible que pour le connecteur redshift-raw-logs.
Exemple : |
Non | |
--query-log-end |
Heure de fin (exclusive) pour l'extraction des journaux de requête. La valeur est tronquée à l'heure. Cette option n'est disponible que pour le connecteur redshift-raw-logs.
Exemple : |
Non |
Examples
L'exemple suivant montre comment extraire les métadonnées d'une base de données Amazon Redshift sur un hôte spécifié à l'aide de clés IAM AWS pour l'authentification :
dwh-migration-dumper \
--connector redshift \
--database database \
--driver path/redshift-jdbc42-version.jar \
--host host.region.redshift.amazonaws.com \
--iam-accesskeyid access_key_ID \
--iam-secretaccesskey secret_access-key \
--user user
L'exemple suivant montre comment extraire les métadonnées d'une base de données Amazon Redshift sur l'hôte par défaut à l'aide du nom d'utilisateur et du mot de passe pour l'authentification :
dwh-migration-dumper \
--connector redshift \
--database database \
--password password \
--user user
L'exemple suivant montre comment extraire les métadonnées d'une base de données Amazon Redshift sur un hôte spécifié à l'aide d'un profil IAM AWS pour l'authentification :
dwh-migration-dumper \
--connector redshift \
--database database \
--driver path/redshift-jdbc42-version.jar \
--host host.region.redshift.amazonaws.com \
--iam-profile profile \
--user user \
--assessment
L'exemple suivant montre comment extraire les journaux de requêtes pour l'évaluation depuis une base de données Amazon Redshift sur un hôte spécifié à l'aide d'un profil IAM AWS pour l'authentification :
dwh-migration-dumper \
--connector redshift-raw-logs \
--database database \
--driver path/redshift-jdbc42-version.jar \
--host 123.456.789.012 \
--iam-profile profile \
--user user \
--assessment
Tables et vues extraites par l'outil dwh-migration-dumper
Les tables et les vues suivantes sont extraites lorsque vous utilisez le connecteur redshift
:
SVV_COLUMNS
SVV_EXTERNAL_COLUMNS
SVV_EXTERNAL_DATABASES
SVV_EXTERNAL_PARTITIONS
SVV_EXTERNAL_SCHEMAS
SVV_EXTERNAL_TABLES
SVV_TABLES
SVV_TABLE_INFO
INFORMATION_SCHEMA.COLUMNS
PG_CAST
PG_DATABASE
PG_LANGUAGE
PG_LIBRARY
PG_NAMESPACE
PG_OPERATOR
PG_PROC
PG_TABLE_DEF
PG_TABLES
PG_TYPE
PG_VIEWS
Les tables et les vues supplémentaires suivantes sont extraites lorsque vous utilisez le connecteur redshift
avec l'option --assessment
:
SVV_DISKUSAGE
STV_MV_INFO
STV_WLM_SERVICE_CLASS_CONFIG
STV_WLM_SERVICE_CLASS_STATE
Les tables et les vues suivantes sont extraites lorsque vous utilisez le connecteur redshift-raw-logs
:
STL_DDLTEXT
STL_QUERY
STL_QUERYTEXT
PG_USER
Les tables et les vues supplémentaires suivantes sont extraites lorsque vous utilisez le connecteur redshift-raw-logs
avec l'option --assessment
:
STL_QUERY_METRICS
SVL_QUERY_QUEUE_INFO
STL_WLM_QUERY
Pour en savoir plus sur les vues système et les tables de Redshift, consultez les sections Vues du système Redshift et Tables de catalogue du système Redshift.
Apache Hive/Spark ou Trino/PrestoSQL
L'outil dwh-migration-dumper
ne permet de se connecter auprès du métastore Apache Hive que via Kerberos. Par conséquent, les options --user
et --password
ne sont pas utilisées. Vous devez à la place utiliser l'option --hive-kerberos-url
pour fournir les détails de l'authentification Kerberos.
Le tableau suivant décrit les options couramment utilisées pour extraire des métadonnées Apache Hive, Spark, Presto ou Trino à l'aide de l'outil d'extraction. Pour en savoir plus sur toutes les options compatibles, consultez la section Options globales.
Nom | Valeur par défaut | Description | Obligatoire |
---|---|---|---|
--assessment |
Active le mode d'évaluation lors de l'extraction des métadonnées.
L'outil |
Obligatoire pour l'évaluation. Non obligatoire pour la traduction. | |
--connector |
Nom du connecteur à utiliser, dans ce cas hiveql. | Yes | |
--hive-metastore-dump-partition-metadata |
true |
Il force l'outil
N'utilisez pas cette option avec l'option |
Non |
--hive-metastore-version |
2.3.6 |
Lorsque vous exécutez l'outil |
No |
--host |
localhost | Nom d'hôte ou adresse IP du serveur de base de données. | No |
--port |
9083 | Port du serveur de base de données. | Non |
--hive-kerberos-url |
Compte principal et hôte Kerberos à utiliser pour l'authentification. | Obligatoire pour les clusters avec l'authentification Kerberos activée. | |
-Dhiveql.rpc.protection |
Niveau de configuration de la protection RPC. Cela détermine la qualité de protection (QOP) de la connexion SASL (Simple Authentication and Security Layer) entre le cluster et l'outil Doit être égale à la valeur du paramètre
Exemple (Bash) : Exemple (Windows PowerShell) : |
Obligatoire pour les clusters avec l'authentification Kerberos activée. |
Examples
L'exemple suivant montre comment extraire les métadonnées d'une base de données Hive 2.3.7 sur un hôte spécifié, sans authentification et en utilisant un autre port pour la connexion :
dwh-migration-dumper \
--connector hiveql \
--hive-metastore-version 2.3.7 \
--host host \
--port port
Pour utiliser l'authentification Kerberos, connectez-vous au métastore Hive en tant qu'utilisateur disposant d'autorisations en lecture et générez un ticket Kerberos. Ensuite, générez le fichier ZIP de métadonnées à l'aide de la commande suivante :
JAVA_OPTS="-Djavax.security.auth.useSubjectCredsOnly=false" \
dwh-migration-dumper \
--connector hiveql \
--host host \
--port port \
--hive-kerberos-url principal/kerberos_host
Azure Synapse ou Microsoft SQL Server
Pour autoriser l'outil dwh-migration-dumper
à se connecter à Azure Synapse ou Microsoft SQL Server, téléchargez son pilote JDBC à partir de la page de téléchargement de Microsoft.
Le tableau suivant décrit les options couramment utilisées pour extraire les métadonnées Azure Synapse ou Microsoft SQL Server à l'aide de l'outil d'extraction. Pour en savoir plus sur toutes les options compatibles, consultez la section Options globales.
Nom | Valeur par défaut | Description | Obligatoire |
---|---|---|---|
--connector |
Nom du connecteur à utiliser, dans ce cas sqlserver. | Yes | |
--database |
Nom de la base de données à laquelle se connecter. |
Yes | |
--driver |
Chemin absolu ou relatif au fichier JAR du pilote à utiliser pour cette connexion. Vous pouvez spécifier plusieurs fichiers JAR de pilote en les séparant par une virgule. | Oui | |
--host |
localhost | Nom d'hôte ou adresse IP du serveur de base de données. | No |
--password |
Mot de passe à utiliser pour la connexion à la base de données. | Yes | |
--port |
1433 | Port du serveur de base de données. | No |
--user |
Nom d'utilisateur à utiliser pour la connexion à la base de données. | Yes |
Examples
L'exemple suivant montre comment extraire les métadonnées d'une base de données Azure Synapse sur un hôte spécifié :
dwh-migration-dumper \
--connector sqlserver \
--database database \
--driver path/mssql-jdbc.jar \
--host server_name.sql.azuresynapse.net \
--password password \
--user user
Netezza
Pour permettre à l'outil dwh-migration-dumper
de se connecter à IBM Netezza, vous devez obtenir son pilote JDBC. Vous pouvez généralement obtenir le pilote à partir du répertoire /nz/kit/sbin
sur votre hôte de serveur IBM Netezza. Si vous ne le trouvez pas, demandez de l'aide à votre administrateur système ou consultez la section Installer et configurer JDBC dans la documentation IBM Netezza.
Le tableau suivant décrit les options couramment utilisées pour extraire les métadonnées IBM Netezza à l'aide de l'outil d'extraction. Pour en savoir plus sur toutes les options compatibles, consultez la section Options globales.
Nom | Valeur par défaut | Description | Obligatoire |
---|---|---|---|
--connector |
Nom du connecteur à utiliser, dans ce cas netezza. | Oui | |
--database |
Liste des bases de données à extraire, séparées par une virgule. |
Oui | |
--driver |
Chemin absolu ou relatif au fichier JAR du pilote à utiliser pour cette connexion. Vous pouvez spécifier plusieurs fichiers JAR de pilote en les séparant par une virgule. | Oui | |
--host |
localhost | Nom d'hôte ou adresse IP du serveur de base de données. | No |
--password |
Mot de passe à utiliser pour la connexion à la base de données. | Yes | |
--port |
5480 | Port du serveur de base de données. | No |
--user |
Nom d'utilisateur à utiliser pour la connexion à la base de données. | Yes |
Examples
L'exemple suivant montre comment extraire les métadonnées de deux bases de données IBM Netezza sur un hôte spécifié :
dwh-migration-dumper \
--connector netezza \
--database database1,database2 \
--driver path/nzjdbc.jar \
--host host \
--password password \
--user user
Oracle
Pour autoriser l'outil dwh-migration-dumper
à se connecter à Oracle, téléchargez son pilote JDBC à partir de la page de téléchargement d'Oracle.
Le tableau suivant décrit les options couramment utilisées pour extraire les métadonnées Oracle à l'aide de l'outil d'extraction. Pour en savoir plus sur toutes les options compatibles, consultez la section Options globales.
Nom | Valeur par défaut | Description | Obligatoire |
---|---|---|---|
--connector |
Nom du connecteur à utiliser, dans ce cas oracle. | Yes | |
--driver |
Chemin absolu ou relatif au fichier JAR du pilote à utiliser pour cette connexion. Vous pouvez spécifier plusieurs fichiers JAR de pilote en les séparant par une virgule. | Oui | |
--host |
localhost | Nom d'hôte ou adresse IP du serveur de base de données. | No |
--oracle-service |
Nom du service Oracle à utiliser pour la connexion. |
Pas explicitement, mais vous devez spécifier cette option ou l'option --oracle-sid . |
|
--oracle-sid |
Identifiant système (SID) Oracle à utiliser pour la connexion. |
Pas explicitement, mais vous devez spécifier cette option ou l'option --oracle-service . |
|
--password |
Mot de passe à utiliser pour la connexion à la base de données. | S'il n'est pas spécifié, l'outil d'extraction utilise une invite sécurisée pour le demander. | |
--port |
1521 | Port du serveur de base de données. | No |
--user |
Nom d'utilisateur à utiliser pour la connexion à la base de données.
L'utilisateur que vous spécifiez doit disposer du rôle |
Yes |
Examples
L'exemple suivant montre comment extraire les métadonnées d'une base de données Oracle sur un hôte spécifié, en utilisant le service Oracle pour la connexion :
dwh-migration-dumper \
--connector oracle \
--driver path/ojdbc8.jar \
--host host \
--oracle-service service_name \
--password password \
--user user
Snowflake
Le tableau suivant décrit les options couramment utilisées pour extraire les métadonnées Snowflake à l'aide de l'outil dwh-migration-dumper
. Pour en savoir plus sur tous les options compatibles, consultez la section Options globales.
Nom | Valeur par défaut | Description | Obligatoire |
---|---|---|---|
--connector |
Nom du connecteur à utiliser, dans ce cas Snowflake. | Yes | |
--database |
Nom de la base de données à laquelle se connecter. Vous ne pouvez extraire des données que d'une base de données à la fois à partir de Snowflake. |
Oui | |
--host |
localhost | Nom d'hôte ou adresse IP du serveur de base de données. | No |
--password |
Mot de passe à utiliser pour la connexion à la base de données. | S'il n'est pas spécifié, l'outil d'extraction utilise une invite sécurisée pour le demander. | |
--role |
Rôle Snowflake à utiliser pour l'autorisation. Vous ne devez spécifier cette valeur que pour les installations volumineuses dans lesquelles vous devez obtenir des métadonnées à partir du schéma SNOWFLAKE.ACCOUNT_USAGE au lieu de INFORMATION_SCHEMA . Pour en savoir plus, consultez la section Travailler avec des instances Snowflake volumineuses.
|
No | |
--user |
Nom d'utilisateur à utiliser pour la connexion à la base de données. |
Yes | |
--warehouse |
Entrepôt Snowflake à utiliser pour le traitement des requêtes de métadonnées. |
Yes |
Examples
L'exemple suivant montre comment extraire les métadonnées d'une base de données Snowflake de taille moyenne sur l'hôte local :
dwh-migration-dumper \
--connector snowflake \
--database database \
--password password \
--user user \
--warehouse warehouse
L'exemple suivant montre comment extraire les métadonnées d'unebase de données Snowflake volumineuse sur un hôte spécifié :
dwh-migration-dumper \
--connector snowflake \
--database database \
--host "account.snowflakecomputing.com" \
--password password \
--role role \
--user user \
--warehouse warehouse
Travailler avec des instances Snowflake volumineuses
L'outil dwh-migration-dumper
lit les métadonnées à partir de INFORMATION_SCHEMA
de Snowflake. Cependant, la quantité de données que vous pouvez récupérer dans INFORMATION_SCHEMA
est limitée. Si vous exécutez l'outil d'extraction et recevez l'erreur SnowflakeSQLException:
Information schema query returned too much data
, vous devez effectuer les étapes suivantes pour pouvoir lire les métadonnées du schéma SNOWFLAKE.ACCOUNT_USAGE
:
- Ouvrez l'option Partages dans l'interface Web Snowflake.
Créez une base de données à partir du partage
SNOWFLAKE.ACCOUNT_USAGE
:-- CREATE DATABASE database FROM SHARE SNOWFLAKE.ACCOUNT_USAGE;
Créer un rôle :
CREATE ROLE role;
Accordez les droits
IMPORTED
sur la nouvelle base de données au rôle :GRANT IMPORTED PRIVILEGES ON DATABASE database TO ROLE role;
Attribuez le rôle à l'utilisateur que vous souhaitez utiliser pour exécuter l'outil
dwh-migration-dumper
:GRANT ROLE role TO USER user;
Vertica
Pour autoriser l'outil dwh-migration-dumper
à se connecter à Vertica, téléchargez son pilote JDBC à partir de la page de téléchargement.
Le tableau suivant décrit les options couramment utilisées pour extraire les métadonnées Vertica à l'aide de l'outil d'extraction. Pour en savoir plus sur toutes les options compatibles, consultez la section Options globales.
Nom | Valeur par défaut | Description | Obligatoire |
---|---|---|---|
--connector |
Nom du connecteur à utiliser, dans ce cas Vertica. | Yes | |
--database |
Nom de la base de données à laquelle se connecter. |
Yes | |
--driver |
Chemin absolu ou relatif au fichier JAR du pilote à utiliser pour cette connexion. Vous pouvez spécifier plusieurs fichiers JAR de pilote en les séparant par une virgule. | Oui | |
--host |
localhost | Nom d'hôte ou adresse IP du serveur de base de données. | No |
--password |
Mot de passe à utiliser pour la connexion à la base de données. | Yes | |
--port |
5433 | Port du serveur de base de données. | No |
--user |
Nom d'utilisateur à utiliser pour la connexion à la base de données. | Yes |
Examples
L'exemple suivant montre comment extraire les métadonnées d'une base de données Vertica sur l'hôte local :
dwh-migration-dumper \
--driver path/vertica-jdbc.jar \
--connector vertica \
--database database
--user user
--password password
Options globales
Le tableau suivant décrit les options pouvant être utilisées avec l'une des plates-formes sources compatibles.
Nom | Description |
---|---|
--connector |
Nom de connecteur du système source. |
--database |
L'utilisation varie selon le système source. |
--driver |
Chemin absolu ou relatif au fichier JAR du pilote à utiliser lors de la connexion au système source. Vous pouvez spécifier plusieurs fichiers JAR de pilote en les séparant par une virgule. |
--dry-run ou -n |
Affiche les actions que l'outil d'extraction effectuerait sans les exécuter. |
--help |
Affiche l'aide associée à la ligne de commande. |
--host |
Nom d'hôte ou adresse IP du serveur de base de données auquel se connecter. |
--jdbcDriverClass |
Ignore éventuellement le nom de classe du pilote JDBC spécifié par le fournisseur. Utilisez cette option si vous avez un client JDBC personnalisé. |
--output |
Chemin du fichier ZIP de sortie. Par exemple, dir1/dir2/teradata-metadata.zip . Si vous ne spécifiez pas de chemin, le fichier de sortie est créé dans votre répertoire de travail. Si vous spécifiez le chemin à un répertoire, le nom du fichier ZIP par défaut est créé dans le répertoire spécifié. Si le répertoire n'existe pas, il est créé.
Pour utiliser Cloud Storage, utilisez le format suivant : Pour vous authentifier à l'aide des identifiants Google Cloud, consultez la page S'authentifier à l'aide de bibliothèques clientes. |
--password |
Mot de passe à utiliser pour la connexion à la base de données. |
--port |
Port du serveur de base de données. |
--save-response-file |
Enregistre les flags de ligne de commande dans un fichier JSON afin de les réutiliser facilement. Le fichier est nommé dumper-response-file.json et est créé dans le répertoire de travail. Pour utiliser le fichier de réponse, indiquez le chemin d'accès à celui-ci avec le préfixe @ lorsque vous exécutez l'outil d'extraction, par exemple dwh-migration-dumper @path/to/dumper-response-file.json .
|
--schema |
Liste des schémas à extraire, séparés par une virgule.
Oracle ne fait pas de distinction entre un schéma et l'utilisateur de la base de données qui a créé le schéma. Vous pouvez donc utiliser des noms de schéma ou des noms d'utilisateur avec l'option |
--thread-pool-size |
Définit la taille du pool de threads, qui a une incidence sur la taille du pool de connexions.
La taille par défaut du pool de threads correspond au nombre de cœurs sur le serveur exécutant l'outil Si l'outil d'extraction semble lent ou nécessiter davantage de ressources, vous pouvez augmenter le nombre de threads utilisés. Si des indications signalent que d'autres processus sur le serveur nécessitent davantage de bande passante, vous pouvez réduire le nombre de threads utilisés. |
--url |
URL à utiliser pour la connexion à la base de données, au lieu de l'URI généré par le pilote JDBC. L'URI généré doit être suffisant dans la plupart des cas. Ne remplacez l'URI généré que si vous devez utiliser un paramètre de connexion JDBC qui soit spécifique à la plate-forme source et non défini par l'une des options répertoriées dans ce tableau. |
--user |
Nom d'utilisateur à utiliser pour la connexion à la base de données. |
--version |
Affiche la version du produit. |
Dépannage
Cette section décrit certains problèmes courants et des techniques de dépannage pour l'outil dwh-migration-dumper
.
Erreur de mémoire insuffisante
L'erreur java.lang.OutOfMemoryError
dans la sortie du terminal de l'outil dwh-migration-dumper
est souvent liée à une mémoire insuffisante pour traiter les données récupérées.
Pour résoudre ce problème, augmentez la mémoire disponible ou réduisez le nombre de threads de traitement.
Vous pouvez augmenter la mémoire maximale en exportant la variable d'environnement JAVA_OPTS
:
Linux
export JAVA_OPTS="-Xmx4G"
Windows
set JAVA_OPTS="-Xmx4G"
Vous pouvez réduire le nombre de threads de traitement (32 par défaut) en incluant l'option --thread-pool-size
. Cette option n'est compatible qu'avec les connecteurs hiveql
et redshift*
.
dwh-migration-dumper --thread-pool-size=1
Gérer une erreur WARN...Task failed
Il est possible que l'erreur WARN [main]
o.c.a.d.MetadataDumper [MetadataDumper.java:107] Task failed: …
s'affiche dans la sortie du terminal de l'outil dwh-migration-dumper
. L'outil d'extraction envoie plusieurs requêtes au système source, et la sortie de chaque requête est écrite dans son propre fichier. L'affichage de ce problème indique que l'une de ces requêtes a échoué. Cependant, l'échec d'une requête n'empêche pas l'exécution des autres requêtes. Si vous voyez plusieurs erreurs WARN
, consultez les détails du problème et vérifiez si vous devez corriger certains éléments pour que la requête s'exécute correctement.
Par exemple, si l'utilisateur de base de données que vous avez spécifié lors de l'exécution de l'outil d'extraction ne dispose pas des autorisations nécessaires pour lire toutes les métadonnées, réessayez avec un utilisateur disposant des autorisations appropriées.
Fichier ZIP corrompu
Pour valider le fichier ZIP de l'outil dwh-migration-dumper
, téléchargez le fichier SHA256SUMS.txt
et exécutez la commande suivante :
sha256sum --check SHA256SUMS.txt
Le résultat OK
confirme la réussite de la vérification de la somme de contrôle. Tout autre message indique une erreur de validation :
FAILED: computed checksum did NOT match
: le fichier ZIP est corrompu et doit être téléchargé à nouveau.FAILED: listed file could not be read
: la version du fichier ZIP est introuvable. Assurez-vous que les fichiers de somme de contrôle et les fichiers ZIP sont téléchargés à partir de la même version et placés dans le même répertoire.
L'extraction des journaux de requêtes Teradata est lente
Pour améliorer les performances des tables de jointure spécifiées par les options -Dteradata-logs.query-logs-table
et -Dteradata-logs.sql-logs-table
, vous pouvez inclure une colonne supplémentaire de type DATE
dans la condition JOIN
. Cette colonne doit être définie dans les deux tables et faire partie de l'index principal partitionné. Pour inclure cette colonne, utilisez l'option -Dteradata-logs.log-date-column
.
Exemple :
Bash
dwh-migration-dumper \ -Dteradata-logs.query-logs-table=historicdb.ArchivedQryLogV \ -Dteradata-logs.sql-logs-table=historicdb.ArchivedDBQLSqlTbl \ -Dteradata-logs.log-date-column=ArchiveLogDate
Windows PowerShell
dwh-migration-dumper ` "-Dteradata-logs.query-logs-table=historicdb.ArchivedQryLogV" ` "-Dteradata-logs.sql-logs-table=historicdb.ArchivedDBQLSqlTbl" ` "-Dteradata-logs.log-date-column=ArchiveLogDate"
Limite de taille des lignes Teradata dépassée
La taille des lignes Teradata 15 est limitée à 64 Ko. Si la limite est dépassée, le Dumper échoue avec le message suivant : none
[Error 9804] [SQLState HY000] Response Row size or Constant Row size overflow
Pour résoudre cette erreur, augmentez la limite de lignes à 1 Mo ou divisez les lignes en plusieurs lignes :
- Installez et activez la fonctionnalité "1MB Perm and Response Rows" et le logiciel TTU actuel. Pour en savoir plus, consultez la section Message de base de données Teradata 9804.
- Divisez le long texte de requête en plusieurs lignes à l'aide des options
-Dteradata.metadata.max-text-length
et-Dteradata-logs.max-sql-length
.
La commande suivante illustre l'utilisation de l'option -Dteradata.metadata.max-text-length
pour diviser le long texte de requête en plusieurs lignes comportant au maximum 10 000 caractères chacune :
Bash
dwh-migration-dumper \ --connector teradata \ -Dteradata.metadata.max-text-length=10000
Windows PowerShell
dwh-migration-dumper ` --connector teradata ` "-Dteradata.metadata.max-text-length=10000"
La commande suivante illustre l'utilisation de l'option -Dteradata-logs.max-sql-length
pour diviser le long texte de requête en plusieurs lignes comportant au maximum 10 000 caractères chacune :
Bash
dwh-migration-dumper \ --connector teradata-logs \ -Dteradata-logs.max-sql-length=10000
Windows PowerShell
dwh-migration-dumper ` --connector teradata-logs ` "-Dteradata-logs.max-sql-length=10000"
Étapes suivantes
Après avoir exécuté l'outil dwh-migration-dumper
, importez la sortie dans Cloud Storage ainsi que les fichiers sources pour la traduction.