Générer des métadonnées pour la traduction et l'évaluation

Preview

Ce produit est soumis aux "Conditions des offres de pré-DG" dans la section "Conditions d'utilisation générales" des Conditions spécifiques au service. Les produits pré-DG sont disponibles "en l'état" et peuvent bénéficier d'une assistance limitée. Pour en savoir plus, consultez les descriptions des étapes de lancement.

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
• Greenplum
• Microsoft SQL Server
• IBM Netezza
• Oracle
• PostgreSQL
• 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 :

1. 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'outil dwh-migration-dumper.
2. Pour valider le fichier ZIP de l'outil dwh-migration-dumper, téléchargez le fichier SHA256SUMS.txt et exécutez la commande suivante :

Bash

sha256sum --check SHA256SUMS.txt

Si la validation échoue, consultez la section Dépannage.

Windows PowerShell

(Get-FileHash RELEASE_ZIP_FILENAME).Hash -eq ((Get-Content SHA256SUMS.txt) -Split " ")[0]

Remplacez RELEASE_ZIP_FILENAME par le nom du fichier ZIP téléchargé correspondant à la version de l'outil d'extraction en ligne de commande dwh-migration-dumper (par exemple, dwh-migration-tools-v1.0.52.zip).

Le résultat True confirme la réussite de la vérification de la somme de contrôle.

Le résultat False indique une erreur de validation. Assurez-vous que le fichier de somme de contrôle et le fichier ZIP ont été téléchargés à partir de la même version et placés dans le même répertoire.

1. 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.
2. 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.

