Metadaten für Übersetzung und Bewertung generieren

Vorschau

Für dieses Produkt gelten die „Bedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Produkte sind „wie besehen“ verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

In diesem Dokument wird beschrieben, wie Sie mit dem dwh-migration-dumper-Befehlszeilen-Extraktionstool Metadaten und Abfragelogdateien erstellen. Die Metadatendateien beschreiben die SQL-Objekte in Ihrem Quellsystem.

BigQuery Migration Service verwendet diese Informationen, um die Übersetzung Ihrer SQL-Skripts von Ihrem Quellsystemdialekt in GoogleSQL zu verbessern.

Bei der BigQuery-Migrationsbewertung werden Metadatendateien und Abfragelogdateien verwendet, um Ihr vorhandenes Data Warehouse zu analysieren und den Aufwand für das Verschieben Ihres Data Warehouse zu BigQuery zu bewerten.

Überblick

Mit dem dwh-migration-dumper-Tool können Sie Metadateninformationen von der Datenbankplattform extrahieren, die Sie zu BigQuery migrieren. Die Verwendung des Extraktionstools ist zwar für die Übersetzung nicht erforderlich, wird jedoch für die BigQuery-Migrationsbewertung benötigt und dringend für alle Migrationsaufgaben empfohlen.

Weitere Informationen finden Sie unter Metadatendateien erstellen.

Mit dem dwh-migration-dumper-Tool können Sie Metadaten von den folgenden Datenbankplattformen extrahieren:

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

Für die meisten dieser Datenbanken können Sie auch Abfragelogs extrahieren.

Das dwh-migration-dumper-Tool fragt Systemtabellen ab, um DDL-Anweisungen (Data Definition Language) für Nutzer- und Systemdatenbanken zu erfassen. Der Inhalt von Nutzerdatenbanken wird nicht abgefragt. Das Tool speichert die Metadateninformationen aus den Systemtabellen als CSV-Dateien und komprimiert diese Dateien dann in einem einzigen Paket. Diese ZIP-Datei laden Sie dann in Cloud Storage hoch, wenn Sie Ihre Quelldateien zur Übersetzung oder Bewertung hochladen.

Wenn Sie die Abfragelogoption verwenden, fragt das dwh-migration-dumper-Tool Systemtabellen nach DDL-Anweisungen und Abfragelogs ab, die sich auf Nutzer- und Systemdatenbanken beziehen. Diese werden im CSV- oder YAML-Format in einem Unterverzeichnis gespeichert und dann in ein ZIP-Paket verpackt. In keinem Moment werden die Inhalte von Nutzerdatenbanken selbst abgefragt. An dieser Stelle erfordert die BigQuery-Migrationsbewertung individuelle CSV-, YAML- und Textdateien für Abfragelogs. Daher sollten Sie alle diese Dateien aus der ZIP-Datei mit den Abfragelogs entpacken und zur Bewertung hochladen.

Das dwh-migration-dumper-Tool kann unter Windows, macOS und Linux ausgeführt werden.

Das dwh-migration-dumper-Tool ist unter der Apache 2-Lizenz verfügbar.

Wenn Sie das dwh-migration-dumper-Tool nicht für die Übersetzung verwenden, können Sie Metadatendateien manuell bereitstellen. Erfassen Sie dazu DDL-Anweisungen (Data Definition Language) für die SQL-Objekte in Ihrem Quellsystem in separaten Textdateien.

Für die Migrationsbewertung mithilfe der BigQuery-Migrationsbewertung ist das Bereitstellen von Metadaten und Abfragelogs erforderlich, die mit dem Tool extrahiert wurden.

Compliance-Anforderungen

Wir stellen die kompilierte Binärdatei des dwh-migration-dumper-Tools für eine einfache Nutzung zur Verfügung. Wenn Sie prüfen müssen, ob das Tool die Compliance-Anforderungen erfüllt, können Sie den Quellcode aus dem GitHub-Repository des dwh-migration-dumper-Tools prüfen und Ihre eigene Binärdatei kompilieren.

Vorbereitung

Java installieren

Auf dem Server, auf dem Sie das dwh-migration-dumper-Tool ausführen möchten, muss Java 8 oder höher installiert sein. Ist dies nicht der Fall, laden Sie Java von der Java-Downloadseite herunter und installieren Sie es.

Erforderliche Berechtigungen

Das Nutzerkonto, das Sie für die Verbindung des dwh-migration-dumper-Tools mit dem Quellsystem angeben, muss Berechtigungen zum Lesen von Metadaten aus diesem System haben. Prüfen Sie, ob dieses Konto die entsprechende Rollenmitgliedschaft hat, um die für Ihre Plattform verfügbaren Metadatenressourcen abzufragen. Beispielsweise ist INFORMATION_SCHEMA eine Metadatenressource, die mehrere Plattformen gemeinsam haben.

Installieren Sie das dwh-migration-dumper-Tool.

So installieren Sie das dwh-migration-dumper-Tool:

1. Laden Sie auf dem Computer, auf dem Sie das dwh-migration-dumper-Tool ausführen möchten, die ZIP-Datei aus dem GitHub-Repository des dwh-migration-dumper-Tools herunter.
2. Laden Sie die Datei SHA256SUMS.txt herunter und führen Sie den folgenden Befehl aus:

   sha256sum --check SHA256SUMS.txt
   

   Wenn die Bestätigung fehlschlägt, finden Sie weitere Informationen unter Fehlerbehebung.
3. Extrahieren Sie die ZIP-Datei. Die Binärdatei des Extraktionstools befindet sich im Unterverzeichnis /bin des Ordners, der durch Extrahieren der ZIP-Datei erstellt wurde.
4. Aktualisieren Sie die Umgebungsvariable PATH so, dass sie den Installationspfad für das Extraktionstool enthält.

dwh-migration-dumper-Tool ausführen

Das dwh-migration-dumper-Tool hat das folgende Format:

dwh-migration-dumper [FLAGS]

Wenn Sie das dwh-migration-dumper-Tool ausführen, wird in Ihrem Arbeitsverzeichnis eine Ausgabedatei namens dwh-migration-<source platform>-metadata.zip erstellt, z. B. dwh-migration-teradata-metadata.zip.

Tipp: Setzen Sie bei Verwendung von Windows PowerShell Flags in doppelte Anführungszeichen, z. B. dwh-migration-dumper "-Dteradata-logs.utility-logs-table=historicdb.ArchivedUtilityLogs".

In der folgenden Anleitung wird gezeigt, wie Sie das dwh-migration-dumper-Tool für Ihre Quellplattform ausführen.

