Gerar metadados para tradução e avaliação

Visualização

Este produto está sujeito aos "Termos de ofertas pré-GA" na seção "Termos de Serviço Gerais" dos Termos Específicos do Serviço. Os produtos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Neste documento, descrevemos como criar metadados e arquivos de registros de consultas usando a ferramenta de linha de comando dwh-migration-dumper. Os arquivos de metadados descrevem os objetos SQL no sistema de origem.

O serviço de migração do BigQuery usa essas informações para melhorar a conversão dos scripts SQL do dialeto do sistema de origem para o GoogleSQL.

A avaliação de migração do BigQuery usa arquivos de metadados e de registro de consulta para analisar seu data warehouse atual e ajudar a avaliar o esforço de migrar o data warehouse para o BigQuery.

Informações gerais

Use a ferramenta dwh-migration-dumper para extrair informações de metadados da plataforma de banco de dados que você está migrando para o BigQuery. Não é necessário usar a ferramenta de extração não é necessária para a avaliação de migração do BigQuery. Recomendamos usá-la para todas as tarefas de migração.

Para conferir mais informações, consulte Criar arquivos de metadados.

É possível usar a ferramenta dwh-migration-dumper para extrair metadados das seguintes plataformas de banco de dados:

• Teradata
• Amazon Redshift
• Apache Hive
• Apache Spark
• Azure Synapse
• Microsoft SQL Server
• IBM Netezza
• Oracle
• Snowflake
• Trino ou PrestoSQL
• Vertica

Para a maioria desses bancos de dados, também é possível extrair registros de consulta.

A ferramenta dwh-migration-dumper consulta tabelas do sistema para reunir instruções de linguagem de definição de dados (DDL) relacionadas a bancos de dados do usuário e do sistema. Ele não consulta o conteúdo de bancos de dados de usuários. A ferramenta salva as informações de metadados das tabelas do sistema como arquivos CSV e, em seguida, compacta esses arquivos em um único pacote. Depois disso, você faz upload desse arquivo ZIP no Cloud Storage ao fazer upload dos arquivos de origem para tradução ou avaliação.

Ao usar a opção de registros de consulta, a ferramenta dwh-migration-dumper consulta nas tabelas do sistema as instruções DDL e os registros de consultas relacionados a bancos de dados do usuário e do sistema. Eles são salvos em formato CSV ou yaml em um subdiretório e compactados em um pacote ZIP. O conteúdo dos bancos de dados do usuário não é consultado em nenhum momento. A avaliação de migração do BigQuery requer arquivos CSV, YAML e de texto para registros de consulta. Por isso, descompacte todos esses arquivos no arquivo ZIP e faça upload para avaliação.

A ferramenta dwh-migration-dumper pode ser executada no Windows, macOS e Linux.

A ferramenta dwh-migration-dumper está disponível sob a licença Apache 2.

Se você optar por não usar a ferramenta dwh-migration-dumper para tradução, forneça manualmente arquivos de metadados coletando as instruções da linguagem de definição de dados (DDL, na sigla em inglês) dos objetos SQL no seu sistema de origem em arquivos de texto separados.

É necessário fornecer metadados e registros de consulta extraídos com a ferramenta para fazer a avaliação da migração com o BigQuery.

Requisitos de conformidade

Fornecemos o binário da ferramenta dwh-migration-dumper compilado para facilitar o uso. Se você precisa auditar a ferramenta para garantir que ela atende aos requisitos de conformidade, analise o código-fonte do repositório da ferramenta dwh-migration-dumper do GitHub. e compilar seu próprio binário.

Pré-requisitos

Instalar o Java

O servidor em que você planeja executar a ferramenta dwh-migration-dumper precisa ter o Java 8 ou mais recente instalado. Caso contrário, faça o download do Java da página de downloads do Java e instale-o.

Permissões necessárias

A conta de usuário especificada para conectar a ferramenta dwh-migration-dumper ao sistema de origem precisa ter permissões para ler metadados desse sistema. Confirme se essa conta tem os papéis apropriados para consultar os recursos de metadados disponíveis na sua plataforma. Por exemplo, INFORMATION_SCHEMA é um recurso de metadados comum em várias plataformas.

Instalar a ferramenta dwh-migration-dumper

Para instalar a ferramenta dwh-migration-dumper, siga estas etapas:

1. Na máquina em que você quer executar a ferramenta dwh-migration-dumper, faça o download do arquivo ZIP do repositório do GitHub da ferramenta dwh-migration-dumper.
2. Faça o download do arquivo SHA256SUMS.txt e execute o seguinte comando:

   sha256sum --check SHA256SUMS.txt
   

   Se a verificação falhar, consulte a Solução de problemas.
3. Extraia o arquivo ZIP. O binário da ferramenta /bin está no subdiretório da pasta criada extraindo o arquivo ZIP.
4. Atualize a variável de ambiente PATH para incluir o caminho de instalação da ferramenta.

Execute a ferramenta dwh-migration-dumper

A ferramenta dwh-migration-dumper usa o seguinte formato:

dwh-migration-dumper [FLAGS]

A execução da ferramenta dwh-migration-dumper cria um arquivo de saída chamado dwh-migration-<source platform>-metadata.zip, por exemplo, dwh-migration-teradata-metadata.zip, no seu diretório de trabalho.

Dica: ao usar o Windows PowerShell, coloque as flags entre aspas duplas. Por exemplo, dwh-migration-dumper "-Dteradata-logs.utility-logs-table=historicdb.ArchivedUtilityLogs".

Use as instruções a seguir para saber como executar a ferramenta dwh-migration-dumper para sua plataforma de origem.

Teradata