Conseil : Lorsque vous utilisez Windows PowerShell, placez les indicateurs entre guillemets doubles, par exemple, dwh-migration-dumper "-Dteradata-logs.utility-logs-table=historicdb.ArchivedUtilityLogs".

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 dwh-migration-dumper 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 les journaux de requêtes, il extrait des colonnes supplémentaires pour l'évaluation de la migration BigQuery.	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 teradata, l'outil dwh-migration-dumper filtre les tables et les vues de métadonnées en fonction de la liste de bases de données fournie. Les exceptions sont les vues DatabasesV et RoleMembersV. L'outil dwh-migration-dumper extrait les bases de données et les utilisateurs de ces vues sans filtrer par nom de base de données. Cette option ne peut pas être utilisée conjointement avec le connecteur teradata-logs. Les journaux de requête sont toujours extraits pour toutes les bases de données.	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.	Non
--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.	Non
--user		Nom d'utilisateur à utiliser pour la connexion à la base de données.	Oui
--query-log-alternates		Pour le connecteur teradata-logs uniquement. Pour extraire les journaux de requête depuis un autre emplacement, nous vous recommandons d'utiliser plutôt les options -Dteradata-logs.query-logs-table et -Dteradata-logs.sql-logs-table. Par défaut, les journaux de requête sont extraits des tables dbc.DBQLogTbl et dbc.DBQLSQLTbl. Si vous utilisez l'option --assessment, les journaux de requête sont extraits de la vue dbc.QryLogV et de la table dbc.DBQLSQLTbl. Si vous devez extraire les journaux de requête à partir d'un autre emplacement, vous pouvez spécifier les noms complets des tables ou des vues à l'aide de l'option --query-log-alternates. Le premier paramètre désigne l'alternative à la table dbc.DBQLogTbl et le second paramètre l'alternative à la table dbc.DBQLSQLTbl. Ils sont tous les deux obligatoires. L'option -Dteradata-logs.log-date-column peut être utilisée pour améliorer les performances d'extraction lorsque les deux tables ont une colonne indexée de type DATE. Exemple : --query-log-alternates historicdb.ArchivedQryLogV,historicdb.ArchivedDBQLSqlTbl	Non
-Dteradata.tmode		Mode de transaction de la connexion. Les valeurs suivantes sont acceptées : ANSI : mode ANSI. Il s'agit du mode par défaut (si l'option n'est pas spécifiée). TERA : mode de transaction Teradata (BTET). DEFAULT : utilisez le mode de transaction par défaut configuré sur le serveur de base de données. NONE : aucun mode n'est défini pour la connexion. Exemple (Bash) : -Dteradata.tmode=TERA Exemple (Windows PowerShell) : "-Dteradata.tmode=TERA"	Non
-Dteradata-logs.log-date-column		Pour le connecteur teradata-logs uniquement. 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é. Exemple (Bash) : -Dteradata-logs.log-date-column=ArchiveLogDate Exemple (Windows PowerShell) : "-Dteradata-logs.log-date-column=ArchiveLogDate"	Non
-Dteradata-logs.query-logs-table		Pour le connecteur teradata-logs uniquement. Par défaut, les journaux de requête sont extraits de la table dbc.DBQLogTbl. Si vous utilisez l'option --assessment, les journaux de requête sont extraits de la vue dbc.QryLogV. Si vous devez extraire les journaux de requête depuis un autre emplacement, vous pouvez spécifier le nom complet de la table ou de la vue à l'aide de cette option. Renseignez-vous sur l'option -Dteradata-logs.log-date-column pour améliorer les performances d'extraction. Exemple (Bash) : -Dteradata-logs.query-logs-table=historicdb.ArchivedQryLogV Exemple (Windows PowerShell) : "-Dteradata-logs.query-logs-table=historicdb.ArchivedQryLogV"	Non
-Dteradata-logs.sql-logs-table		Pour le connecteur teradata-logs uniquement. Par défaut, les journaux de requête contenant le texte SQL sont extraits de la table dbc.DBQLSqlTbl. Si vous devez les extraire depuis un autre emplacement, vous pouvez spécifier le nom complet de la table ou de la vue à l'aide de cette option. Renseignez-vous sur l'option -Dteradata-logs.log-date-column pour améliorer les performances d'extraction. Exemple (Bash) : -Dteradata-logs.sql-logs-table=historicdb.ArchivedDBQLSqlTbl Exemple (Windows PowerShell) : "-Dteradata-logs.sql-logs-table=historicdb.ArchivedDBQLSqlTbl"	Non
-Dteradata-logs.utility-logs-table		Pour le connecteur teradata-logs uniquement. Par défaut, les journaux utilitaires sont extraits de la table dbc.DBQLUtilityTbl. Si vous devez extraire ces journaux utilitaires à partir d'un autre emplacement, vous pouvez spécifier le nom complet de la table à l'aide de l'option -Dteradata-logs.utility-logs-table. Exemple (Bash) : -Dteradata-logs.utility-logs-table=historicdb.ArchivedUtilityLogs Exemple (Windows PowerShell) : "-Dteradata-logs.utility-logs-table=historicdb.ArchivedUtilityLogs"	Non
-Dteradata-logs.res-usage-scpu-table		Pour le connecteur teradata-logs uniquement. Par défaut, les journaux d'utilisation des ressources SCPU sont extraits de la table dbc.ResUsageScpu. Si vous devez les extraire d'un autre emplacement, vous pouvez spécifier le nom complet de la table à l'aide de l'option -Dteradata-logs.res-usage-scpu-table. Exemple (Bash) : -Dteradata-logs.res-usage-scpu-table=historicdb.ArchivedResUsageScpu Exemple (Windows PowerShell) : "-Dteradata-logs.res-usage-scpu-table=historicdb.ArchivedResUsageScpu"	Non
-Dteradata-logs.res-usage-spma-table		Pour le connecteur teradata-logs uniquement. Par défaut, les journaux d'utilisation des ressources SPMA sont extraits de la table dbc.ResUsageSpma. Si vous devez extraire ces journaux à partir d'un autre emplacement, vous pouvez spécifier le nom complet de la table à l'aide de l'option -Dteradata-logs.res-usage-spma-table. Exemple (Bash) : -Dteradata-logs.res-usage-spma-table=historicdb.ArchivedResUsageSpma Exemple (Windows PowerShell) : "-Dteradata-logs.res-usage-spma-table=historicdb.ArchivedResUsageSpma"	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 : --query-log-start "2023-01-01 14:00:00"	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 : --query-log-end "2023-01-15 22:00:00"	Non
-Dteradata.metadata.tablesizev.max-rows		Pour le connecteur teradata uniquement. Limitez le nombre de lignes extraites de la vue TableSizeV. Les lignes sont regroupées par colonnes.DatabaseName, AccountName et TableName, puis triées par ordre décroissant de la taille de l'espace permanent (l'expression SUM(CurrentPerm)). Le nombre de lignes spécifié est ensuite extrait. Exemple (Bash) : -Dteradata.metadata.tablesizev.max-rows=100000 Exemple (Windows PowerShell) : "-Dteradata.metadata.tablesizev.max-rows=100000"	Non
-Dteradata.metadata.diskspacev.max-rows		Pour le connecteur teradata uniquement. Limitez le nombre de lignes extraites de la vue DiskSpaceV. Les lignes sont triées par ordre décroissant de la taille de l'espace permanent (colonne CurrentPerm), puis le nombre de lignes spécifié est extrait. Exemple (Bash) : -Dteradata.metadata.diskspacev.max-rows=100000 Exemple (Windows PowerShell) : "-Dteradata.metadata.diskspacev.max-rows=100000"	Non
-Dteradata.metadata.databasesv.users.max-rows		Pour le connecteur teradata uniquement. Limitez le nombre de lignes représentant les utilisateurs (DBKind='U') extraits de la vue DatabasesV. Les lignes de la colonne PermSpace sont triées par ordre décroissant, puis le nombre de lignes spécifié est extrait. Exemple (Bash) : -Dteradata.metadata.databasesv.users.max-rows=100000 Exemple (Windows PowerShell) : "-Dteradata.metadata.databasesv.users.max-rows=100000"	Non
-Dteradata.metadata.databasesv.dbs.max-rows		Pour le connecteur teradata uniquement. Limitez le nombre de lignes représentant les bases de données (DBKind='D') extraites de la vue DatabasesV. Les lignes de la colonne PermSpace sont triées par ordre décroissant, puis le nombre de lignes spécifié est extrait. Exemple (Bash) : -Dteradata.metadata.databasesv.dbs.max-rows=100000 Exemple (Windows PowerShell) : "-Dteradata.metadata.databasesv.dbs.max-rows=100000"	Non
-Dteradata.metadata.max-text-length		Pour le connecteur teradata uniquement. Longueur maximale de la colonne de texte lors de l'extraction des données de la vue TableTextV. Le texte dépassant la limite définie sera divisé en plusieurs lignes. Plage autorisée : comprise entre 5 000 et 32 000 (inclus). Exemple (Bash) : -Dteradata.metadata.max-text-length=10000 Exemple (Windows PowerShell) : "-Dteradata.metadata.max-text-length=10000"	Non
-Dteradata-logs.max-sql-length		Pour le connecteur teradata-logs uniquement. Longueur maximale de la colonne DBQLSqlTbl.SqlTextInfo. Le texte de requête dépassant la limite définie sera divisé en plusieurs lignes. Plage autorisée : comprise entre 5 000 et 31 000 (inclus). Exemple (Bash) : -Dteradata-logs.max-sql-length=10000 Exemple (Windows PowerShell) : "-Dteradata-logs.max-sql-length=10000"	Non