Teradata

Damit das dwh-migration-dumper-Tool eine Verbindung zu Teradata herstellen kann, laden Sie den JDBC-Treiber von der Downloadseite von Teradata herunter.

In der folgenden Tabelle werden die Flags beschrieben, die häufig zum Extrahieren von Teradata-Metadaten und -Abfragelogs mit dem Extraktionstool verwendet werden. Informationen zu allen unterstützten Flags finden Sie unter Globale Flags.

Name	Standardwert	Beschreibung	Erforderlich
--assessment		Aktiviert den Bewertungsmodus beim Generieren von Datenbanklogs oder Extrahieren von Metadaten. Das dwh-migration-dumper-Tool generiert die erforderlichen Metadatenstatistiken für die BigQuery-Migrationsbewertung, wenn für die Metadatenextraktion verwendet. Bei der Verwendung von Abfragelogs werden zusätzliche Spalten für die BigQuery-Migrationsbewertung extrahiert.	Erforderlich für die Ausführung der Bewertung, nicht für die Übersetzung.
--connector		Der Name des zu verwendenden Connectors, in diesem Fall teradata für Metadaten oder teradata-logs für Abfragelogs.	Ja
--database		Eine Liste der Datenbanken für die Extraktion, durch Kommas getrennt. Bei den Datenbanknamen wird abhängig von der Teradata-Serverkonfiguration möglicherweise die Groß-/Kleinschreibung beachtet. Wenn dieses Flag in Kombination mit dem teradata-Connector verwendet wird, filtert das dwh-migration-dumper-Tool die Metadatentabellen und -ansichten nach der bereitgestellten Liste der Datenbanken. Die Ausnahmen sind die Ansichten DatabasesV und RoleMembersV. Das dwh-migration-dumper-Tool extrahiert die Datenbanken und Nutzer aus diesen Ansichten, ohne nach dem Datenbanknamen zu filtern. Dieses Flag kann nicht in Kombination mit dem teradata-logs-Connector verwendet werden. Abfragelogs werden immer für alle Datenbanken extrahiert.	Nein
--driver		Der absolute oder relative Pfad zur JAR-Datei des Treibers, die für diese Verbindung verwendet werden soll. Sie können mehrere JAR-Treiberdateien angeben, indem Sie sie durch Kommas trennen.	Ja
--host	localhost	Der Hostname oder die IP-Adresse des Datenbankservers.	Nein
--password		Das Passwort für die Datenbankverbindung.	Wenn keine Angabe erfolgt, verwendet das Extraktionstool eine sichere Eingabeaufforderung, um sie anzufordern.
--port	1025	Der Port des Datenbankservers.	Nein
--user		Der Nutzername für die Datenbankverbindung.	Ja
--query-log-alternates		Nur für den teradata-logs-Connector. Wenn Sie die Abfragelogs aus einem alternativen Speicherort extrahieren möchten, empfehlen wir stattdessen die Verwendung der Flags -Dteradata-logs.query-logs-table und -Dteradata-logs.sql-logs-table. Standardmäßig werden die Abfragelogs aus den Tabellen dbc.DBQLogTbl und dbc.DBQLSQLTbl extrahiert. Wenn Sie das Flag --assessment verwenden, werden die Abfragelogs aus der Ansicht dbc.QryLogV und aus der Tabelle dbc.DBQLSQLTbl extrahiert. Wenn Sie die Abfragelogs aus einem alternativen Speicherort extrahieren möchten, können Sie mit dem Flag --query-log-alternates die voll qualifizierten Namen der Tabellen oder Ansichten angeben. Der erste Parameter verweist auf die Alternative zur Tabelle dbc.DBQLogTbl und der zweite Parameter auf die Alternative zur Tabelle dbc.DBQLSQLTbl. Beide Parameter sind erforderlich. Das Flag -Dteradata-logs.log-date-column kann verwendet werden, um die Extraktionsleistung zu verbessern, wenn beide Tabellen eine indexierte Spalte vom Typ DATE haben. Beispiel: --query-log-alternates historicdb.ArchivedQryLogV,historicdb.ArchivedDBQLSqlTbl	Nein
-Dteradata.tmode		Der Transaktionsmodus für die Verbindung. Folgende Werte werden unterstützt: ANSI: ANSI-Modus. Dies ist der Standardmodus (wenn das Flag nicht angegeben ist). TERA: Teradata-Transaktionsmodus (BTET) DEFAULT: den auf dem Datenbankserver konfigurierten Standardtransaktionsmodus verwenden NONE: Für die Verbindung ist kein Modus festgelegt. Beispiel (Bash): -Dteradata.tmode=TERA Beispiel (Windows PowerShell): "-Dteradata.tmode=TERA"	Nein
-Dteradata-logs.log-date-column		Nur für den teradata-logs-Connector. Zur Verbesserung der Leistung von Join-Tabellen, die mit den Flags -Dteradata-logs.query-logs-table und -Dteradata-logs.sql-logs-table angegeben werden, können Sie eine zusätzliche Spalte vom Typ DATE in JOIN Bedingung inkludieren. Diese Spalte muss in beiden Tabellen definiert sein und Teil des partitionierten primären Index sein. Beispiel (Bash): -Dteradata-logs.log-date-column=ArchiveLogDate Beispiel (Windows PowerShell): "-Dteradata-logs.log-date-column=ArchiveLogDate"	Nein
-Dteradata-logs.query-logs-table		Nur für den teradata-logs-Connector. Die Abfragelogs werden standardmäßig aus der Tabelle dbc.DBQLogTbl extrahiert. Wenn Sie das Flag --assessment verwenden, werden die Abfragelogs aus der Ansicht dbc.QryLogV extrahiert. Wenn Sie die Abfragelogs aus einem alternativen Speicherort extrahieren möchten, können Sie mit diesem Flag den vollqualifizierten Namen der Tabelle oder Ansicht angeben. Sehen Sie sich das Flag -Dteradata-logs.log-date-column an, um die Extraktionsleistung zu verbessern. Beispiel (Bash): -Dteradata-logs.query-logs-table=historicdb.ArchivedQryLogV Beispiel (Windows PowerShell): "-Dteradata-logs.query-logs-table=historicdb.ArchivedQryLogV"	Nein
-Dteradata-logs.sql-logs-table		Nur für den teradata-logs-Connector. Standardmäßig werden die Abfragelogs, die SQL-Text enthalten, aus der Tabelle dbc.DBQLSqlTbl extrahiert. Wenn Sie sie von einem alternativen Speicherort extrahieren müssen, können Sie mit diesem Flag den vollqualifizierten Namen der Tabelle oder Ansicht angeben. Sehen Sie sich das Flag -Dteradata-logs.log-date-column an, um die Extraktionsleistung zu verbessern. Beispiel (Bash): -Dteradata-logs.sql-logs-table=historicdb.ArchivedDBQLSqlTbl Beispiel (Windows PowerShell): "-Dteradata-logs.sql-logs-table=historicdb.ArchivedDBQLSqlTbl"	Nein
-Dteradata-logs.utility-logs-table		Nur für den teradata-logs-Connector. Die Dienstprogrammlogs werden standardmäßig aus der Tabelle dbc.DBQLUtilityTbl extrahiert. Wenn Sie die Dienstprogrammlogs von einem alternativen Speicherort extrahieren müssen, können Sie mit dem Flag -Dteradata-logs.utility-logs-table den vollqualifizierten Namen der Tabelle angeben. Beispiel (Bash): -Dteradata-logs.utility-logs-table=historicdb.ArchivedUtilityLogs Beispiel (Windows PowerShell): "-Dteradata-logs.utility-logs-table=historicdb.ArchivedUtilityLogs"	Nein
-Dteradata-logs.res-usage-scpu-table		Nur für den teradata-logs-Connector. Standardmäßig werden die SCPU-Ressourcennutzungslogs aus der Tabelle dbc.ResUsageScpu extrahiert. Wenn Sie diese Logs von einem alternativen Speicherort extrahieren müssen, können Sie mit dem Flag -Dteradata-logs.res-usage-scpu-table den vollqualifizierten Namen der Tabelle angeben. Beispiel (Bash): -Dteradata-logs.res-usage-scpu-table=historicdb.ArchivedResUsageScpu Beispiel (Windows PowerShell): "-Dteradata-logs.res-usage-scpu-table=historicdb.ArchivedResUsageScpu"	Nein
-Dteradata-logs.res-usage-spma-table		Nur für den teradata-logs-Connector. Standardmäßig werden die Logs für die SPMA-Ressourcennutzung aus der Tabelle dbc.ResUsageSpma extrahiert. Wenn Sie diese Logs von einem alternativen Speicherort extrahieren müssen, können Sie mit dem Flag -Dteradata-logs.res-usage-spma-table den vollqualifizierten Namen der Tabelle angeben. Beispiel (Bash): -Dteradata-logs.res-usage-spma-table=historicdb.ArchivedResUsageSpma Beispiel (Windows PowerShell): "-Dteradata-logs.res-usage-spma-table=historicdb.ArchivedResUsageSpma"	Nein
--query-log-start		Die Startzeit (einschließlich) für zu extrahierende Abfragelogs. Der Wert wird auf die Stunde gekürzt. Dieses Flag ist nur für den teradata-logs-Connector verfügbar. Beispiel: --query-log-start "2023-01-01 14:00:00"	Nein
--query-log-end		Die Endzeit (exklusiv) für das Extrahieren von Abfragelogs. Der Wert wird auf die Stunde gekürzt. Dieses Flag ist nur für den teradata-logs-Connector verfügbar. Beispiel: --query-log-end "2023-01-15 22:00:00"	Nein
-Dteradata.metadata.tablesizev.max-rows		Nur für den teradata-Connector. Begrenzen Sie die Anzahl der aus der Ansicht TableSizeV extrahierten Zeilen. Die Zeilen sind nach den Spalten DatabaseName ,AccountName und TableName gruppiert und werden dann in absteigender Reihenfolge nach der Größe des permanenten Leerzeichens (der Ausdruck SUM(CurrentPerm)) sortiert. Anschließend wird die angegebene Anzahl von Zeilen extrahiert. Beispiel (Bash): -Dteradata.metadata.tablesizev.max-rows=100000 Beispiel (Windows PowerShell): "-Dteradata.metadata.tablesizev.max-rows=100000"	Nein
-Dteradata.metadata.diskspacev.max-rows		Nur für den teradata-Connector. Begrenzen Sie die Anzahl der aus der Ansicht DiskSpaceV extrahierten Zeilen. Die Zeilen werden in absteigender Reihenfolge nach der Größe des permanenten Leerzeichens (Spalte CurrentPerm) sortiert. Anschließend wird die angegebene Anzahl von Zeilen extrahiert. Beispiel (Bash): -Dteradata.metadata.diskspacev.max-rows=100000 Beispiel (Windows PowerShell): "-Dteradata.metadata.diskspacev.max-rows=100000"	Nein
-Dteradata.metadata.databasesv.users.max-rows		Nur für den teradata-Connector. Begrenzen Sie die Anzahl der Zeilen, die Nutzer (DBKind='U') darstellen, die aus der Ansicht DatabasesV extrahiert werden. Die Zeilen werden in absteigender Reihenfolge nach der Spalte PermSpace sortiert. Anschließend wird die angegebene Anzahl von Zeilen extrahiert. Beispiel (Bash): -Dteradata.metadata.databasesv.users.max-rows=100000 Beispiel (Windows PowerShell): "-Dteradata.metadata.databasesv.users.max-rows=100000"	Nein
-Dteradata.metadata.databasesv.dbs.max-rows		Nur für den teradata-Connector. Begrenzen Sie die Anzahl der Zeilen, die Datenbanken (DBKind='D') darstellen, die aus der Ansicht DatabasesV extrahiert werden. Die Zeilen werden in absteigender Reihenfolge nach der Spalte PermSpace sortiert. Anschließend wird die angegebene Anzahl von Zeilen extrahiert. Beispiel (Bash): -Dteradata.metadata.databasesv.dbs.max-rows=100000 Beispiel (Windows PowerShell): "-Dteradata.metadata.databasesv.dbs.max-rows=100000"	Nein
-Dteradata.metadata.max-text-length		Nur für den teradata-Connector. Maximale Länge der Textspalte beim Extrahieren der Daten aus der Ansicht TableTextV. Text, der das definierte Limit überschreitet, wird in mehrere Zeilen aufgeteilt. Zulässiger Bereich: zwischen 5.000 und 32.000 (einschließlich). Beispiel (Bash): -Dteradata.metadata.max-text-length=10000 Beispiel (Windows PowerShell): "-Dteradata.metadata.max-text-length=10000"	Nein
-Dteradata-logs.max-sql-length		Nur für den teradata-logs-Connector. Maximale Länge der Spalte DBQLSqlTbl.SqlTextInfo. Abfragetext, der das definierte Limit überschreitet, wird in mehrere Zeilen aufgeteilt. Zulässiger Bereich: zwischen 5000 und 31000 (einschließlich). Beispiel (Bash): -Dteradata-logs.max-sql-length=10000 Beispiel (Windows PowerShell): "-Dteradata-logs.max-sql-length=10000"	Nein