Para permitir que a ferramenta dwh-migration-dumper se conecte ao Teradata, faça o download do driver JDBC na página de download do Teradata.

A tabela a seguir descreve as sinalizações mais usadas para extrair metadados e registros de consulta do Teradata com a ferramenta de extração. Para informações sobre todas as sinalizações compatíveis, consulte Sinalizações globais.

Nome	Valor padrão	Descrição	Obrigatório
--assessment		Ativa o modo de avaliação ao gerar registros do banco de dados ou extrair metadados. A ferramenta dwh-migration-dumper gera as estatísticas de metadados necessárias para avaliação de migração do BigQuery quando usada para extração de metadados. Quando usada para registros de consulta, ela extrai colunas adicionais para a avaliação de migração do BigQuery.	Obrigatória para a execução de avaliações, mas não para tradução.
--connector		O nome do conector a ser usado. Neste caso, teradata para metadados ou teradata-logs para registros de consulta.	Sim
--database		Uma lista dos bancos de dados a serem despejados, separados por vírgulas. Os nomes dos bancos de dados podem diferenciar maiúsculas de minúsculas, dependendo da configuração do servidor do Teradata. Se essa sinalização for usada em combinação com o conector teradata, a ferramenta dwh-migration-dumper vai filtrar as tabelas e visualizações de metadados pela lista de bancos de dados fornecida. As exceções são as visualizações DatabasesV e RoleMembersV. A ferramenta dwh-migration-dumper extrai os bancos de dados e os usuários dessas visualizações sem filtrar pelo nome do banco de dados. Essa sinalização não pode ser usada em combinação com o conector teradata-logs. Os registros de consulta são sempre extraídos para todos os bancos de dados.	Não
--driver		O caminho absoluto ou relativo para o arquivo JAR do driver a ser usado para essa conexão. É possível especificar vários arquivos JAR do driver, separando-os por vírgulas.	Sim
--host	localhost	O nome do host ou o endereço IP do servidor de banco de dados.	Não
--password		A senha a ser usada na conexão do banco de dados.	Se não for especificada, a ferramenta usará uma solicitação segura para solicitá-la.
--port	1025	A porta do servidor de banco de dados.	Não
--user		O nome de usuário a ser usado na conexão do banco de dados.	Sim
--query-log-alternates		Apenas para o conector teradata-logs. Para extrair os registros de consulta de um local alternativo, recomendamos o uso das flags -Dteradata-logs.query-logs-table e -Dteradata-logs.sql-logs-table. Por padrão, os registros de consulta são extraídos das tabelas dbc.DBQLogTbl e dbc.DBQLSQLTbl. Se você usar a sinalização --assessment, os registros de consulta serão extraídos da visualização dbc.QryLogV e da tabela dbc.DBQLSQLTbl. Se você precisar extrair os registros de consulta de um local alternativo, especifique os nomes totalmente qualificados das tabelas ou visualizações usando a sinalização --query-log-alternates. O primeiro parâmetro faz referência à alternativa à tabela dbc.DBQLogTbl, e o segundo faz referência à alternativa à tabela dbc.DBQLSQLTbl. Os dois parâmetros são obrigatórios. A flag -Dteradata-logs.log-date-column pode ser usada para melhorar o desempenho da extração quando as duas tabelas têm uma coluna indexada do tipo DATE. Exemplo: --query-log-alternates historicdb.ArchivedQryLogV,historicdb.ArchivedDBQLSqlTbl	Não
-Dteradata.tmode		O modo de transação da conexão. Os valores a seguir são compatíveis: ANSI: modo ANSI. Este é o modo padrão (se a sinalização não for especificada). TERA: modo de transação do Teradata (BTET) DEFAULT: usa o modo de transação padrão configurado no servidor de banco de dados. NONE: nenhum modo está definido para a conexão. Exemplo (Bash): -Dteradata.tmode=TERA Exemplo (Windows PowerShell): "-Dteradata.tmode=TERA"	Não
-Dteradata-logs.log-date-column		Apenas para o conector teradata-logs. Para melhorar o desempenho da mesclagem de tabelas especificadas pelas flags -Dteradata-logs.query-logs-table e -Dteradata-logs.sql-logs-table, inclua mais uma coluna do tipo DATE na condição JOIN. Essa coluna precisa ser definida em ambas as tabelas e fazer parte do índice primário particionado. Exemplo (Bash): -Dteradata-logs.log-date-column=ArchiveLogDate Exemplo (Windows PowerShell): "-Dteradata-logs.log-date-column=ArchiveLogDate"	Não
-Dteradata-logs.query-logs-table		Apenas para o conector teradata-logs. Por padrão, os registros da consulta são extraídos da tabela dbc.DBQLogTbl. Se você usar a flag --assessment, os registros de consulta serão extraídos da visualização dbc.QryLogV. Se for necessário extrair os registros de consulta de um local alternativo, especifique o nome totalmente qualificado da tabela ou visualização usando essa flag. Consulte a flag -Dteradata-logs.log-date-column para melhorar o desempenho da extração. Exemplo (Bash): -Dteradata-logs.query-logs-table=historicdb.ArchivedQryLogV Exemplo (Windows PowerShell): "-Dteradata-logs.query-logs-table=historicdb.ArchivedQryLogV"	Não
-Dteradata-logs.sql-logs-table		Apenas para o conector teradata-logs. Por padrão, os registros de consulta que contêm texto SQL são extraídos da tabela dbc.DBQLSqlTbl. Se você precisar extraí-las de um local alternativo, especifique o nome totalmente qualificado da tabela ou visualização usando essa flag. Consulte a flag -Dteradata-logs.log-date-column para melhorar o desempenho da extração. Exemplo (Bash): -Dteradata-logs.sql-logs-table=historicdb.ArchivedDBQLSqlTbl Exemplo (Windows PowerShell): "-Dteradata-logs.sql-logs-table=historicdb.ArchivedDBQLSqlTbl"	Não
-Dteradata-logs.utility-logs-table		Apenas para o conector teradata-logs. Por padrão, os registros do utilitário são extraídos da tabela dbc.DBQLUtilityTbl. Se você precisar extrair os registros do utilitário de um local alternativo, especifique o nome totalmente qualificado da tabela usando a flag -Dteradata-logs.utility-logs-table. Exemplo (Bash): -Dteradata-logs.utility-logs-table=historicdb.ArchivedUtilityLogs Exemplo (Windows PowerShell): "-Dteradata-logs.utility-logs-table=historicdb.ArchivedUtilityLogs"	Não
-Dteradata-logs.res-usage-scpu-table		Apenas para o conector teradata-logs. Por padrão, os registros de uso de recursos da SCPU são extraídos da tabela dbc.ResUsageScpu. Se você precisar extraí-los de um local alternativo, especifique o nome totalmente qualificado da tabela usando a flag -Dteradata-logs.res-usage-scpu-table. Exemplo (Bash): -Dteradata-logs.res-usage-scpu-table=historicdb.ArchivedResUsageScpu Exemplo (Windows PowerShell): "-Dteradata-logs.res-usage-scpu-table=historicdb.ArchivedResUsageScpu"	Não
-Dteradata-logs.res-usage-spma-table		Apenas para o conector teradata-logs. Por padrão, os registros de uso de recursos SPMA são extraídos da tabela dbc.ResUsageSpma. Se você precisar extrair esses registros de um local alternativo, especifique o nome totalmente qualificado da tabela usando a flag -Dteradata-logs.res-usage-spma-table. Exemplo (Bash): -Dteradata-logs.res-usage-spma-table=historicdb.ArchivedResUsageSpma Exemplo (Windows PowerShell): "-Dteradata-logs.res-usage-spma-table=historicdb.ArchivedResUsageSpma"	Não
--query-log-start		O horário de início (inclusivo) dos registros de consulta que serão extraídos. O valor é truncado com a hora. Essa sinalização só está disponível para o conector teradata-logs. Exemplo: --query-log-start "2023-01-01 14:00:00"	Não
--query-log-end		O horário de término (exclusivo) para extrair os registros da consulta. O valor é truncado com a hora. Essa sinalização só está disponível para o conector teradata-logs. Exemplo: --query-log-end "2023-01-15 22:00:00"	Não
-Dteradata.metadata.tablesizev.max-rows		Apenas para o conector teradata. Limite o número de linhas extraídas da visualização TableSizeV. As linhas são agrupadas pelas colunas DatabaseName AccountName e TableName e classificadas em ordem decrescente de acordo com o tamanho do espaço permanente (a expressão SUM(CurrentPerm)). Em seguida, o número especificado de linhas é extraído. Exemplo (Bash): -Dteradata.metadata.tablesizev.max-rows=100000 Exemplo (Windows PowerShell): "-Dteradata.metadata.tablesizev.max-rows=100000"	Não
-Dteradata.metadata.diskspacev.max-rows		Apenas para o conector teradata. Limite o número de linhas extraídas da visualização DiskSpaceV. As linhas são classificadas em ordem decrescente de acordo com o tamanho do espaço permanente (coluna CurrentPerm) e, em seguida, o número especificado de linhas é extraído. Exemplo (Bash): -Dteradata.metadata.diskspacev.max-rows=100000 Exemplo (Windows PowerShell): "-Dteradata.metadata.diskspacev.max-rows=100000"	Não
-Dteradata.metadata.databasesv.users.max-rows		Apenas para o conector teradata. Limite o número de linhas que representam usuários (DBKind='U') que são extraídas da visualização DatabasesV. As linhas são classificadas em ordem decrescente pela coluna PermSpace e, em seguida, o número especificado de linhas é extraído. Exemplo (Bash): -Dteradata.metadata.databasesv.users.max-rows=100000 Exemplo (Windows PowerShell): "-Dteradata.metadata.databasesv.users.max-rows=100000"	Não
-Dteradata.metadata.databasesv.dbs.max-rows		Apenas para o conector teradata. Limite o número de linhas que representam bancos de dados (DBKind='D') que são extraídos da visualização DatabasesV. As linhas são classificadas em ordem decrescente pela coluna PermSpace e, em seguida, o número especificado de linhas é extraído. Exemplo (Bash): -Dteradata.metadata.databasesv.dbs.max-rows=100000 Exemplo (Windows PowerShell): "-Dteradata.metadata.databasesv.dbs.max-rows=100000"	Não
-Dteradata.metadata.max-text-length		Apenas para o conector teradata. Tamanho máximo da coluna de texto ao extrair os dados da visualização TableTextV. O texto maior que o limite definido será dividido em várias linhas. Intervalo permitido: entre 5.000 e 32.000 (inclusive). Exemplo (Bash): -Dteradata.metadata.max-text-length=10000 Exemplo (Windows PowerShell): "-Dteradata.metadata.max-text-length=10000"	Não
-Dteradata-logs.max-sql-length		Apenas para o conector teradata-logs. Comprimento máximo da coluna DBQLSqlTbl.SqlTextInfo. O texto da consulta mais longo que o limite definido será dividido em várias linhas. Intervalo permitido: entre 5.000 e 31.000 (inclusive). Exemplo (Bash): -Dteradata-logs.max-sql-length=10000 Exemplo (Windows PowerShell): "-Dteradata-logs.max-sql-length=10000"	Não