Exemples

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é par DBC.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.	Oui
--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.	Non
--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.	Non
--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 à AKIAIOSFODNN7EXAMPLE. Utilisez cette option conjointement avec l'option --iam-secretaccesskey. N'utilisez pas cette option lorsque vous spécifiez les options --iam-profile ou --password.	Pas explicitement, mais vous devez fournir des informations d'authentification via l'une des méthodes suivantes : Utiliser cette option conjointement avec l'option --iam-secretaccesskey Utiliser l'option --iam-profile Utiliser l'option --password conjointement avec l'option --user
--iam-profile		Profil AWS IAM à utiliser pour l'authentification. Pour récupérer une valeur de profil à utiliser, examinez le fichier $HOME/.aws/credentials ou exécutez aws configure list-profiles. N'utilisez pas cette option avec les options --iam-accesskeyid, --iam-secretaccesskey ou --password.	Pas explicitement, mais vous devez fournir des informations d'authentification via l'une des méthodes suivantes : Utiliser cette option Utiliser l'option --iam-accesskeyid conjointement avec l'option --iam-secretaccesskey Utiliser l'option --password conjointement avec l'option --user
--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 à wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY. Utilisez cette option conjointement avec l'option --iam-accesskeyid. N'utilisez pas cette option avec les options --iam-profile ou --password.	Pas explicitement, mais vous devez fournir des informations d'authentification via l'une des méthodes suivantes : Utiliser cette option conjointement avec l'option --iam-accesskeyid Utiliser l'option --iam-profile Utiliser l'option --password conjointement avec l'option --user
--password		Mot de passe à utiliser pour la connexion à la base de données. N'utilisez pas cette option avec les options --iam-accesskeyid, --iam-secretaccesskey ou --iam-profile.	Pas explicitement, mais vous devez fournir des informations d'authentification via l'une des méthodes suivantes : Utiliser cette option conjointement avec l'option --user Utiliser l'option --iam-accesskeyid conjointement avec l'option --iam-secretaccesskey Utiliser l'option --password
--port	5439	Port du serveur de base de données.	Non
--user		Nom d'utilisateur à utiliser pour la connexion à la base de données.	Oui
--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 : --query-log-start "2023-01-01 14:00:00"	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 : --query-log-end "2023-01-15 22:00:00"	Non