Beispiele

Das folgende Beispiel zeigt, wie Sie eine Extraktion von Metadaten aus zwei Teradata-Datenbanken auf dem lokalen Host ausführen:

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

Das folgende Beispiel zeigt, wie Sie eine Extraktion von Abfragelogs für die Bewertung auf dem lokalen Host ausführen:

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

Vom dwh-migration-dumper-Tool extrahierte Tabellen und Ansichten

Die folgenden Tabellen und Ansichten werden mit dem Connector teradata extrahiert:

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

Wenn Sie den Connector teradata mit dem Flag --assessment verwenden, werden die folgenden zusätzlichen Tabellen und Ansichten extrahiert:

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

Die folgenden Tabellen und Ansichten werden mit dem Connector teradata-logs extrahiert:

• DBC.DBQLogTbl (Änderungen in DBC.QryLogV, wenn das Flag --assessment verwendet wird)
• DBC.DBQLSqlTbl

Wenn Sie den Connector teradata-logs mit dem Flag --assessment verwenden, werden die folgenden zusätzlichen Tabellen und Ansichten extrahiert:

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

Redshift

Sie können mit dem Extraktionstool einen der folgenden Authentifizierungs- und Autorisierungsmechanismen von Amazon Redshift verwenden:

• Ein Nutzername und ein Passwort.
• Eine Zugriffsschlüssel-ID und ein geheimer Schlüssel für AWS Identity and Access Management (IAM).
• Ein AWS IAM-Profilname.