Examples

O exemplo a seguir mostra como despejar metadados de dois bancos de dados do Teradata no host local:

dwh-migration-dumper \
  --connector teradata \
  --user user \
  --password password \
  --database database1,database2 \
  --driver path/terajdbc4.jar

O exemplo a seguir mostra como despejar registros de consulta para avaliação no host local para autenticação:

dwh-migration-dumper \
  --connector teradata-logs \
  --assessment \
  --user user \
  --password password \
  --driver path/terajdbc4.jar

Tabelas e visualizações extraídas pela ferramenta dwh-migration-dumper

As tabelas e visualizações a seguir são extraídas quando você usa o conector teradata:

• DBC.ColumnsV
• DBC.DatabasesV
• DBC.DBCInfo
• DBC.FunctionsV
• DBC.IndicesV
• DBC.PartitioningConstraintsV
• DBC.TablesV
• DBC.TableTextV

As tabelas e visualizações adicionais a seguir são extraídas quando você usa o conector teradata com a sinalização --assessment:

• DBC.All_RI_ChildrenV
• DBC.All_RI_ParentsV
• DBC.AllTempTablesVX
• DBC.DiskSpaceV
• DBC.RoleMembersV
• DBC.StatsV
• DBC.TableSizeV

As tabelas e visualizações a seguir são extraídas quando você usa o conector teradata-logs:

• DBC.DBQLogTbl (mudanças para DBC.QryLogV se a sinalização --assessment for usada)
• DBC.DBQLSqlTbl

As tabelas e visualizações adicionais a seguir são extraídas quando você usa o conector teradata-logs com a sinalização --assessment:

• DBC.DBQLUtilityTbl
• DBC.ResUsageScpu
• DBC.ResUsageSpma

Redshift

É possível usar qualquer um dos seguintes mecanismos de autenticação e autorização do Amazon Redshift com a ferramenta de extração:

• um nome de usuário e senha;
• Um ID da chave de acesso e uma chave secreta do AWS Identity and Access Management (IAM).
• Um nome de perfil do IAM da AWS.

Para autenticar com o nome de usuário e a senha, use o driver JDBC padrão do PostgreSQL do Amazon Redshift. Para autenticar com o IAM da AWS, use o driver JDBC do Amazon Redshift, que pode ser baixado na página de download.

A tabela a seguir descreve as sinalizações mais usadas para extrair metadados e registros de consulta do Amazon Redshift com a ferramenta dwh-migration-dumper. Para informações sobre todas as sinalizações compatíveis, consulte Sinalizações globais.

Nome	Valor padrão	Descrição	Obrigatório
--assessment		Ativar o modo de avaliação ao gerar registros do banco de dados ou extrair metadados. Ele gera as estatísticas de metadados necessárias para a avaliação de migração do BigQuery quando usado para extração de metadados. Quando usado para extração de registros de consulta, ele gera estatísticas de métricas de consulta para a avaliação de migração do BigQuery.	Obrigatório no modo de avaliação e não para tradução.
--connector		O nome do conector a ser usado. Neste caso, redshift para metadados ou redshift-raw-logs para registros de consulta.	Sim
--database	Se não for especificado, o Amazon Redshift usará o valor --user como o nome padrão do banco de dados.	O nome do banco de dados a ser conectado.	Não
--driver	Se não for especificado, o Amazon Redshift usará o driver JDBC padrão do PostgreSQL.	O caminho absoluto ou relativo para o arquivo JAR do driver a ser usado para essa conexão. É possível especificar vários arquivos JAR do driver, separando-os por vírgulas.	Não
--host	localhost	O nome do host ou o endereço IP do servidor de banco de dados.	Não
--iam-accesskeyid		O ID da chave de acesso do IAM da AWS a ser usado para autenticação. A chave de acesso é uma string de caracteres, algo como AKIAIOSFODNN7EXAMPLE. Use em conjunto com a sinalização --iam-secretaccesskey. Não use essa sinalização ao especificar as sinalizações --iam-profile ou --password.	Não explicitamente, mas você precisa fornecer informações de autenticação por meio de um dos seguintes métodos: O uso dessa sinalização em conjunto com a sinalização --iam-secretaccesskey. Como usar a sinalização --iam-profile Uso da sinalização --password em conjunto com a sinalização --user.
--iam-profile		O perfil do IAM da AWS a ser usado para autenticação. É possível recuperar um valor de perfil para usar examinando o arquivo $HOME/.aws/credentials ou executando aws configure list-profiles. Não use essa sinalização com as sinalizações --iam-accesskeyid, --iam-secretaccesskey ou --password.	Não explicitamente, mas você precisa fornecer informações de autenticação por meio de um dos seguintes métodos: O uso dessa sinalização. Uso da sinalização --iam-accesskeyid em conjunto com a sinalização --iam-secretaccesskey. Uso da sinalização --password em conjunto com a sinalização --user.
--iam-secretaccesskey		A chave de acesso secreta do IAM da AWS que será usada para a autenticação. A chave de acesso do secret é uma string de caracteres, algo como wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY. Use em conjunto com a sinalização --iam-accesskeyid. Não use essa sinalização com as sinalizações --iam-profile ou --password.	Não explicitamente, mas você precisa fornecer informações de autenticação por meio de um dos seguintes métodos: O uso dessa sinalização em conjunto com a sinalização --iam-accesskeyid. Como usar a sinalização --iam-profile Uso da sinalização --password em conjunto com a sinalização --user.
--password		A senha a ser usada na conexão do banco de dados. Não use essa sinalização com as sinalizações --iam-accesskeyid, --iam-secretaccesskey ou --iam-profile.	Não explicitamente, mas você precisa fornecer informações de autenticação por meio de um dos seguintes métodos: O uso dessa sinalização em conjunto com a sinalização --user. Uso da sinalização --iam-accesskeyid em conjunto com a sinalização --iam-secretaccesskey. Como usar a sinalização --password
--port	5439	A porta do servidor de banco de dados.	Não
--user		O nome de usuário a ser usado na conexão do banco de dados.	Sim
--query-log-start		O horário de início (inclusivo) dos registros de consulta que serão extraídos. O valor é truncado com a hora. Essa sinalização só está disponível para o conector redshift-raw-logs. Exemplo: --query-log-start "2023-01-01 14:00:00"	Não
--query-log-end		O horário de término (exclusivo) para extrair os registros da consulta. O valor é truncado com a hora. Essa sinalização só está disponível para o conector redshift-raw-logs. Exemplo: --query-log-end "2023-01-15 22:00:00"	Não

