Daten aus Teradata migrieren

Durch die Kombination des BigQuery Data Transfer Service und eines speziellen Migrations-Agents können Sie Ihre Daten von einer lokalen Teradata Data Warehouse-Instanz nach BigQuery kopieren. In diesem Dokument wird der schrittweise Prozess der Datenmigration aus Teradata mithilfe des BigQuery Data Transfer Service beschrieben.

Vorbereitung

Stellen Sie sicher, dass Sie die folgenden Voraussetzungen erfüllt haben, um für eine erfolgreiche Teradata Data Warehouse-Migration zu sorgen.

Google Cloud-Anforderungen

  1. Wählen Sie ein Google Cloud-Projekt zum Speichern Ihrer Migrationsdaten aus oder erstellen Sie eins. Sie müssen über owner-Berechtigungen für das Google Cloud-Projekt verfügen, um die Übertragung einzurichten.

    • Rufen Sie in der Google Cloud Console die Seite für die Projektauswahl auf.

      Zur Projektauswahl

    • Wählen Sie ein Google Cloud-Projekt aus oder erstellen Sie eines.

  2. Aktivieren Sie diese Google Cloud APIs.

    Console

    Klicken Sie in der Cloud Console auf den beiden folgenden Seiten auf AKTIVIEREN.

    BigQuery ist in neuen Projekten automatisch aktiviert. Für ein vorhandenes Projekt müssen Sie möglicherweise die BigQuery API aktivieren.

    Beispiel:

    API aktivieren.

    Ein grünes Häkchen zeigt an, dass Sie die API bereits aktiviert haben.

    Aktivierte API.

    gcloud

    Optional können Sie die APIs mit dem gcloud-Befehlszeilentool aktivieren.

    So können Sie gcloud-Befehle in Cloud Shell ausführen oder das gcloud-Tool herunterladen und auf dem lokalen Computer installieren:

    Geben Sie die folgenden gcloud-Befehle ein:

    gcloud services enable bigquerydatatransfer.googleapis.com
    gcloud services enable storage-component.googleapis.com
    gcloud services enable pubsub.googleapis.com
    

    BigQuery ist in neuen Projekten automatisch aktiviert. Aktivieren Sie für ein vorhandenes Projekt auch die BigQuery API.

    gcloud services enable bigquery.googleapis.com
    
  3. Erstellen Sie ein BigQuery-Dataset zum Speichern Ihrer Daten. Sie müssen keine Tabellen erstellen.

  4. Erstellen Sie ein IAM-Dienstkonto (Identitäts- und Zugriffsverwaltung). Informationen zum Erstellen eines Dienstkontos finden Sie unter Dienstkonten erstellen und verwalten.

  5. Gewähren Sie dem Dienstkonto folgende IAM-Rollen: Siehe Rollen für Dienstkonten gewähren.

    • BigQuery: Die vordefinierte IAM-Rolle bigquery.admin.
    • Cloud Storage: Die vordefinierte IAM-Rolle storage.objectAdmin.
  6. Erstellen Sie einen Cloud Storage-Bucket für das Staging der Daten. Sie verwenden diesen Bucket-Namen später im Migrationsprozess.

Lokale Anforderungen

  1. Lokale Anforderungen an Maschinen
    • Der Migrations-Agent verwendet eine JDBC-Verbindung mit der Teradata-Instanz und Google Cloud APIs. Achten Sie darauf, dass der Netzwerkzugriff nicht von einer Firewall blockiert wird.
    • Prüfen Sie, ob die Java-Laufzeitumgebung 8 oder höher installiert ist.
    • Stellen Sie sicher, dass Sie über den empfohlenen Mindestspeicherplatz verfügen, wie unter Staging-Speicherplatzbedarf beschrieben.
  2. Details zur Teradata-Verbindung
    • Benutzername und Kennwort eines Nutzers mit Lesezugriff auf die Systemtabellen und die zu migrierenden Tabellen.
    • Hostname und Portnummer zur Verbindung mit der Teradata-Instanz.
  3. Laden Sie die erforderlichen JDBC-Treiber von Teradata herunter: tdgssconfig.jar and terajdbc4.jar.
  4. Laden Sie Ihre Google Cloud-Anmeldedaten herunter.

Übertragungsmodi und -optionen