Verwenden Sie zur Authentifizierung mit dem Nutzernamen und Passwort den Standard-PostgreSQL-JDBC-Treiber von Amazon Redshift. Verwenden Sie zur Authentifizierung bei AWS IAM den JDBC-Treiber von Amazon Redshift, den Sie von der Downloadseite herunterladen können.

In der folgenden Tabelle werden die Flags beschrieben, die häufig zum Extrahieren von Amazon Redshift-Metadaten und -Abfragelogs mithilfe des dwh-migration-dumper-Tools verwendet werden. Informationen zu allen unterstützten Flags finden Sie unter Globale Flags.

Name	Standardwert	Beschreibung	Erforderlich
--assessment		Bewertungsmodus beim Generieren von Datenbanklogs oder Extrahieren von Metadaten aktivieren. Generiert die erforderlichen Metadatenstatistiken für die BigQuery-Migrationsbewertung, wenn für die Metadatenextraktion verwendet. Bei der Verwendung der Extraktion von Abfragelogs werden Statistiken zu Abfragemesswerten für die BigQuery-Migrationsbewertung erstellt.	Erforderlich im Ausführungsmodus, jedoch nicht für die Übersetzung.
--connector		Der Name des zu verwendenden Connectors, in diesem Fall Redshift für Metadaten oder redshift-raw-logs für Abfragelogs.	Ja
--database	Wenn nicht angegeben, verwendet Amazon Redshift den --user-Wert als Standarddatenbankname.	Der Name der Datenbank, zu der eine Verbindung hergestellt werden soll.	Nein
--driver	Wenn nicht angegeben, verwendet Amazon Redshift den Standard-PostgreSQL-JDBC-Treiber.	Der absolute oder relative Pfad zur JAR-Datei des Treibers, die für diese Verbindung verwendet werden soll. Sie können mehrere JAR-Treiberdateien angeben, indem Sie sie durch Kommas trennen.	Nein
--host	localhost	Der Hostname oder die IP-Adresse des Datenbankservers.	Nein
--iam-accesskeyid		Die AWS IAM-Zugriffsschlüssel-ID, die zur Authentifizierung verwendet werden soll. Der Zugriffsschlüssel ist ein String aus Zeichen, zum Beispiel AKIAIOSFODNN7EXAMPLE. In Verbindung mit dem Flag --iam-secretaccesskey verwenden. Dieses Flag nicht verwenden, wenn Sie das Flag --iam-profile oder --password angeben.	Nicht explizit, aber Sie müssen Authentifizierungsinformationen mit einer der folgenden Methoden angeben: Dieses Flag in Verbindung mit dem Flag --iam-secretaccesskey verwenden. Flag --iam-profile verwenden. Flag --password in Verbindung mit dem Flag --user verwenden.
--iam-profile		Das AWS IAM-Profil, das für die Authentifizierung verwendet werden soll. Sie können einen zu verwendenden Profilwert abrufen, indem Sie sich die Datei $HOME/.aws/credentials ansehen oder aws configure list-profiles ausführen. Dieses Flag nicht mit den Flags --iam-accesskeyid, --iam-secretaccesskey oder --password verwenden.	Nicht explizit, aber Sie müssen Authentifizierungsinformationen mit einer der folgenden Methoden angeben: Dieses Flag verwenden. Flag --iam-accesskeyid in Verbindung mit dem Flag --iam-secretaccesskey verwenden. Flag --password in Verbindung mit dem Flag --user verwenden.
--iam-secretaccesskey		Der geheime AWS-Zugriffsschlüssel für die Authentifizierung. Der Zugriffsschlüssel ist ein String aus Zeichen, zum Beispiel wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY. In Verbindung mit dem Flag --iam-accesskeyid verwenden. Dieses Flag nicht mit den Flags --iam-profile und --password verwenden.	Nicht explizit, aber Sie müssen Authentifizierungsinformationen mit einer der folgenden Methoden angeben: Dieses Flag in Verbindung mit dem Flag --iam-accesskeyid verwenden. Flag --iam-profile verwenden. Flag --password in Verbindung mit dem Flag --user verwenden.
--password		Das Passwort für die Datenbankverbindung. Dieses Flag nicht mit den Flags --iam-accesskeyid, --iam-secretaccesskey oder --iam-profile verwenden.	Nicht explizit, aber Sie müssen Authentifizierungsinformationen mit einer der folgenden Methoden angeben: Dieses Flag in Verbindung mit dem Flag --user verwenden. Flag --iam-accesskeyid in Verbindung mit dem Flag --iam-secretaccesskey verwenden. Flag --password verwenden.
--port	5439	Der Port des Datenbankservers.	Nein
--user		Der Nutzername für die Datenbankverbindung.	Ja
--query-log-start		Die Startzeit (einschließlich) für zu extrahierende Abfragelogs. Der Wert wird auf die Stunde gekürzt. Dieses Flag ist nur für den Connector redshift-raw-logs verfügbar. Beispiel: --query-log-start "2023-01-01 14:00:00"	Nein
--query-log-end		Die Endzeit (exklusiv) für das Extrahieren von Abfragelogs. Der Wert wird auf die Stunde gekürzt. Dieses Flag ist nur für den Connector redshift-raw-logs verfügbar. Beispiel: --query-log-end "2023-01-15 22:00:00"	Nein