Examples

O exemplo a seguir mostra como despejar metadados de um banco de dados do Amazon Redshift em um host especificado, usando chaves de IAM da AWS para autenticação:

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

O exemplo a seguir mostra como despejar metadados de um banco de dados do Amazon Redshift no host padrão, usando o nome de usuário e a senha para autenticação:

dwh-migration-dumper \
  --connector redshift \
  --database database \
  --password password \
  --user user

O exemplo a seguir mostra como despejar metadados de um banco de dados do Amazon Redshift em um host especificado, usando um perfil do IAM da AWS para autenticação:

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

O exemplo a seguir mostra como despejar registros de consultas de avaliação de um banco de dados do Amazon Redshift em um host especificado, usando um perfil do IAM da AWS para autenticação:

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

Tabelas e visualizações extraídas pela ferramenta dwh-migration-dumper

As tabelas e visualizações a seguir são extraídas quando você usa o conector 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

As tabelas e visualizações adicionais a seguir são extraídas quando você usa o conector redshift com a sinalização --assessment:

• SVV_DISKUSAGE
• STV_MV_INFO
• STV_WLM_SERVICE_CLASS_CONFIG
• STV_WLM_SERVICE_CLASS_STATE

As tabelas e visualizações a seguir são extraídas quando você usa o conector redshift-raw-logs:

• STL_DDLTEXT
• STL_QUERY
• STL_QUERYTEXT
• PG_USER

As tabelas e visualizações adicionais a seguir são extraídas quando você usa o conector redshift-raw-logs com a sinalização --assessment:

• STL_QUERY_METRICS
• SVL_QUERY_QUEUE_INFO
• STL_WLM_QUERY

Para saber mais sobre as visualizações do sistema e as tabelas no Redshift, consulte Visualizações do sistema do Redshift e Tabelas do catálogo do sistema do Redshift.

Apache Hive/Spark ou Trino/PrestoSQL

A ferramenta dwh-migration-dumper só dá suporte à autenticação no metastore do Apache Hive por meio do Kerberos. Portanto, as flags --user e --password não são usadas. Use a flag --hive-kerberos-url para fornecer os detalhes de autenticação do Kerberos.

A tabela a seguir descreve as flags usadas com frequência para extrair metadados do Apache Hive, do Spark, do Presto ou do Trino com a ferramenta de extração. Para informações sobre todas as sinalizações compatíveis, consulte as Sinalizações globais.

Nome	Valor padrão	Descrição	Obrigatório
--assessment		Ativa o modo de avaliação ao extrair metadados. A ferramenta dwh-migration-dumper gera as estatísticas de metadados necessárias para avaliação de migração do BigQuery quando usada para extração de metadados.	Obrigatório para a avaliação. Não é necessário para a tradução.
--connector		O nome do conector a ser usado, neste caso hiveql.	Sim
--hive-metastore-dump-partition-metadata	true	Faz com que a ferramenta dwh-migration-dumper despeja metadados de partição. É recomendável definir essa sinalização como false para o metastore de produção com um número significativo de partições devido a implicações de desempenho do cliente Thrift. Isso melhora o desempenho da ferramenta , mas causa alguma perda de otimização de partição no BigQuery. Não use essa flag com a flag --assessment, porque ela não terá efeito.	Não
--hive-metastore-version	2.3.6	Quando você executa a ferramenta dwh-migration-dumper, ela seleciona a especificação Thrift apropriada para se comunicar com o servidor Apache Hive, com base no valor dessa sinalização. Se a ferramenta de extração não tiver uma especificação apropriada do Thrift, ela usará o cliente 2.3.6 e emitirá um aviso para stdout. Se isso ocorrer, entre em contato com o suporte e informe o número da versão do Apache Hive que você solicitou.	Não
--host	localhost	O nome do host ou o endereço IP do servidor de banco de dados.	Não
--port	9083	A porta do servidor de banco de dados.	Não
--hive-kerberos-url		O principal e o host do Kerberos a serem usados para autenticação.	Obrigatório para clusters com a autenticação Kerberos ativada.
-Dhiveql.rpc.protection		O nível de configuração de proteção RPC. Isso determina a qualidade de proteção (QOP, na sigla em inglês) da conexão da Camada de autenticação e segurança simples (SASL, na sigla em inglês) entre o cluster e a ferramenta dwh-migration-dumper. Precisa ser igual ao valor do parâmetro hadoop.rpc.protection dentro do arquivo /etc/hadoop/conf/core-site.xml no cluster, com um dos seguintes valores: authentication integrity privacy Exemplo (Bash): -Dhiveql.rpc.protection=privacy Exemplo (Windows PowerShell): "-Dhiveql.rpc.protection=privacy"	Obrigatório para clusters com a autenticação Kerberos ativada.