Exemples

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 dwh-migration-dumper 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.	Obligatoire pour l'évaluation. Non obligatoire pour la traduction.
--connector		Nom du connecteur à utiliser, dans ce cas hiveql.	Oui
--hive-metastore-dump-partition-metadata	true	Il force l'outil dwh-migration-dumper à extraire les métadonnées de la partition. Vous pouvez définir cette option sur false pour le métastore de production comportant un nombre important de partitions, en raison des implications en termes de performances du client Thrift. Cela améliore les performances de l'outil d'extraction, mais entraîne une perte d'optimisation des partitions côté BigQuery. N'utilisez pas cette option avec l'option --assessment, car elle n'aura aucun effet.	Non
--hive-metastore-version	2.3.6	Lorsque vous exécutez l'outil dwh-migration-dumper, il sélectionne la spécification Thrift appropriée à utiliser pour communiquer avec votre serveur Apache Hive, en fonction de la valeur de cette option. Si l'outil d'extraction ne dispose pas d'une spécification Thrift appropriée, il utilise le client 2.3.6 et envoie un avertissement à stdout. Si cela se produit, contactez l'assistance et indiquez le numéro de version Apache Hive que vous avez demandé.	Non
--host	localhost	Nom d'hôte ou adresse IP du serveur de base de données.	Non
--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 dwh-migration-dumper. Doit être égale à la valeur du paramètre hadoop.rpc.protection dans le fichier /etc/hadoop/conf/core-site.xml du cluster, avec l'une des valeurs suivantes : authentication integrity privacy Exemple (Bash) : -Dhiveql.rpc.protection=privacy Exemple (Windows PowerShell) : "-Dhiveql.rpc.protection=privacy"	Obligatoire pour les clusters avec l'authentification Kerberos activée.

Exemples

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.	Oui
--database		Nom de la base de données à laquelle se connecter.	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.	Non
--password		Mot de passe à utiliser pour la connexion à la base de données.	Oui
--port	1433	Port du serveur de base de données.	Non
--user		Nom d'utilisateur à utiliser pour la connexion à la base de données.	Oui

Exemples

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

Greenplum

Pour autoriser l'outil dwh-migration-dumper à se connecter à Greenplum, téléchargez son pilote JDBC à partir de la page de téléchargement de VMware Greenplum.

Le tableau suivant décrit les options couramment utilisées pour extraire les métadonnées Greenplum à 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 greenplum.	Oui
--database		Nom de la base de données à laquelle se connecter.	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.	Non
--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	5432	Port du serveur de base de données.	Non
--user		Nom d'utilisateur à utiliser pour la connexion à la base de données.	Oui

Exemples

L'exemple suivant montre comment extraire les métadonnées d'une base de données Greenplum sur un hôte spécifié :

dwh-migration-dumper \
  --connector greenplum \
  --database database \
  --driver path/greenplum.jar \
  --host host \
  --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.	Non
--password		Mot de passe à utiliser pour la connexion à la base de données.	Oui
--port	5480	Port du serveur de base de données.	Non
--user		Nom d'utilisateur à utiliser pour la connexion à la base de données.	Oui

Exemples

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

PostgreSQL

Pour autoriser l'outil dwh-migration-dumper à se connecter à PostgreSQL, téléchargez son pilote JDBC à partir de la page de téléchargement de PostgreSQL.

Le tableau suivant décrit les options couramment utilisées pour extraire les métadonnées PostgreSQL à 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 postgresql.	Oui
--database		Nom de la base de données à laquelle se connecter.	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.	Non
--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	5432	Port du serveur de base de données.	Non
--user		Nom d'utilisateur à utiliser pour la connexion à la base de données.	Oui

Exemples

L'exemple suivant montre comment extraire les métadonnées d'une base de données PostgreSQL sur un hôte spécifié :

dwh-migration-dumper \
  --connector postgresql \
  --database database \
  --driver path/postgresql-version.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.	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.	Non
--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.	Non
--user		Nom d'utilisateur à utiliser pour la connexion à la base de données. L'utilisateur que vous spécifiez doit disposer du rôle SELECT_CATALOG_ROLE pour extraire les métadonnées. Pour savoir si l'utilisateur dispose du rôle requis, exécutez la requête select granted_role from user_role_privs; sur la base de données Oracle.	Oui