Beispiele

Das folgende Beispiel zeigt, wie Sie eine Extraktion von Metadaten aus einer Amazon Redshift-Datenbank auf einem bestimmten Host ausführen und dabei AWS IAM-Schlüssel zur Authentifizierung verwenden:

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

Das folgende Beispiel zeigt, wie Sie eine Extraktion von Metadaten aus einer Amazon Redshift-Datenbank auf dem Standardhost ausführen und dabei den Nutzernamen und das Passwort zur Authentifizierung verwenden:

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

Das folgende Beispiel zeigt, wie Sie eine Extraktion von Metadaten aus einer Amazon Redshift-Datenbank auf einem bestimmten Host ausführen und dabei ein AWS IAM-Profil zur Authentifizierung verwenden:

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

Das folgende Beispiel zeigt, wie Sie eine Extraktion von Abfragelogs für die Bewertung aus einer Amazon Redshift-Datenbank auf einem bestimmten Host ausführen und dabei ein AWS IAM-Profil zur Authentifizierung verwenden:

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

Vom dwh-migration-dumper-Tool extrahierte Tabellen und Ansichten

Die folgenden Tabellen und Ansichten werden mit dem Connector redshift extrahiert:

• 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

Wenn Sie den Connector redshift mit dem Flag --assessment verwenden, werden die folgenden zusätzlichen Tabellen und Ansichten extrahiert:

• SVV_DISKUSAGE
• STV_MV_INFO
• STV_WLM_SERVICE_CLASS_CONFIG
• STV_WLM_SERVICE_CLASS_STATE

Die folgenden Tabellen und Ansichten werden mit dem Connector redshift-raw-logs extrahiert:

• STL_DDLTEXT
• STL_QUERY
• STL_QUERYTEXT
• PG_USER

Wenn Sie den Connector redshift-raw-logs mit dem Flag --assessment verwenden, werden die folgenden zusätzlichen Tabellen und Ansichten extrahiert:

• STL_QUERY_METRICS
• SVL_QUERY_QUEUE_INFO
• STL_WLM_QUERY

Informationen zu den Systemansichten und Tabellen in Redshift finden Sie unter Redshift-Systemansichten und Redshift-Systemkatalogtabellen.

Apache Hive/Spark oder Trino/PrestoSQL

Das dwh-migration-dumper-Tool unterstützt nur die Authentifizierung beim Apache Hive-Metastore über Kerberos. Daher werden die Flags --user und --password nicht verwendet. Verwenden Sie stattdessen das Flag --hive-kerberos-url, um die Kerberos-Authentifizierungsdetails anzugeben.

In der folgenden Tabelle werden die Flags beschrieben, die häufig zum Extrahieren von Apache Hive-, Spark-, Presto- oder Trino-Metadaten mithilfe des Extraktionstools verwendet werden. Informationen zu allen unterstützten Flags finden Sie unter Globale Flags.

Name	Standardwert	Beschreibung	Erforderlich
--assessment		Aktiviert den Bewertungsmodus beim Extrahieren von Metadaten. Das dwh-migration-dumper-Tool generiert die erforderlichen Metadatenstatistiken für die BigQuery-Migrationsbewertung, wenn für die Metadatenextraktion verwendet.	Für die Bewertung erforderlich. Für die Übersetzung nicht erforderlich.
--connector		Der Name des zu verwendenden Connectors, in diesem Fall hiveql.	Ja
--hive-metastore-dump-partition-metadata	wahr	Verwirft das dwh-migration-dumper-Tool zur Extraktion von Partitionsmetadaten. Sie können dieses Flag aufgrund von Auswirkungen auf die Leistung des Thrift-Clients für Produktions-Metastores mit einer erheblichen Anzahl von Partitionen auf false setzen. Dies verbessert die Leistung des Extraktionstools, führt jedoch zu einem gewissen Verlust der Partitionsoptimierung auf BigQuery-Seite. Verwenden Sie dieses Flag nicht mit dem Flag --assessment, da es keine Auswirkungen hat.	Nein
--hive-metastore-version	2.3.6	Wenn Sie das dwh-migration-dumper-Tool ausführen, wird die entsprechende Thrift-Spezifikation ausgewählt, die basierend auf dem Wert dieses Flags für die Kommunikation mit Ihrem Apache Hive-Server verwendet wird. Wenn das Extraktionstool keine entsprechende Thrift-Spezifikation hat, verwendet es den 2.3.6-Client und gibt eine Warnung an stdout aus. Wenden Sie sich in diesem Fall an den Support und geben Sie die angeforderte Apache Hive-Versionsnummer an.	Nein
--host	localhost	Der Hostname oder die IP-Adresse des Datenbankservers.	Nein
--port	9083	Der Port des Datenbankservers.	Nein
--hive-kerberos-url		Der Kerberos-Principal und -Host für die Authentifizierung.	Erforderlich für Cluster mit aktivierter Kerberos-Authentifizierung.
-Dhiveql.rpc.protection		Die RPC-Schutzkonfigurationsebene. Dies bestimmt die Qualität des Schutzes (QOP) der SASL-Verbindung (Simple Authentication and Security Layer) zwischen dem Cluster und dem dwh-migration-dumper-Tool. Muss dem Wert des Parameters hadoop.rpc.protection in der Datei /etc/hadoop/conf/core-site.xml im Cluster entsprechen, mit einem der folgenden Werte: authentication integrity privacy Beispiel (Bash): -Dhiveql.rpc.protection=privacy Beispiel (Windows PowerShell): "-Dhiveql.rpc.protection=privacy"	Erforderlich für Cluster mit aktivierter Kerberos-Authentifizierung.

Beispiele

Das folgende Beispiel zeigt, wie Sie eine Extraktion von Metadaten aus einer Hive 2.3.7-Datenbank auf einem bestimmten Host ohne Authentifizierung ausführen und dabei einen alternativen Port für die Verbindung verwenden:

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