Examples

Confira no exemplo a seguir como despejar metadados de um banco de dados Hive 2.3.7 em um host especificado, sem autenticação e usando uma porta alternativa para conexão:

dwh-migration-dumper \
  --connector hiveql \
  --hive-metastore-version 2.3.7 \
  --host host \
  --port port

Para usar a autenticação do Kerberos, faça login como um usuário que tenha permissões de leitura no metastore do Hive e gere um tíquete do Kerberos. Em seguida, gere o arquivo ZIP de metadados com o seguinte comando:

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

Para permitir que a ferramenta dwh-migration-dumper se conecte ao Azure Synapse ou ao Microsoft SQL Server, faça o download do driver JDBC na página de download da Microsoft.

Na tabela a seguir, descrevemos as sinalizações usadas com frequência para extrair metadados do Azure Synapse ou do Microsoft SQL Server usando a ferramenta de extração. Para informações sobre todas as sinalizações compatíveis, consulte as Sinalizações globais.

Nome	Valor padrão	Descrição	Obrigatório
--connector		O nome do conector a ser usado, neste caso sqlserver.	Sim
--database		O nome do banco de dados a ser conectado.	Sim
--driver		O caminho absoluto ou relativo para o arquivo JAR do driver a ser usado para essa conexão. É possível especificar vários arquivos JAR do driver, separando-os por vírgulas.	Sim
--host	localhost	O nome do host ou o endereço IP do servidor de banco de dados.	Não
--password		A senha a ser usada na conexão do banco de dados.	Sim
--port	1433	A porta do servidor de banco de dados.	Não
--user		O nome de usuário a ser usado na conexão do banco de dados.	Sim

Examples

O exemplo a seguir mostra como despejar metadados de um banco de dados do Azure Synapse em um host especificado:

dwh-migration-dumper \
  --connector sqlserver \
  --database database \
  --driver path/mssql-jdbc.jar \
  --host server_name.sql.azuresynapse.net \
  --password password \
  --user user

Netezza

Para permitir que a ferramenta dwh-migration-dumper se conecte ao IBM Netezza, você precisa receber o driver JDBC. Geralmente, é possível conseguir o driver do diretório /nz/kit/sbin no host do dispositivo IBM Netezza. Se não conseguir encontrá-lo, peça a ajuda ao administrador do sistema ou leia Como instalar e configurar o JDBC na documentação do IBM Netezza.

A tabela a seguir descreve as sinalizações normalmente usadas para extrair metadados IBM Netezza usando a ferramenta de extração. Para informações sobre todas as sinalizações compatíveis, consulte Sinalizações globais.

Nome	Valor padrão	Descrição	Obrigatório
--connector		O nome do conector a ser usado, neste caso netezza.	Sim
--database		Uma lista dos bancos de dados a serem despejados, separados por vírgulas.	Sim
--driver		O caminho absoluto ou relativo para o arquivo JAR do driver a ser usado para essa conexão. É possível especificar vários arquivos JAR do driver, separando-os por vírgulas.	Sim
--host	localhost	O nome do host ou o endereço IP do servidor de banco de dados.	Não
--password		A senha a ser usada na conexão do banco de dados.	Sim
--port	5480	A porta do servidor de banco de dados.	Não
--user		O nome de usuário a ser usado na conexão do banco de dados.	Sim

Examples

O exemplo a seguir mostra como despejar metadados de dois bancos de dados IBM Netezza em um host especificado:

dwh-migration-dumper \
  --connector netezza \
  --database database1,database2 \
  --driver path/nzjdbc.jar \
  --host host \
  --password password \
  --user user

Oracle

Para permitir que a ferramenta dwh-migration-dumper se conecte ao Oracle, faça o download do driver JDBC na página de download do Oracle.

A tabela a seguir descreve as sinalizações mais usadas para extrair metadados da Oracle usando a ferramenta de extração. Para informações sobre todas as sinalizações compatíveis, consulte Sinalizações globais.

Nome	Valor padrão	Descrição	Obrigatório
--connector		O nome do conector a ser usado, neste caso, oracle.	Sim
--driver		O caminho absoluto ou relativo para o arquivo JAR do driver a ser usado para essa conexão. É possível especificar vários arquivos JAR do driver, separando-os por vírgulas.	Sim
--host	localhost	O nome do host ou o endereço IP do servidor de banco de dados.	Não
--oracle-service		O nome do serviço Oracle a ser usado para a conexão.	Não explicitamente, mas você precisa especificar essa sinalização ou a sinalização --oracle-sid.
--oracle-sid		O identificador de sistema Oracle (SID) a ser usado para a conexão.	Não explicitamente, mas você precisa especificar essa sinalização ou a sinalização --oracle-service.
--password		A senha a ser usada na conexão do banco de dados.	Se não for especificada, a ferramenta usará uma solicitação segura para solicitá-la.
--port	1521	A porta do servidor de banco de dados.	Não
--user		O nome de usuário a ser usado na conexão do banco de dados. O usuário especificado precisa ter o papel SELECT_CATALOG_ROLE para despejar metadados. Para conferir se o usuário tem o papel necessário, execute a consulta select granted_role from user_role_privs; no banco de dados Oracle.	Sim

Examples

O exemplo a seguir mostra como extrair metadados de um banco de dados Oracle em um host especificado, usando o serviço Oracle para a conexão:

dwh-migration-dumper \
  --connector oracle \
  --driver path/ojdbc8.jar \
  --host host \
  --oracle-service service_name \
  --password password \
  --user user

Snowflake