Da für jede Migration spezielle Anforderungen gelten, kann der Migrations-Agent auf folgende Arten angepasst werden. Beim Einrichten einer Datenübertragung von Teradata zu BigQuery gibt es drei Hauptoptionen:

Extraktionsmethode

BigQuery Data Transfer Service unterstützt zwei verschiedene Extraktionsmethoden für die Übertragung von Daten von Teradata zu BigQuery:

  1. Extraktion mit JDBC-Treiber und FastExport-Verbindung: In diesem Modus wird eine Tabelle in eine Sammlung von AVRO-Dateien an einen angegebenen Speicherort in einem lokalen Dateisystem extrahiert. Die extrahierten Dateien werden dann in einen bestimmten Cloud Storage-Bucket hochgeladen. Nach erfolgreicher Übertragung werden die Dateien aus dem lokalen Dateisystem gelöscht.
    • Beschränkungen beim Speicherplatz in einem lokalen Dateisystem werden erzwungen. Die Extraktion wird pausiert, bis extrahierte Dateien aus dem lokalen Dateisystem hochgeladen und gelöscht werden.
    • Wenn es enge Einschränkungen für den lokalen Speicherplatz gibt oder TPT nicht verfügbar ist, verwenden Sie diese Extraktionsmethode.
    • Die Standardextraktionsmethode ist ein JDBC-Treiber mit FastExport.
  2. Extraktion mit dem tbuild-Dienstprogramm "Teradata Parallel Transporter (TPT)". In diesem Modus versucht ein Agent, Extraktionsbatches mithilfe von Zeilen zu berechnen, die nach Partitionen verteilt sind. Für jeden Batch wird ein TPT-Extraktionsskript ausgegeben und ausgeführt, das einen Satz von durch Trennzeichen getrennten Dateien erzeugt. Nach jeder Batchextraktion werden Dateien in einen bestimmten Cloud Storage-Bucket hochgeladen und aus dem lokalen Dateisystem gelöscht. Beschränkungen beim Speicherplatz im lokalen Dateisystem werden nicht erzwungen. Sie müssen daher dafür sorgen, dass das lokale Dateisystem über genügend Speicherplatz verfügt, um die größte Partition in einer Teradata-Tabelle zu extrahieren.
    • Wir empfehlen, mit TPT zu extrahieren und Ihr Schema anzupassen, um Partitionsspalten anzugeben. Dies führt zur schnellsten Datenextraktion.

Weitere Informationen zum Angeben der Extraktionsmethode finden Sie im Abschnitt Konfiguration für den Migrations-Agent in der schrittweisen Anleitung zum Einrichten von Übertragungen.

Benutzerdefinierte Schemadatei

Eine Schemadatei ist eine JSON-Datei, die Datenbankobjekte beschreibt. Das Schema enthält einen Satz Datenbanken, die jeweils eine Gruppe von Tabellen enthalten, von denen jede eine Gruppe von Spalten enthält. Jede Spalte hat das Feld Typ – ein Typ, der einer Spalte in BigQuery zugewiesen ist.

In einer Schemadatei hat jedes Objekt das Feld Name – einen Namen, der diesem in BigQuery zugewiesen wird. Jedes Objekt hat außerdem das Feld originalName – den Namen des übereinstimmenden Objekts in der Teradata-Datenbank.

BigQuery Data Transfer Service bietet eine automatische Schemaerkennung und Datenkonvertierung während einer Datenübertragung von Teradata zu BigQuery. Optional können Sie eine benutzerdefinierte Schemadatei angeben. Die Anpassung von Schemas wird in einigen Situationen dringend empfohlen. Beispiele:

  • Eine benutzerdefinierte Schemadatei ist besonders nützlich, um zusätzliche Informationen zu einer Tabelle wie die Partitionierung aufzunehmen, die ohne die Nennung einer Schemadatei bei der Migration verloren gehen würden.
  • Sie können eine benutzerdefinierte Schemadatei angeben, um Felder wie Name eines beliebigen Objekts oder das Array usageType einer beliebigen Spalte während der Datenübertragung zu transformieren.
  • Weitere Informationen finden Sie unter Benutzerdefinierte Schemadatei.

On-Demand- oder inkrementelle Übertragungen