Melden Sie sich als Nutzer mit Leseberechtigungen für den Hive-Metastore an und generieren Sie ein Kerberos-Ticket, um die Kerberos-Authentifizierung zu verwenden. Generieren Sie dann die Metadaten-ZIP-Datei mit dem folgenden Befehl:

JAVA_OPTS="-Djavax.security.auth.useSubjectCredsOnly=false" \
  dwh-migration-dumper \
  --connector hiveql \
  --host host \
  --port port \
  --hive-kerberos-url principal/kerberos_host

Azure Synapse oder Microsoft SQL Server

Damit das dwh-migration-dumper-Tool eine Verbindung zu Azure Synapse oder Microsoft SQL Server herstellen kann, laden Sie den JDBC-Treiber von der Downloadseite von Microsoft herunter.

In der folgenden Tabelle werden die Flags beschrieben, die häufig zum Extrahieren von Azure Synapse- oder Microsoft SQL Server-Metadaten mithilfe des Extraktionstools verwendet werden. Informationen zu allen unterstützten Flags finden Sie unter Globale Flags.

Name	Standardwert	Beschreibung	Erforderlich
--connector		Der Name des zu verwendenden Connectors, in diesem Fall sqlserver.	Ja
--database		Der Name der Datenbank, zu der eine Verbindung hergestellt werden soll.	Ja
--driver		Der absolute oder relative Pfad zur JAR-Datei des Treibers, die für diese Verbindung verwendet werden soll. Sie können mehrere JAR-Treiberdateien angeben, indem Sie sie durch Kommas trennen.	Ja
--host	localhost	Der Hostname oder die IP-Adresse des Datenbankservers.	Nein
--password		Das Passwort für die Datenbankverbindung.	Ja
--port	1.433	Der Port des Datenbankservers.	Nein
--user		Der Nutzername für die Datenbankverbindung.	Ja

Beispiele

Das folgende Beispiel zeigt, wie Sie eine Extraktion von Metadaten aus einer Azure Synapse-Datenbank auf einem bestimmten Host ausführen:

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

Netezza

Damit das dwh-migration-dumper-Tool eine Verbindung zu IBM Netezza herstellen kann, benötigen Sie den zugehörigen JDBC-Treiber. Den Treiber können Sie in der Regel aus dem Verzeichnis /nz/kit/sbin auf Ihrem IBM Netezza-Appliance-Host abrufen. Wenn Sie die Datei dort nicht finden, bitten Sie Ihren Systemadministrator um Hilfe oder lesen Sie JDBC installieren und konfigurieren in der IBM Netezza-Dokumentation.

In der folgenden Tabelle sind die Flags aufgeführt, die häufig zum Extrahieren von IBM Netezza-Metadaten mit dem Extraktionstool verwendet werden. Informationen zu allen unterstützten Flags finden Sie unter Globale Flags.

Name	Standardwert	Beschreibung	Erforderlich
--connector		Der Name des zu verwendenden Connectors, in diesem Fall netezza.	Ja
--database		Eine Liste der Datenbanken für die Extraktion, durch Kommas getrennt.	Ja
--driver		Der absolute oder relative Pfad zur JAR-Datei des Treibers, die für diese Verbindung verwendet werden soll. Sie können mehrere JAR-Treiberdateien angeben, indem Sie sie durch Kommas trennen.	Ja
--host	localhost	Der Hostname oder die IP-Adresse des Datenbankservers.	Nein
--password		Das Passwort für die Datenbankverbindung.	Ja
--port	5480	Der Port des Datenbankservers.	Nein
--user		Der Nutzername für die Datenbankverbindung.	Ja

Beispiele

Das folgende Beispiel zeigt, wie Sie eine Extraktion von Metadaten für zwei IBM Netezza-Datenbanken auf einem bestimmten Host ausführen:

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

Oracle

Damit das dwh-migration-dumper-Tool eine Verbindung zu Oracle herstellen kann, laden Sie den JDBC-Treiber von der Downloadseite von Oracle herunter.

In der folgenden Tabelle werden die Flags beschrieben, die häufig zum Extrahieren von Oracle-Metadaten mithilfe des Extraktionstools verwendet werden. Informationen zu allen unterstützten Flags finden Sie unter Globale Flags.

Name	Standardwert	Beschreibung	Erforderlich
--connector		Der Name des zu verwendenden Connectors, in diesem Fall Oracle.	Ja
--driver		Der absolute oder relative Pfad zur JAR-Datei des Treibers, die für diese Verbindung verwendet werden soll. Sie können mehrere JAR-Treiberdateien angeben, indem Sie sie durch Kommas trennen.	Ja
--host	localhost	Der Hostname oder die IP-Adresse des Datenbankservers.	Nein
--oracle-service		Der Oracle-Dienstname, der für die Verbindung verwendet werden soll.	Nicht explizit, aber Sie müssen entweder dieses Flag oder das Flag --oracle-sid angeben.
--oracle-sid		Die Oracle-Systemkennung (Oracle System Identifier, SID), die für die Verbindung verwendet werden soll.	Nicht explizit, aber Sie müssen entweder dieses Flag oder das Flag --oracle-service angeben.
--password		Das Passwort für die Datenbankverbindung.	Wenn keine Angabe erfolgt, verwendet das Extraktionstool eine sichere Eingabeaufforderung, um sie anzufordern.
--port	1521	Der Port des Datenbankservers.	Nein
--user		Der Nutzername für die Datenbankverbindung. Der angegebene Nutzer muss die Rolle SELECT_CATALOG_ROLE haben, um Metadaten extrahieren zu können. Führen Sie die Abfrage select granted_role from user_role_privs; für die Oracle-Datenbank aus, um festzustellen, ob der Nutzer die erforderliche Rolle hat.	Ja

Beispiele

Das folgende Beispiel zeigt, wie Sie eine Extraktion von Metadaten aus einer Oracle-Datenbank auf einem bestimmten Host ausführen und dabei den Oracle-Dienst für die Verbindung verwenden:

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

Snowflake

In der folgenden Tabelle werden die Flags beschrieben, die häufig zum Extrahieren von Schneeflockenmetadaten mit dem dwh-migration-dumper-Tool verwendet werden. Informationen zu allen unterstützten Flags finden Sie unter Globale Flags.