A tabela a seguir descreve as flags usadas com frequência para extrair metadados do Snowflake pela ferramenta dwh-migration-dumper. Para informações sobre todas as sinalizações compatíveis, consulte Sinalizações globais.

Nome	Valor padrão	Descrição	Obrigatório
--connector		O nome do conector a ser usado, neste caso, snowflake.	Sim
--database		O nome do banco de dados a ser conectado. Só é possível extrair de um banco de dados por vez do Snowflake.	Sim
--host	localhost	O nome do host ou o endereço IP do servidor de banco de dados.	Não
--password		A senha a ser usada na conexão do banco de dados.	Se não for especificada, a ferramenta usará uma solicitação segura para solicitá-la.
--role		O papel de floco de neve a ser usado para autorização. Só é necessário especificar isso para instalações grandes em que você precisa receber metadados do esquema SNOWFLAKE.ACCOUNT_USAGE em vez de INFORMATION_SCHEMA. Para mais informações, consulte Como trabalhar com grandes instâncias do Snowflake.	Não
--user		O nome de usuário a ser usado na conexão do banco de dados.	Sim
--warehouse		O armazenamento de Snowflake a ser usado para processar consultas de metadados.	Sim

Examples

O exemplo a seguir mostra como extrair metadados de um banco de dados do Snowflake de tamanho normal no host local:

dwh-migration-dumper \
  --connector snowflake \
  --database database \
  --password password \
  --user user \
  --warehouse warehouse

O exemplo a seguir mostra como extrair metadados de um grande banco de dados do Snowflake em um host especificado:

dwh-migration-dumper \
  --connector snowflake \
  --database database \
  --host "account.snowflakecomputing.com" \
  --password password \
  --role role \
  --user user \
  --warehouse warehouse

Como trabalhar com grandes instâncias do Snowflake

A ferramenta dwh-migration-dumper lê metadados da INFORMATION_SCHEMA do Snowflake. No entanto, há um limite para a quantidade de dados que é possível recuperar de INFORMATION_SCHEMA. Se você executar a ferramenta de extração e receber o erro SnowflakeSQLException: Information schema query returned too much data, será necessário seguir as seguintes etapas para ler os metadados do esquema SNOWFLAKE.ACCOUNT_USAGE em vez disso:

1. Abra a opção Shares na interface da Web do Snowflake.

2. Crie um banco de dados a partir do compartilhamento SNOWFLAKE.ACCOUNT_USAGE:

   -- CREATE DATABASE database FROM SHARE SNOWFLAKE.ACCOUNT_USAGE;
   

3. Crie um papel:

   CREATE ROLE role;
   

4. Conceda privilégios IMPORTED ao novo banco de dados para o papel:

   GRANT IMPORTED PRIVILEGES ON DATABASE database TO ROLE role;
   

5. Conceda o papel ao usuário que você pretende usar para executar a ferramenta dwh-migration-dumper:

   GRANT ROLE role TO USER user;
   

Vertica

Para permitir que a ferramenta dwh-migration-dumper se conecte à Vertica, faça o download do driver JDBC na página de download.

A tabela a seguir descreve as sinalizações comumente usadas para extrair metadados da Vertica com a ferramenta de extração. Para informações sobre todas as sinalizações compatíveis, consulte Sinalizações globais.

Nome	Valor padrão	Descrição	Obrigatório
--connector		O nome do conector a ser usado, neste caso vertica.	Sim
--database		O nome do banco de dados a ser conectado.	Sim
--driver		O caminho absoluto ou relativo para o arquivo JAR do driver a ser usado para essa conexão. É possível especificar vários arquivos JAR do driver, separando-os por vírgulas.	Sim
--host	localhost	O nome do host ou o endereço IP do servidor de banco de dados.	Não
--password		A senha a ser usada na conexão do banco de dados.	Sim
--port	5433	A porta do servidor de banco de dados.	Não
--user		O nome de usuário a ser usado na conexão do banco de dados.	Sim

Examples

O exemplo a seguir mostra como extrair metadados de um banco de dados Vertica no host local:

dwh-migration-dumper \
  --driver path/vertica-jdbc.jar \
  --connector vertica \
  --database database
  --user user
  --password password

Sinalizações globais

A tabela a seguir descreve as sinalizações que podem ser usadas em qualquer uma das plataformas de origem compatíveis.