Bei der Migration von Daten aus einer Teradata-Datenbankinstanz zu BigQuery unterstützt BigQuery Data Transfer Service sowohl die einmalige Snapshot-Datenübertragung als auch wiederkehrende, regelmäßige Übertragungen neuer und aktualisierter Zeilen ("inkrementelle Übertragungen") (Beta). Sie legen die Übertragung beim Einrichten einer Übertragung in den Planungsoptionen als On-Demand oder inkrementell fest.

  • On-Demand-Datenübertragung
    • Wenn Ihre Tabelle sehr groß ist und Sie TPT für eine bessere Leistung extrahieren können, empfehlen wir Ihnen, Ihre Teradata-Tabelle so zu partitionieren, dass Partitionen partitionsweise extrahiert werden können. Weitere Informationen finden Sie unter Benutzerdefinierte Schemadatei.
    • Wenn Ihre Tabellen klein sind oder Sie TPT nicht verwenden können, befolgen Sie die grundlegende Anleitung. Die Anpassung von Schemas ist nicht erforderlich.
  • Inkrementelle Datenübertragung
    • Wenn Sie regelmäßig Änderungen von Teradata zu BigQuery migrieren möchten, können Sie den inkrementellen Modus verwenden. Auf wiederkehrender Basis werden neue und geänderte Datensätze aus Teradata an BigQuery-Tabellen angehängt.
    • Bei dieser Methode müssen Sie Ihr Schema anpassen, um COMMIT_TIMESTAMP-Spalten mit Anmerkungen zu versehen.
    • Beim Einrichten inkrementeller Übertragungen gelten bestimmte Bedingungen. Weitere Informationen finden Sie unter Inkrementelle Übertragungen.

Teradata-Migration einrichten

In diesem Abschnitt wird die Einrichtung einer Datenmigration von Teradata zu BigQuery Schritt für Schritt beschrieben. Folgende Schritte sind auszuführen:

  • Laden Sie den Migrations-Agent herunter.
  • Richten Sie eine Übertragung mit dem BigQuery Data Transfer Service ein.
  • Initialisieren Sie den Migrations-Agent.
  • Führen Sie den Migrations-Agent aus.

Migrations-Agent herunterladen

Verwenden Sie diesen Link, um den Migrations-Agent auf den lokalen Computer herunterzuladen, auf dem sich das Data Warehouse befindet.

Nachdem Sie den Migrations-Agent installiert haben, richten Sie eine Übertragung mit dem BigQuery Data Transfer Service ein, initialisieren den Migrations-Agent und führen den Agent aus, um die Datenmigration zu starten.

Übertragung einrichten

Erstellen Sie eine Übertragung mit dem BigQuery Data Transfer Service.