Exemples

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.	Oui
--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.	Non
--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.	Non
--user		Nom d'utilisateur à utiliser pour la connexion à la base de données.	Oui
--warehouse		Entrepôt Snowflake à utiliser pour le traitement des requêtes de métadonnées.	Oui

Exemples

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 :

1. Ouvrez l'option Partages dans l'interface Web Snowflake.

2. Créez une base de données à partir du partage SNOWFLAKE.ACCOUNT_USAGE :

   -- CREATE DATABASE database FROM SHARE SNOWFLAKE.ACCOUNT_USAGE;
   

3. Créer un rôle :

   CREATE ROLE role;
   

4. Accordez les droits IMPORTED sur la nouvelle base de données au rôle :

   GRANT IMPORTED PRIVILEGES ON DATABASE database TO ROLE role;
   

5. 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.	Oui
--database		Nom de la base de données à laquelle se connecter.	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.	Non
--password		Mot de passe à utiliser pour la connexion à la base de données.	Oui
--port	5433	Port du serveur de base de données.	Non
--user		Nom d'utilisateur à utiliser pour la connexion à la base de données.	Oui

Exemples

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 : gs://<BUCKET>/<PATH> 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 --schema. Par exemple, --schema schema1,user2,schema3.
--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 dwh-migration-dumper. 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 :

Bash

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 le fichier de somme de contrôle et le fichier ZIP ont été téléchargés à partir de la même version et placés dans le même répertoire.

Windows PowerShell

(Get-FileHash RELEASE_ZIP_FILENAME).Hash -eq ((Get-Content SHA256SUMS.txt) -Split " ")[0]

Remplacez RELEASE_ZIP_FILENAME par le nom du fichier ZIP téléchargé correspondant à la version de l'outil d'extraction en ligne de commande dwh-migration-dumper (par exemple, dwh-migration-tools-v1.0.52.zip).

Le résultat True confirme la réussite de la vérification de la somme de contrôle.

Le résultat False indique une erreur de validation. Assurez-vous que le fichier de somme de contrôle et le fichier ZIP ont été 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"

Problème de connexion Oracle

Dans les cas courants, comme un mot de passe ou un nom d'hôte non valides, l'outil dwh-migration-dumper affiche un message d'erreur pertinent décrivant le problème sous-jacent. Toutefois, dans certains cas, le message d'erreur renvoyé par le serveur Oracle peut être générique et difficile à analyser.

L'un de ces problèmes est IO Error: Got minus one from a read call. Cette erreur indique que la connexion au serveur Oracle a été établie, mais que le serveur n'a pas accepté le client et a fermé la connexion. Ce problème se produit généralement lorsque le serveur n'accepte que les connexions TCPS. Par défaut, l'outil dwh-migration-dumper utilise le protocole TCP. Pour résoudre ce problème, vous devez remplacer l'URL de connexion JDBC Oracle.

Au lieu de fournir les options oracle-service, host et port, vous pouvez résoudre ce problème en fournissant l'option url au format suivant : jdbc:oracle:thin:@tcps://{HOST_NAME}:{PORT}/{ORACLE_SERVICE}. En règle générale, le numéro de port TCPS utilisé par le serveur Oracle est 2484.

Exemple de commande de dumper:

  dwh-migration-dumper \
    --connector oracle-stats \
    --url "jdbc:oracle:thin:@tcps://host:port/oracle_service" \
    --assessment \
    --driver "jdbc_driver_path" \
    --user "user" \
    --password

En plus de modifier le protocole de connexion en TCPS, vous devrez peut-être fournir la configuration SSL du trustStore requise pour valider le certificat du serveur Oracle. Si aucune configuration SSL n'est définie, un message d'erreur Unable to find valid certification path s'affiche. Pour résoudre ce problème, définissez la variable d'environnement JAVA_OPTS:

  set JAVA_OPTS=-Djavax.net.ssl.trustStore="jks_file_location" -Djavax.net.ssl.trustStoreType=JKS -Djavax.net.ssl.trustStorePassword="password"

Selon la configuration de votre serveur Oracle, vous devrez peut-être également fournir la configuration du keystore. Pour en savoir plus sur les options de configuration, consultez SSL avec le pilote JDBC Oracle.

Étape suivante

Après avoir exécuté l'outil dwh-migration-dumper, importez la sortie dans Cloud Storage ainsi que les fichiers sources pour la traduction.