Nome	Descrição
--connector	Nome do conector do sistema de origem.
--database	O uso varia de acordo com o sistema de origem.
--driver	O caminho absoluto ou relativo para o arquivo JAR do driver a ser usado ao se conectar ao sistema de origem. É possível especificar vários arquivos JAR do driver, separando-os por vírgulas.
--dry-run ou -n	Mostre quais ações a ferramenta de extração faria sem executá-las.
--help	Exibe a ajuda da linha de comando.
--host	O nome do host ou o endereço IP do servidor de banco de dados a que se conectar.
--jdbcDriverClass	Como opção, modifica o nome da classe do driver JDBC especificado pelo fornecedor. Use essa opção se você tiver um cliente JDBC personalizado.
--output	O caminho do arquivo ZIP de saída. Por exemplo, dir1/dir2/teradata-metadata.zip. Se você não especificar um caminho, o arquivo de saída será criado no diretório de trabalho. Se você especificar o caminho para um diretório, o nome do arquivo ZIP padrão será criado no diretório especificado. Se o diretório não existir, ele será criado. Para usar o Cloud Storage, use o seguinte formato: gs://<BUCKET>/<PATH> Para autenticar usando credenciais do Google Cloud, consulte Autenticar para usar bibliotecas de cliente.
--password	A senha a ser usada na conexão do banco de dados.
--port	A porta do servidor de banco de dados.
--save-response-file	Salva suas flags de linha de comando em um arquivo JSON para facilitar a reutilização. O arquivo é chamado dumper-response-file.json e é criado no diretório de trabalho. Para usar o arquivo de resposta, forneça o caminho para ele com o prefixo @ ao executar a ferramenta dwh-migration-dumper @path/to/dumper-response-file.json, por exemplo, .
--schema	Uma lista dos esquemas a serem extraídos, separados por vírgulas. O Oracle não faz distinção entre um esquema e o usuário do banco de dados que criou o esquema. Portanto, é possível usar nomes de esquema ou de usuário com a sinalização --schema. de dados. Por exemplo, --schema schema1,user2,schema3.
--thread-pool-size	Define o tamanho do pool de linhas de execução, o que afeta o tamanho do pool de conexões. O tamanho padrão do pool de linhas de execução é o número de núcleos no servidor que executa a ferramenta dwh-migration-dumper. Se a ferramenta de extração parecer lenta ou precisar de mais recursos, aumente o número de linhas de execução usadas. Se houver indicações de que outros processos no servidor exigem mais largura de banda, reduza o número de linhas de execução usadas.
--url	O URL a ser usado para a conexão do banco de dados, em vez do URI gerado pelo driver JDBC. O URI gerado é suficiente na maioria dos casos. Só substitua o URI gerado quando você precisar usar uma configuração de conexão JDBC específica para a plataforma de origem e que ainda não esteja definida por uma das sinalizações listadas nesta tabela.
--user	O nome de usuário a ser usado na conexão do banco de dados.
--version	Exibe a versão do produto.

Solução de problemas

Nesta seção, explicamos alguns problemas comuns e técnicas de resolução para a ferramenta dwh-migration-dumper.

Erro por falta de memória

O erro java.lang.OutOfMemoryError na saída do terminal da ferramenta dwh-migration-dumper geralmente está relacionado à memória insuficiente para processar os dados recuperados. Para resolver esse problema, aumente a memória disponível ou reduza o número de linhas de execução de processamento.

É possível aumentar a memória máxima exportando a variável de ambiente JAVA_OPTS:

Linux

export JAVA_OPTS="-Xmx4G"

Windows

set JAVA_OPTS="-Xmx4G"

Reduza o número de linhas de execução de processamento (o padrão é 32) incluindo a flag --thread-pool-size. Essa opção é compatível apenas com os conectores hiveql e redshift*.

dwh-migration-dumper --thread-pool-size=1

Como processar um erro WARN...Task failed

Às vezes, pode ser exibido um erro WARN [main] o.c.a.d.MetadataDumper [MetadataDumper.java:107] Task failed: … na saída do terminal da ferramenta dwh-migration-dumper. A ferramenta de extração envia várias consultas ao sistema de origem, e a saída de cada consulta é gravada no próprio arquivo. Esse problema indica que uma dessas consultas falhou. No entanto, a falha de uma consulta não impede a execução das outras. Se você vir mais de alguns erros WARN, analise os detalhes do problema e confira se há algo que precisa ser corrigido para que a consulta seja executada corretamente. Por exemplo, se o usuário do banco de dados especificado ao executar a ferramenta de extração não tiver permissões para ler todos os metadados, tente novamente com um usuário com as permissões corretas.

Arquivo ZIP corrompido

Para validar o arquivo ZIP da ferramenta dwh-migration-dumper, faça o download do arquivo SHA256SUMS.txt e execute o seguinte comando:

sha256sum --check SHA256SUMS.txt

O resultado OK confirma a verificação com êxito do checksum. Qualquer outra mensagem indica um erro de verificação:

• FAILED: computed checksum did NOT match: o arquivo ZIP está corrompido, e o download dele precisa ser refeito.
• FAILED: listed file could not be read: não é possível localizar a versão do arquivo ZIP. Verifique se o checksum e os arquivos ZIP são da mesma versão de lançamento ao fazer o download e foram colocados no mesmo diretório.

A extração de registros de consulta do Teradata é lenta

Para melhorar o desempenho da mesclagem de tabelas especificadas pelas flags -Dteradata-logs.query-logs-table e -Dteradata-logs.sql-logs-table, inclua mais uma coluna do tipo DATE na condição JOIN. Essa coluna precisa ser definida em ambas as tabelas e fazer parte do índice primário particionado. Para incluir essa coluna, use a flag -Dteradata-logs.log-date-column.

Exemplo:

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"

O limite de tamanho das linhas do Teradata foi excedido

O Teradata 15 tem um limite de tamanho de linha de 64 KB. Se o limite for excedido, o destrutor falhará com a seguinte mensagem: none [Error 9804] [SQLState HY000] Response Row size or Constant Row size overflow

Para resolver esse erro, aumente o limite para 1 MB ou divida as linhas em várias linhas:

• Instale e ative o recurso de linhas de resposta e de permissões de 1 MB e o software TTU atual. Para mais informações, consulte a mensagem 9804 do banco de dados do Teradata.
• Divida o texto longo de consulta em várias linhas usando as flags -Dteradata.metadata.max-text-length e -Dteradata-logs.max-sql-length.

O comando a seguir mostra o uso da flag -Dteradata.metadata.max-text-length para dividir o texto de consulta longo em várias linhas de, no máximo, 10.000 caracteres cada:

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"

O comando a seguir mostra o uso da flag -Dteradata-logs.max-sql-length para dividir o texto de consulta longo em várias linhas de, no máximo, 10.000 caracteres cada:

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"

A seguir

Depois de executar a ferramenta dwh-migration-dumper, faça upload da saída para o Cloud Storage junto com os arquivos de origem para tradução.