Console

  1. Rufen Sie in der Cloud Console die Seite „BigQuery“ auf.

    Zur Seite „BigQuery“

  2. Klicken Sie auf Übertragungen.

  3. Klicken Sie auf Create Transfer (Übertragung erstellen).

  4. Tun Sie unter Quelltyp Folgendes:

    • Wählen Sie Migration: Teradata.
    • Geben Sie als Konfigurationsname für Übertragung den Namen für die Übertragung ein, der angezeigt werden soll, z. B. My Migration. Der angezeigte Name kann ein beliebiger Wert sein, mit dem Sie die Übertragung leicht identifizieren können, wenn Sie sie später ändern müssen.
    • (Optional) Unter Zeitplanoptionen können Sie den Standardwert Täglich (basierend auf dem Zeitpunkt der Erstellung) belassen oder eine andere Uhrzeit auswählen.
    • Wählen Sie für Zieleinstellungen das entsprechende Dataset aus.

      Neue Teradata-Migration allgemein.

  5. Fahren Sie unter Details zur Datenquelle mit spezifischen Details für Ihre Teradata-Übertragung fort.

    • Wählen Sie als Datenbanktyp Teradata aus.
    • Suchen Sie unter Cloud Storage-Bucket nach dem Namen des Cloud Storage-Buckets für das Staging der Migrationsdaten. Geben Sie nicht das Präfix gs:// ein, sondern geben Sie nur den Bucket-Namen ein.
    • Geben Sie unter Datenbankname den Namen der Quellendatenbank in Teradata ein.
    • Geben Sie für Tabellennamensmuster () ein Muster für übereinstimmende Tabellennamen in der Quelldatenbank ein. Sie können das Muster mit regulären Ausdrücken angeben. Das Muster sollte der Java-Syntax für reguläre Ausdrücke folgen.
    • Geben Sie unter E-Mail-Adresse des Dienstkontos die E-Mail-Adresse ein, die dem von Ihnen erstellten IAM-Dienstkonto zugeordnet ist.
    • (Optional) Geben Sie als Schemadateipfad den Pfad und den Dateinamen einer JSON-Schemadatei ein. Wird keine Schemadatei eingegeben, so erkennt BigQuery das Tabellenschema automatisch auf Basis der übertragenen Quelldaten. Sie können Ihre eigene Schemadatei erstellen, wie im folgenden Beispiel gezeigt, oder den Migrations-Agent verwenden, um eine Schemadatei zu erstellen. Informationen zum Erstellen einer Schemadatei finden sich im Abschnitt Migrations-Agent initialisieren.

      Neue Teradata-Migration

    • Optional: Im Abschnitt Notification options (Benachrichtigungsoptionen):

      • Klicken Sie auf die Umschaltfläche, um E-Mail-Benachrichtigungen zu aktivieren. Wenn Sie diese Option aktivieren, erhält der Übertragungsadministrator eine E-Mail-Benachrichtigung, wenn ein Übertragungsvorgang fehlschlägt.
      • Wählen Sie unter Pub/Sub-Thema auswählen Ihr Thema aus oder klicken Sie auf Thema erstellen. Mit dieser Option werden Pub/Sub-Ausführungsbenachrichtigungen für Ihre Übertragung konfiguriert.

        Pub/Sub-Thema

  6. Klicken Sie auf Speichern.

  7. Die Cloud Console zeigt alle Details zur Übertragungseinrichtung an, einschließlich eines Ressourcennamens für diese Übertragung. Notieren Sie sich den Ressourcennamen, da Sie ihn später eingeben müssen, wenn Sie den Migrations-Agent ausführen.

    Übertragungsbestätigung

bq

Geben Sie den Befehl bq mk ein, und geben Sie das Flag --transfer_config für die Übertragungserstellung an. Folgende Flags sind ebenfalls erforderlich:

  • --data_source
  • --display_name
  • --target_dataset
  • --params
bq mk \
--transfer_config \
--project_id=project ID \
--target_dataset=dataset \
--display_name=name \
--params='parameters' \
--data_source=data source

Dabei gilt:

  • project ID ist die Projekt-ID. Wenn --project_id nicht bereitgestellt wird, um ein bestimmtes Projekt anzugeben, wird das Standardprojekt verwendet.
  • dataset ist das Dataset, auf das Sie die Übertragungskonfiguration abzielen möchten (--target_dataset).
  • name ist der Anzeigename (--display_name) für die Übertragungskonfiguration. Der angezeigte Name der Übertragung kann ein beliebiger Wert sein, mit dem Sie die Übertragung leicht identifizieren können, wenn Sie sie später ändern müssen.
  • parameters enthält die Parameter (--params) für die erstellte Übertragungskonfiguration im JSON-Format. Beispiel: --params='{"param":"param_value"}'.
    • Für Teradata-Migrationen sind folgende Parameter erforderlich: bucket, database_type, agent_service_account, database_name, table_name_patterns.
      • bucket ist der Cloud Storage-Bucket, der während der Migration als Staging-Bereich fungiert.
      • database_type ist Teradata.
      • agent_service_account ist die E-Mail-Adresse, die mit dem Dienstkonto, das Sie erstellt haben, verknüpft ist.
      • database_name ist der Name der Quelldatenbank in Teradata.
      • table_name_patterns ist ein oder mehrere Muster zum Abgleich der Tabellennamen in der Quelldatenbank. Sie können das Muster mit regulären Ausdrücken angeben. Das Muster sollte der Java-Syntax für reguläre Ausdrücke folgen.
  • data_source ist die Datenquelle (--data_source): on_premises.

Beispiel: Mit folgendem Befehl wird eine Teradata-Übertragung namens My Transfer mit dem Cloud Storage-Bucket mybucket und dem Ziel-Dataset mydataset erstellt. Bei der Übertragung werden alle Tabellen aus dem Teradata Data Warehouse mydatabase migriert. Die optionale Schemadatei ist myschemafile.json.