Name	Standardwert	Beschreibung	Erforderlich
--connector		Der Name des zu verwendenden Connectors, in diesem Fall Snowflake.	Ja
--database		Der Name der Datenbank, zu der eine Verbindung hergestellt werden soll. Sie können jeweils nur aus einer Datenbank aus Snowflake extrahieren.	Ja
--host	localhost	Der Hostname oder die IP-Adresse des Datenbankservers.	Nein
--password		Das Passwort für die Datenbankverbindung.	Wenn keine Angabe erfolgt, verwendet das Extraktionstool eine sichere Eingabeaufforderung, um sie anzufordern.
--role		Die für die Autorisierung zu verwendende Snowflake-Rolle. Diese müssen Sie nur bei großen Installationen angeben, bei denen Sie Metadaten aus dem Schema SNOWFLAKE.ACCOUNT_USAGE anstelle von INFORMATION_SCHEMA abrufen müssen. Weitere Informationen finden Sie unter Mit großen Snowflake-Instanzen arbeiten.	Nein
--user		Der Nutzername für die Datenbankverbindung.	Ja
--warehouse		Das Snowflake-Warehouse zur Verarbeitung von Metadatenabfragen	Ja

Beispiele

Das folgende Beispiel zeigt, wie Sie eine Exraktion von Metadaten aus einer Snowflake-Datenbank mit typischer Größe auf dem lokalen Host ausführen:

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

Das folgende Beispiel zeigt, wie Sie eine Extraktion von Metadaten aus einer großen Snowflake-Datenbank auf dem lokalen Host ausführen:

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

Mit großen Snowflake-Instanzen arbeiten

Das dwh-migration-dumper-Tool liest Metadaten aus der Schneeflocke INFORMATION_SCHEMA. Die Datenmenge, die von INFORMATION_SCHEMA abgerufen werden kann, ist jedoch begrenzt. Wenn Sie das Extraktionstool ausführen und der Fehler SnowflakeSQLException: Information schema query returned too much data angezeigt wird, müssen Sie folgendermaßen vorgehen, damit Sie Metadaten aus dem Schema SNOWFLAKE.ACCOUNT_USAGE lesen können:

1. Öffnen Sie die Option Freigaben in der Snowflake-Weboberfläche.

2. Erstellen Sie eine Datenbank aus der SNOWFLAKE.ACCOUNT_USAGE-Freigabe:

   -- CREATE DATABASE database FROM SHARE SNOWFLAKE.ACCOUNT_USAGE;
   

3. Erstellen Sie eine Rolle:

   CREATE ROLE role;
   

4. Weisen Sie der Rolle IMPORTED-Berechtigungen für die neue Datenbank zu:

   GRANT IMPORTED PRIVILEGES ON DATABASE database TO ROLE role;
   

5. Weisen Sie die Rolle dem Nutzer zu, den Sie zum Ausführen des dwh-migration-dumper-Tools verwenden möchten:

   GRANT ROLE role TO USER user;
   

Vertica

Damit das dwh-migration-dumper-Tool eine Verbindung zu Vertica herstellen kann, laden Sie den JDBC-Treiber von der Downloadseite herunter.

In der folgenden Tabelle werden die häufig verwendeten Flags zum Extrahieren von Vertica-Metadaten mit dem Extraktionstool beschrieben. Informationen zu allen unterstützten Flags finden Sie unter Globale Flags.

Name	Standardwert	Beschreibung	Erforderlich
--connector		Der Name des zu verwendenden Connectors, in diesem Fall Vertica.	Ja
--database		Der Name der Datenbank, zu der eine Verbindung hergestellt werden soll.	Ja
--driver		Der absolute oder relative Pfad zur JAR-Datei des Treibers, die für diese Verbindung verwendet werden soll. Sie können mehrere JAR-Treiberdateien angeben, indem Sie sie durch Kommas trennen.	Ja
--host	localhost	Der Hostname oder die IP-Adresse des Datenbankservers.	Nein
--password		Das Passwort für die Datenbankverbindung.	Ja
--port	5433	Der Port des Datenbankservers.	Nein
--user		Der Nutzername für die Datenbankverbindung.	Ja

Beispiele

Das folgende Beispiel zeigt, wie Sie eine Extraktion von Metadaten aus einer Vertica-Datenbank auf dem lokalen Host ausführen:

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

Globale Flags

In der folgenden Tabelle werden die Flags beschrieben, die mit jeder der unterstützten Quellplattformen verwendet werden können.

Name	Beschreibung
--connector	Der Connector-Name für das Quellsystem.
--database	Die Nutzung variiert je nach Quellsystem.
--driver	Der absolute oder relative Pfad zur JAR-Datei der Treiber, die beim Herstellen einer Verbindung zum Quellsystem verwendet werden soll. Sie können mehrere JAR-Treiberdateien angeben, indem Sie sie durch Kommas trennen.
--dry-run oder -n	Zeigt, welche Maßnahmen das Extraktionstool ergreifen würde, ohne sie auszuführen.
--help	Zeigt die Befehlszeilenhilfe an.
--host	Der Hostname oder die IP-Adresse des Datenbankservers, zu dem eine Verbindung hergestellt werden soll.
--jdbcDriverClass	Überschreibt optional den vom Anbieter angegebenen JDBC-Treiberklassennamen. Verwenden Sie diese Option, wenn Sie einen benutzerdefinierten JDBC-Client haben.
--output	Der Pfad der ZIP-Ausgabedatei. Beispiel: dir1/dir2/teradata-metadata.zip. Wenn Sie keinen Pfad angeben, wird die Ausgabedatei in Ihrem Arbeitsverzeichnis erstellt. Wenn Sie den Pfad zu einem Verzeichnis angeben, wird der Standard-ZIP-Dateiname im angegebenen Verzeichnis erstellt. Wenn das Verzeichnis nicht vorhanden ist, wird es erstellt. Verwenden Sie das folgende Format, um Cloud Storage zu verwenden: gs://<BUCKET>/<PATH> Informationen zur Authentifizierung mit Google Cloud-Anmeldedaten finden Sie unter Für die Verwendung von Clientbibliotheken authentifizieren.
--password	Das Passwort für die Datenbankverbindung.
--port	Der Port des Datenbankservers.
--save-response-file	Speichert Ihre Befehlszeilen-Flags in einer JSON-Datei, um die Wiederverwendung zu erleichtern. Die Datei hat den Namen dumper-response-file.json und wird im Arbeitsverzeichnis erstellt. Um die Antwortdatei zu verwenden, geben Sie den Pfad zu diesem mit dem Präfix @ an, wenn Sie das Extraktionstool ausführen, z. B. dwh-migration-dumper @path/to/dumper-response-file.json.
--schema	Eine Liste der Schemas für die Extraktion, durch Kommas getrennt. Oracle unterscheidet nicht zwischen einem Schema und dem Datenbanknutzer, der das Schema erstellt hat. Sie können also entweder Schemanamen oder Nutzernamen mit dem Flag --schema verwenden. Beispiel: --schema schema1,user2,schema3
--thread-pool-size	Legt die Größe des Threadpools fest, die sich auf die Größe des Verbindungspools auswirkt. Die Standardgröße des Thread-Pools ist die Anzahl der Kerne auf dem Server, auf dem das dwh-migration-dumper-Tool ausgeführt wird. Wenn das Extraktionstool langsam ist oder anderweitig mehr Ressourcen benötigt, können Sie die Anzahl der verwendeten Threads erhöhen. Wenn es Hinweise darauf gibt, dass andere Prozesse auf dem Server mehr Bandbreite benötigen, können Sie die Anzahl der verwendeten Threads verringern.
--url	Die URL, die für die Datenbankverbindung verwendet werden soll, anstelle des URI, der vom JDBC-Treiber generiert wird. Der generierte URI sollte in den meisten Fällen ausreichend sein. Überschreiben Sie den generierten URI nur, wenn Sie eine JDBC-Verbindungseinstellung verwenden müssen, die für die Quellplattform spezifisch ist und nicht bereits durch eines der in dieser Tabelle aufgeführten Flags festgelegt ist.
--user	Der Nutzername für die Datenbankverbindung.
--version	Zeigt die Produktversion an.