bq mk \
--transfer_config \
--project_id=123456789876 \
--target_dataset=MyDataset \
--display_name='My Migration' \
--params='{"bucket": "mybucket", "database_type": "Teradata",
"database_name":"mydatabase", "table_name_patterns": ".*",
"agent_service_account":"myemail@mydomain.com", "schema_file_path":
"gs://mybucket/myschemafile.json"}' \
--data_source=on_premises

Nachdem Sie den Befehl ausgeführt haben, erhalten Sie eine Meldung wie die Folgende:

[URL omitted] Please copy and paste the above URL into your web browser and follow the instructions to retrieve an authentication code.

Folgen Sie der Anleitung und fügen Sie den Authentifizierungscode in die Befehlszeile ein.

API

Verwenden Sie die Methode projects.locations.transferConfigs.create und geben Sie eine Instanz der Ressource TransferConfig an.

Migrations-Agent

Sie können die Übertragung optional direkt vom Migrations-Agent erstellen, wie im Abschnitt Migrations-Agent initialisieren beschrieben.

Um die Übertragung vom Migrations-Agent zu erstellen, müssen Sie dem erstellten Dienstkonto die IAM-Rolle serviceAccessTokenCreator zuweisen.

Sie können die IAM-Rolle auf eine der beiden folgenden Arten zuweisen:

  • Gewähren Sie in der Cloud Console folgende IAM-Rolle Ersteller von Dienstkonto-Tokens: Siehe Dienstkonten Rollen zuweisen.

  • Sie können den folgenden gcloud-Befehl in Cloud Shell oder im gcloud-Befehlszeilentool ausführen:

gcloud projects add-iam-policy-binding user_project_id \
--member='serviceAccount:service-user_project_number@gcp-sa-bigquerydatatransfer.iam.gserviceaccount.com' \
--role='roles/iam.serviceAccountTokenCreator'

Nachdem Sie dem Dienstkonto die serviceAccessTokenCreator-Berechtigung erteilt haben, können Sie mit dem Herunterladen des Migrations-Agent fortfahren und die Übertragung als Teil des Initialisierungsschritts einrichten.

Migrations-Agent initialisieren

Wenn Sie zum ersten Mal eine Datenmigration starten, initialisieren Sie den Migrations-Agent. Die Initialisierung ist nur einmal erforderlich, wenn Sie eine Migrationsübertragung einrichten, unabhängig davon, ob diese wiederholt wird oder nicht.

Diese Sitzung startet die Migration noch nicht, sondern dient nur für die Erstkonfiguration.

  1. Öffnen Sie eine neue Sitzung. In der Befehlszeile starten Sie einen Befehl zum Ausführen der JAR-Datei mit bestimmten Flags in folgender Form:

    java -cp \
    OS-specific-separated-paths-to-jars (JDBC and agent) \
    com.google.cloud.bigquery.dms.Agent \
    --initialize
    

    Unix, Linux, Mac OS

    java -cp \
    /usr/local/migration/Teradata/JDBC/tdgssconfig.jar:/usr/local/migration/Teradata/JDBC/terajdbc4.jar:/usr/local/migration/mirroring-agent.jar \
    com.google.cloud.bigquery.dms.Agent \
    --initialize
    

    Windows

    Kopieren Sie alle Dateien in den Ordner C:\migration (oder passen Sie die Pfade im Befehl an) und führen Sie dann Folgendes aus:

    java -cp C:\migration\tdgssconfig.jar;C:\migration\terajdbc4.jar;C:\migration\mirroring-agent.jar com.google.cloud.bigquery.dms.Agent --initialize
    
  2. Geben Sie auf Aufforderung die folgenden Parameter ein:

    • Ob Sie die TPT-Vorlage (Teradata Parallel Transporter) auf dem Laufwerk speichern möchten. Wenn Sie die TPT-Extraktionsmethode verwenden möchten, können Sie die gespeicherte Vorlage mit Parametern ändern, die zu Ihrer Teradata-Instanz passen.
    • Der URI der Quelldatenbank. Geben Sie gegebenenfalls die Portnummer an.
    • Pfad zu einem temporären lokalen Speicherbereich für die Migration. Stellen Sie sicher, dass Sie über den empfohlenen Mindestspeicherplatz verfügen, wie unter Staging-Speicherplatzbedarf beschrieben.
    • Ob Sie Teradata Parallel Transporter (TPT) als Extraktionsmethode verwenden.
    • (Optional) Pfad zu einer Datei mit Datenbankanmeldedaten.
  3. Wenn Sie zur Eingabe eines Ressourcennamens für den BigQuery Data Transfer Service aufgefordert werden:

    Sie können den Ressourcennamen der in der Cloud Console konfigurierten Übertragung eingeben oder die Übertragung in diesem Moment über den Migrations-Agent selbst erstellen. Optional können Sie den Befehl zur Initialisierung des Migrations-Agent verwenden, um eine Schemadatei zu erstellen. Informationen zu dieser Option finden Sie unten auf dem Tab Migrations-Agent.

    Console

    Geben Sie den Ressourcennamen der Übertragung ein, die Sie zuvor auf dem Tab "Console" des Abschnitts Übertragung einrichten eingerichtet haben.

    Migrations-Agent

    • Geben Sie die Google Cloud-Projekt-ID ein.
    • Geben Sie den Namen der Quelldatenbank in Teradata ein.
    • Geben Sie ein Muster für übereinstimmende Tabellennamen in der Quelldatenbank ein. Sie können das Muster mit regulären Ausdrücken angeben. Das Muster sollte der Java-Syntax für reguläre Ausdrücke folgen.
    • Optional: Geben Sie den Pfad zu einer lokalen JSON-Schemadatei ein (empfohlen für wiederkehrende Übertragungen). Diese Schemadatei wird in Ihren Cloud Storage-Bucket hochgeladen.)
      • Entscheiden Sie, eine neue Schemadatei zu erstellen. In diesem Fall werden Sie nach einem Nutzernamen und Passwort für Teradata gefragt und der Agent erstellt eine JSON-Datei mit einem konvertierten Schema. Die Datei wird in einem lokalen Ordner nach folgendem Muster erstellt: <localpath>/schema/DO_NOT_REMOVE_td2bq_table_schemas_<string>.json. Nach dem Hochladen in Ihren Cloud Storage-Bucket folgen der Pfad und der Dateiname diesem Muster: gs://mybucket/myproject_id/schema/DO_NOT_REMOVE_td2bq_table_schemas_<string>.json.
      • Ändern Sie die Schemadatei, um Partitionierung, Clustering, Primärschlüssel und die Änderungsverfolgungsspalten zu ändern und prüfen Sie, ob Sie dieses Schema für die Übertragungskonfiguration verwenden möchten. Tipps finden Sie im Abschnitt zur optionalen Schemadatei.
    • Geben Sie den Namen des Ziel-Datasets in BigQuery ein.
    • Geben Sie den Namen des Cloud Storage-Buckets ein, in dem Migrationsdaten vor dem Laden in BigQuery bereitgestellt werden.
    • Geben Sie einen Namen für die Übertragungskonfiguration ein.
  4. Nach der Eingabe aller angeforderten Parameter erstellt der Migrations-Agent eine Konfigurationsdatei und fügt sie in den lokalen Pfad ein, der in den Parametern angegeben ist. Im nächsten Abschnitt erfahren Sie mehr über die Konfigurationsdatei.

Konfigurationsdatei für den Migrations-Agent

Die im Initialisierungsschritt erstellte Konfigurationsdatei sieht in etwa so aus:


   {
    "agent-id": "0eebc1ad-621d-4386-87f1-8eca96991f63",
    "transfer-configuration": {
      "project-id": "123456789876",
      "location": "us",
      "id": "5d533a90-0000-2e89-89a0-94eb2c059a76"
    },
    "source-type": "teradata",
    "console-log": false,
    "silent": false,
    "teradata-config": {
      "connection": {
       "host": "localhost"
      },
      "local-processing-space": "extracted",
      "database-credentials-file-path": "",
      "max-local-storage": "200GB",
      "use-tpt": false,
      "max-sessions": 0,
      "max-parallel-upload": 1,
      "max-unload-file-size": "2GB"
     }
   }
   