Fehlerbehebung

In diesem Abschnitt werden einige häufige Probleme und Techniken zur Fehlerbehebung für das dwh-migration-dumper-Tool erläutert.

Fehler aufgrund fehlenden Speichers

Der Fehler java.lang.OutOfMemoryError in der Terminalausgabe des dwh-migration-dumper-Tools hängt häufig mit dem unzureichenden Speicher für die Verarbeitung abgerufener Daten zusammen. Erhöhen Sie den verfügbaren Speicher oder reduzieren Sie die Anzahl der Verarbeitungsthreads, um dieses Problem zu beheben.

Sie können den maximalen Arbeitsspeicher erhöhen, indem Sie die Umgebungsvariable JAVA_OPTS exportieren:

Linux

export JAVA_OPTS="-Xmx4G"

Windows

set JAVA_OPTS="-Xmx4G"

Sie können die Anzahl der Verarbeitungsthreads reduzieren (Standard ist 32), indem Sie das Flag --thread-pool-size angeben. Diese Option wird nur für die Connectors hiveql und redshift* unterstützt.

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

Umgang mit dem Fehler WARN...Task failed

Manchmal wird in der Terminalausgabe des dwh-migration-dumper-Tools der Fehler WARN [main] o.c.a.d.MetadataDumper [MetadataDumper.java:107] Task failed: … angezeigt. Das Extraktionstool sendet mehrere Abfragen an das Quellsystem und die Ausgabe jeder Abfrage wird in eine eigene Datei geschrieben. Dieses Problem zeigt an, dass eine dieser Abfragen fehlgeschlagen ist. Das Fehlschlagen einer Abfrage verhindert jedoch nicht die Ausführung der anderen Abfragen. Wenn mehrere WARN-Fehler angezeigt werden, prüfen Sie die Problemdetails und prüfen Sie, ob Sie etwas korrigieren müssen, damit die Abfrage ordnungsgemäß ausgeführt wird. Wenn der beim Ausführen des Extraktionstools angegebenen Datenbanknutzer beispielsweise nicht berechtigt ist, alle Metadaten zu lesen, versuchen Sie es mit einem Nutzer mit den richtigen Berechtigungen noch einmal.

Beschädigte ZIP-Datei

Laden Sie die Datei SHA256SUMS.txt herunter und führen Sie den folgenden Befehl aus, um die ZIP-Datei des dwh-migration-dumper-Tools zu validieren:

sha256sum --check SHA256SUMS.txt

Das Ergebnis OK bestätigt die erfolgreiche Prüfsummenverifizierung. Jede andere Meldung weist auf einen Verifizierungsfehler hin:

• FAILED: computed checksum did NOT match: Die ZIP-Datei ist beschädigt und muss noch einmal heruntergeladen werden.
• FAILED: listed file could not be read: Die Version der ZIP-Datei kann nicht gefunden werden. Achten Sie darauf, dass die Prüfsumme und die ZIP-Dateien aus derselben Releaseversion heruntergeladen und im selben Verzeichnis gespeichert werden.

Extraktion von Teradata-Abfragelogs ist langsam

Zur Verbesserung der Leistung von Join-Tabellen, die mit den Flags -Dteradata-logs.query-logs-table und -Dteradata-logs.sql-logs-table angegeben werden, können Sie eine zusätzliche Spalte vom Typ DATE in der Bedingung JOIN einfügen. “ Diese Spalte muss in beiden Tabellen definiert sein und Teil des partitionierten primären Index sein. Verwenden Sie das Flag -Dteradata-logs.log-date-column, um diese Spalte einzuschließen.

Beispiel:

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"

Größenbeschränkung für Teradata-Zeilen überschritten

Teradata 15 hat eine Zeilengröße von 64 KB. Wenn das Limit überschritten wird, schlägt die Dumper mit der folgenden Meldung fehl: none [Error 9804] [SQLState HY000] Response Row size or Constant Row size overflow

Zur Behebung dieses Fehlers erweitern Sie entweder das Zeilenlimit auf 1 MB oder teilen die Zeilen in mehrere Zeilen auf:

• Installieren und aktivieren Sie das Feature „1MB Perm and Response Rows“ und die aktuelle TTU-Software. Weitere Informationen finden Sie unter Teradata Database Message 9804.
• Teilen Sie den langen Abfragetext mithilfe der Flags -Dteradata.metadata.max-text-length und -Dteradata-logs.max-sql-length in mehrere Zeilen auf.

Der folgende Befehl zeigt die Verwendung des Flags -Dteradata.metadata.max-text-length auf, um den langen Abfragetext in mehrere Zeilen mit jeweils maximal 10.000 Zeichen aufzuteilen:

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"

Der folgende Befehl zeigt die Verwendung des Flags -Dteradata-logs.max-sql-length auf, um den langen Abfragetext in mehrere Zeilen mit jeweils maximal 10.000 Zeichen aufzuteilen:

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"

Nächste Schritte

Nachdem Sie das dwh-migration-dumper-Tool ausgeführt haben, laden Sie die Ausgabe zusammen mit den Quelldateien zur Übersetzung in Cloud Storage hoch.