Alle Optionen für die Konfigurationsdatei des Migrations-Agent

  • transfer-configuration: Informationen zu dieser Übertragungskonfiguration im BigQuery Data Transfer Service.
  • teradata-config: Informationen speziell für diese Teradata-Extraktion:

    • connection: Informationen zu Hostnamen und Port
    • local-processing-space: Der Extraktionsordner, in den der Agent Tabellendaten extrahiert, bevor er sie in den Cloud-Speicher hochlädt.
    • database-credentials-file-path: (Optional) Der Pfad zu einer Datei, die Anmeldedaten für die automatische Verbindung zur Teradata-Datenbank enthält. Die Datei sollte zwei Zeilen enthalten, zum Beispiel:
      username=abc
      password=123
      
      Achten Sie bei der Verwendung einer Datei mit Anmeldedaten darauf, den Zugriff auf den Ordner zu kontrollieren, in dem Sie die Datei im lokalen Dateisystem speichern, da diese nicht verschlüsselt wird. Wenn kein Pfad angegeben wird, werden Sie beim Starten eines Agents zur Eingabe eines Nutzernamens und eines Kennworts aufgefordert.
    • max-local-storage: Die maximale Menge lokalen Speichers, die für die Extraktion im angegebenen Staging-Verzeichnis verwendet werden soll. Der Standardwert ist 200GB. Das unterstützte Format ist: numberKB|MB|GB|TB.

      In allen Extraktionsmodi werden Dateien nach dem Hochladen in Cloud Storage aus dem lokalen Staging-Verzeichnis gelöscht.

      Der tatsächlich benötigte Staging-Speicherplatz hängt von der Extraktionsmethode ab:

      • Bei der Standardextraktionsmethode (JDBC-Treiber mit FastExport) werden kleine Datenblöcke geschrieben und kontinuierlich in den angegebenen Cloud Storage-Bucket hochgeladen. Die Extraktion wird angehalten, wenn das angegebene max_local_storage-Limit erreicht ist.
      • Beim Extrahieren mit Teradata Parallel Transporter (TPT) ohne Partitionierungsspalte wird die gesamte Tabelle unabhängig von der Einstellung max_local_storage extrahiert.
      • Bei der Extraktion mit Teradata Parallel Transporter (TPT) mit Partitionierungsspalte extrahiert der Agent Partitionssätze. Die Anforderungen für den Staging-Speicher werden durch das größere Element bestimmt: max_local_storage oder die Größe der größten Partition gemäß der ins CSV-Format extrahierten Tabelle.
    • use-tpt: Weist den Migrations-Agent an, Teradata Parallel Transporter (TPT) als Extraktionsmethode zu verwenden.

      Für jede Tabelle generiert der Migrations-Agent ein TPT-Skript, startet einen tbuild-Prozess und wartet auf den Abschluss. Sobald der tbuild-Prozess abgeschlossen ist, listet der Agent die extrahierten Dateien auf und lädt sie in den Cloud-Speicher hoch. Anschließend wird das TPT-Skript gelöscht.

      So verwenden Sie die TPT-Extraktionsmethode:

      • Das Dienstprogramm tbuild sollte installiert und verfügbar sein, damit der Migrations-Agent den Prozess tbuild verwenden und starten kann.
      • Der lokale Extraktionsordner muss genügend Platz zum Extrahieren der größten Partition der Tabelle im CSV-Format haben. Aufgrund der Formatierung sind CSV-Dateien größer als die ursprünglichen Tabellen in Teradata.
    • max-sessions: Gibt die maximale Anzahl der vom Exportjob (FastExport oder TPT) verwendeten Sitzungen an. Bestimmen Sie 0, so ermittelt die Teradata-Datenbank die maximale Anzahl von Sitzungen für jeden Exportjob.

    • max-parallel-uploads: Bestimmt die Anzahl der parallel in Cloud Storage hochgeladenen Dateien. Abhängig von Ihrer Netzwerkbandbreite und anderen Einstellungen (z. B. DLP-Scannen) kann das Erhöhen dieses Parameters die Leistung verbessern.

    • max-unload-file-size: Legt die maximale extrahierte Dateigröße fest. Dieser Parameter wird für TPT-Extraktionen nicht erzwungen.

Migrations-Agent ausführen

Führen Sie nach dem Initialisieren des Migrations-Agent und dem Erstellen der Konfigurationsdatei die folgenden Schritte aus, um den Agent auszuführen und die Migration zu starten:

  1. Starten Sie den Agent, indem Sie den Klassenpfad zu den JDBC-Treibern und den Pfad zur Konfigurationsdatei verwenden, die im vorherigen Initialisierungsschritt erstellt wurde.

    java -cp \
    OS-specific-separated-paths-to-jars (JDBC and agent) \
    com.google.cloud.bigquery.dms.Agent \
    --configuration-file=path to configuration file
    

    Unix, Linux, Mac OS

    java -cp \
    /usr/local/migration/Teradata/JDBC/tdgssconfig.jar:/usr/local/migration/Teradata/JDBC/terajdbc4.jar:mirroring-agent.jar \
    com.google.cloud.bigquery.dms.Agent \
    --configuration-file=config.json
    

    Windows

    Kopieren Sie alle Dateien in den Ordner C:\migration (oder passen Sie die Pfade im Befehl an) und führen Sie dann Folgendes aus:

    java -cp C:\migration\tdgssconfig.jar;C:\migration\terajdbc4.jar;C:\migration\mirroring-agent.jar com.google.cloud.bigquery.dms.Agent --configuration-file=config.json
    

    Wenn Sie mit der Migration fortfahren möchten, drücken Sie Enter. Der Agent fährt fort, wenn der bei der Initialisierung angegebene Klassenpfad gültig ist.

  2. Wenn Sie dazu aufgefordert werden, geben Sie den Nutzernamen und das Kennwort für die Datenbankverbindung ein. Wenn der Nutzername und das Passwort gültig sind, beginnt die Datenmigration.

    Optional Im Startbefehl für die Migration können Sie auch ein Flag verwenden, das eine Anmeldedatendatei an den Agent übergibt, anstatt jedes Mal den Nutzernamen und das Kennwort einzugeben. Weitere Informationen finden Sie im optionalen Parameter database-credentials-file-path in der Konfigurationsdatei des Agent. Führen Sie bei Verwendung einer Datei mit Anmeldedaten die entsprechenden Schritte aus, um den Zugriff auf den Ordner zu kontrollieren, in dem Sie die Datei im lokalen Dateisystem speichern, da diese nicht verschlüsselt wird.

  3. Lassen Sie diese Sitzung geöffnet, bis die Migration abgeschlossen ist. Wenn Sie eine wiederkehrende Migrationsübertragung erstellt haben, lassen Sie diese Sitzung unbegrenzt geöffnet. Wenn diese Sitzung unterbrochen wird, schlagen aktuelle und zukünftige Übertragungsdurchläufe fehl.

  4. Prüfen Sie regelmäßig, ob der Agent ausgeführt wird. Wenn ein Übertragungsdurchlauf ausgeführt wird und kein Agent innerhalb von 24 Stunden antwortet, schlägt der Übertragungsdurchlauf fehl.

  5. Wenn der Migrations-Agent abstürzt, während die Übertragung ausgeführt wird oder geplant ist, zeigt die Cloud Console den Fehlerstatus an und fordert Sie auf, den Agent neu zu starten. Um den Migrations-Agent wieder zu starten, beginnen Sie am Anfang dieses Abschnitts mit dem Ausführen des Migrations-Agents mit dem Befehl zum Ausführen des Migrations-Agents. Sie müssen den Initialisierungsbefehl nicht wiederholen. Die Übertragung wird ab dem Punkt fortgesetzt, an dem die Tabellen nicht abgeschlossen wurden.

Migrationsfortschritt beobachten

Sie können den Migrationsstatus in der Cloud Console einsehen. Sie können auch Pub/Sub- oder E-Mail-Benachrichtigungen einrichten. Siehe BigQuery Data Transfer Service-Benachrichtigungen.

Der BigQuery Data Transfer Service plant und initiiert eine Übertragung nach einem Zeitplan, der beim Erstellen der Übertragungskonfiguration festgelegt wurde. Es ist wichtig, dass der Migrations-Agent ausgeführt wird, wenn eine Übertragung aktiv ist. Wenn innerhalb von 24 Stunden keine Updates seitens des Agent vorliegen, schlägt eine Übertragung fehl.

Beispiel für den Migrationsstatus in der Cloud Console:

Migrationsstatus

Migrations-Agent aktualisieren

Ist eine neue Version des Migrations-Agents verfügbar, so müssen Sie den Migrations-Agent manuell aktualisieren. Um Benachrichtigungen zum BigQuery Data Transfer Service zu erhalten, abonnieren Sie die Versionshinweise.

Nächste Schritte