Allgemeine Informationen zu Openflow Connector for Oracle¶

1. Eingebettete Lizenz (von Snowflake bereitgestellt)¶

Snowflake stellt Ihnen die Oracle XStream-Lizenz gegen eine Gebühr direkt zur Verfügung. Mit diesem Modell können Sie die XStream-Replikation nutzen, ohne einen direkten Vertrag mit Oracle abzuschließen. Weitere Informationen dazu finden Sie unter Details zur eingebetteten Lizenz und im Addendum zu Openflow Connector für Oracle.

2. Unabhängige Lizenz (Bring Your Own License, BYOL)¶

Sie stellen Ihre eigene Oracle-Lizenz bereit, die Berechtigungen für XStream umfasst (z. B. Oracle GoldenGate-Lizenz). Weitere Informationen dazu finden Sie unter Unabhängige Lizenz (BYOL).

Rechnungsstellung¶

Oracle XStream-Services werden monatlich abgerechnet und aus Ihrem Snowflake-Kapazitätsguthaben entnommen. Die Gebühr setzt sich aus zwei Komponenten zusammen – einer Lizenzgebühr und einer Gebühr für Support und Wartung (S&M). Die Lizenzgebühr wird auf Basis der Anzahl der Prozessorknoten in Ihrer Oracle-Quelldatenbank berechnet, multipliziert mit dem Oracle-Prozessor-Kern-Faktor.

Commitment (Die „Tag 61“-Regel)¶

Die ersten 60 Tage sind für bis zu 16 lizenzierte -Kerne kostenlos. Die Aktivierung des Konnektors nach Ablauf der 60-tägigen Testphase löst jedoch eine nicht kündbare Abrechnungsfrist von 36 Monaten („Erstmalige Laufzeit“) aus.

• Automatische Konvertierung: Die Abrechnung beginnt automatisch an Tag 61. Um Gebühren zu vermeiden, müssen Sie die Testversion unter Admin » Terms » Openflow for Oracle-Dashboard vor Tag 60 stornieren.

• Sperrung: Wenn Ihr Snowflake-Vertrag während dieser Erstlaufzeit beendet wird, wird der gesamte Restsaldo der Erstlaufzeit sofort fällig.

Nachträgliche Verlängerung und Strafen¶

Nach der Erstlaufzeit beträgt die Lizenzgebühr 0 USD, aber die Gebühr für Support und Wartung (S&M) bleibt bestehen.

• Opt-out-Konsequenz: Sie können die S&M-Verlängerung im Dashboard deaktivieren. Wählen Sie dazu Admin » Terms » Openflow for Oracle. Wenn jedoch die S&M-Abdeckung eingestellt wird, werden die Konnektor-Prozessoren gesperrt. Um den Betrieb wieder aufzunehmen, müssen Sie eine NEW eingebettete Lizenz kaufen (wodurch eine Zurücksetzung auf die 36-monatige Vollpreisverpflichtung erfolgt).

Anforderungen¶

Sie sind dafür verantwortlich, die Anzahl der Prozessorkerne und den korrekten Kernfaktor in der Konfiguration des Konnektors genau anzugeben. Diese Informationen müssen auf dem neuesten Stand gehalten werden, wenn sich die Hardware Ihrer Quelldatenbank ändert.

Einschränkungen¶

Diese Option ist nicht verfügbar für:

• Organisationen des öffentlichen Sektors (z. B. Regierungsbehörden und Bildungseinrichtungen).

• Kunden, die Snowflake über den GCP-Marketplace kaufen

• Kunden, die einen Vertrag mit Snowflake über einen Wiederverkäufer abgeschlossen haben (z. B.CDW, Optiv).

Konfiguration¶

So konfigurieren Sie die eingebettete -Lizenz:

• Lesen und akzeptieren Sie die im Addendum zu Openflow Connector für Oracle und in der UI aufgeführten Nutzungsbedingungen.

• Wählen Sie den Typ Embedded License aus.

• Geben Sie die Details zur Anzahl der CPU-Kerne für Ihre Oracle-Quelldatenbank an: Total Cores (die Gesamtzahl der physischen Kerne im Quelldatenbankserver) und Core Factor (der Oracle-Prozessor-Kernfaktor, z. B. 0.5 für Intel-Prozessoren). Den richtigen Wert finden Sie in der Tabelle mit den Kernfaktoren für Oracle-Prozessoren.

Anforderungen¶

Sie allein sind dafür verantwortlich, dass Sie den Konnektor entsprechend den Bedingungen Ihrer bestehenden Oracle-Lizenzvereinbarung verwenden. Snowflake validiert oder prüft Ihre Oracle-Berechtigungen nicht.

Konfiguration¶

Konfigurieren der unabhängigen Lizenz (BYOL):

• Lesen und akzeptieren Sie die im Addendum zu Openflow Connector für Oracle und in der UI aufgeführten Nutzungsbedingungen.

• Wählen Sie den Typ Independent License aus.

Fahren Sie bei der Konfiguration des Konnektors fort, ohne eine Kernanzahl oder abrechnungsrelevante Informationen einzugeben.

Replizieren von Tabellen¶

Die Tabellen werden in den folgenden Schritten repliziert:

1. Schema-Introspektion: Der Konnektor erkennt die Spalten in der Quelltabelle, einschließlich der Spaltennamen und -typen, und validiert sie dann anhand der `Einschränkungen`_ von Snowflake und des Konnektors. Wenn die Validierung fehlschlägt, schlägt diese Phase fehl, und der Zyklus ist abgeschlossen. Nach erfolgreichem Abschluss dieser Phase erstellt der Konnektor in Snowflake eine leere Zieltabelle.

2. Laden des Snapshots: Der Konnektor kopiert alle in der Quelltabelle verfügbaren Daten in die Zieltabelle. Wenn dieser Schritt fehlschlägt, werden keine weiteren Daten repliziert. Nach erfolgreichem Abschluss sind die Daten aus der Quelltabelle in der Zieltabelle verfügbar.

3. Inkrementelles Laden: Der Konnektor verfolgt Änderungen in der Quelltabelle und wendet diese Änderungen in der Zieltabelle an. Dies geschieht so lange, bis die Tabelle aus der Replikation entfernt wird. Bei einem Fehler in dieser Phase wird die Replikation der Quelltabelle dauerhaft gestoppt, bis das Problem behoben ist.

Status der Tabellenreplikation¶

Zwischenzeitliche Fehler, wie z. B. Verbindungsfehler, verhindern nicht, dass Tabellen repliziert werden. Permanente Fehler, z. B. nicht unterstützte Datentypen, verhindern jedoch die Replikation von Tabellen.

Um Replikationsprobleme zu beheben oder sicherzustellen, dass eine Tabelle erfolgreich aus dem Replikationsablauf entfernt wurde, überprüfen Sie den Table State Store:

1. Klicken Sie in der Openflow-Laufzeitoberfläche mit der rechten Maustaste auf eine Prozessorgruppe und wählen Sie Controller Services. Es wird eine Tabelle mit den Controllerndiensten angezeigt.

2. Suchen Sie die Zeile mit der Bezeichnung Table State Store, klicken Sie rechts neben der Zeile auf die Schaltfläche More und wählen Sie View State.

Eine Liste der Tabellen und ihrer aktuellen Statusangaben wird angezeigt. Geben Sie einen Namen in das Suchfeld ein, um die Liste nach Tabellennamen zu filtern. Die möglichen Statusangaben sind:

• NEW: Die Replikation der Tabelle ist geplant, aber die Replikation wurde noch nicht gestartet.

• SNAPSHOT_REPLICATION: Der Konnektor kopiert vorhandene Daten. Dieser Status wird so lange angezeigt, bis alle Datensätze in der Zieltabelle gespeichert sind.

• INCREMENTAL_REPLICATION: Der Konnektor repliziert aktiv Änderungen. Dieser Status wird nach dem Ende der Snapshot-Replikation angezeigt und so lange, bis eine Tabelle entweder aus der Replikation entfernt wird oder die Replikation fehlschlägt.

• FAILED: Die Replikation wurde aufgrund eines Fehlers dauerhaft gestoppt.

Replication state for table <database_name>.<schema_name>.<table_name> changed from <old_state> to <new_state>

Wenn ein permanenter Fehler die Replikation der Tabelle verhindert, entfernen Sie die Tabelle aus der Replikation. Nachdem Sie das Problem behoben haben, das den Fehler verursacht hat, können Sie die Tabelle wieder zur Replikation hinzufügen. Weitere Informationen dazu finden Sie unter Replikation der Tabellen neu starten.

Datenaufbewahrung¶

Metadatenspalten der Zieltabelle¶

Jede Zieltabelle enthält die folgenden Metadatenspalten, in denen Replikationsinformationen verfolgt werden:

Vorläufig gelöschte Zeilen¶

Wenn eine Zeile aus der Quelltabelle gelöscht wird, entfernt der Konnektor sie nicht physisch aus der Zieltabelle. Stattdessen wird die Zeile durch Festlegen der Metadatenspalte _SNOWFLAKE_DELETED auf true als gelöscht markiert.

Dieser Ansatz ermöglicht Folgendes:

• Aufbewahrung historischer Daten für Auditing- oder Compliance-Zwecke.

• Abfragen gelöschter Datensätze bei Bedarf.

• Anhand Ihrer Anforderungen entscheiden, wann und wie Daten dauerhaft entfernt werden sollen.

Um nur aktive (nicht gelöschte) Zeilen abzufragen, filtern Sie die Spalte _SNOWFLAKE_DELETED:

SELECT * FROM my_table WHERE _SNOWFLAKE_DELETED = FALSE;

So fragen Sie gelöschte Zeilen ab:

SELECT * FROM my_table WHERE _SNOWFLAKE_DELETED = TRUE;

Gelöschte Spalten¶

Wenn eine Spalte aus der Quelltabelle gelöscht wird, löscht der Konnektor die entsprechende Spalte nicht aus der Zieltabelle. Stattdessen wird die Spalte durch Anhängen des Suffix``__SNOWFLAKE_DELETED`` umbenannt, um historische Werte zu erhalten.

Wenn beispielsweise eine Spalte mit dem Namen``EMAIL`` aus der Quelltabelle gelöscht wird, wird sie in EMAIL__SNOWFLAKE_DELETED in der Zieltabelle umbenannt. Zeilen, die vor dem Löschen der Spalte vorhanden waren, behalten ihre ursprünglichen Werte, während Zeilen, die nach dem Löschen hinzugefügt wurden, den Wert NULL in dieser Spalte haben.

Sie können weiterhin historische Werte aus der umbenannten Spalte abfragen:

SELECT EMAIL__SNOWFLAKE_DELETED FROM my_table;

Umbenannte Spalten¶

Aufgrund von Einschränkungen desCDC (Change Data Capture)-Mechanismus kann der Konnektor nicht zwischen einer Spalte unterscheiden, die umbenannt wurde, und einer Spalte, die gelöscht wurde, gefolgt von einer neu hinzugefügten Spalte. Wenn Sie eine Spalte in der Quelltabelle umbenennen, behandelt der Konnektor dies daher als zwei separate Vorgänge: Löschen der ursprünglichen Spalte und Hinzufügen einer neuen Spalte mit dem neuen Namen.

Wenn Sie z. B. in der Quelltabelle eine Spalte von A in B umbenennen, enthält die Zieltabelle Folgendes:

• A__SNOWFLAKE_DELETED: Enthält Werte, wie sie vor dem Umbenennen vorhanden waren. Zeilen, die nach dem Umbenennen hinzugefügt werden, haben in dieser Spalte den Wert NULL.

• B: Enthält Werte, wie sie nach dem Umbenennen vorhanden sind. Zeilen, die vor dem Umbenennen vorhanden waren, haben in dieser Spalte den Wert NULL.

SELECT
    COALESCE(B, A__SNOWFLAKE_DELETED) AS A_RENAMED_TO_B
FROM my_table;

SELECT
    CASE
        WHEN B IS NOT NULL THEN B
        ELSE A__SNOWFLAKE_DELETED
    END AS A_RENAMED_TO_B
FROM my_table;

CREATE VIEW my_table_unified AS
SELECT
    *,
    COALESCE(B, A__SNOWFLAKE_DELETED) AS A_RENAMED_TO_B
FROM my_table;

Journaltabellen¶

Bei der inkrementellen Replikation werden Änderungen aus der Quelldatenbank zunächst in Journaltabellen geschrieben, bevor sie in den Zieltabellen zusammengeführt werden. Der Konnektor entfernt nicht automatisch Daten aus Journaltabellen, da diese Daten für Auditing-, Debugging- oder Wiederverarbeitungszwecke nützlich sein können.

Journaltabellen werden im gleichen Schema wie ihre entsprechenden Zieltabellen erstellt und folgen dieser Namenskonvention:

<TABLE_NAME>_JOURNAL_<timestamp>_<number>

Wobei:

• <TABLE_NAME> ist der Name der Zieldatenbank.

• <timestamp> ist der Zeitstempel der Erstellung im Unix-Epochenformat (Sekunden seit dem 1. Januar 1970), der die Eindeutigkeit gewährleistet.

• <number> beginnt bei 1 und wird immer dann erhöht, wenn sich das Schema der Zieltabelle ändert, entweder aufgrund von Schemaänderungen in der Quelltabelle oder aufgrund von Änderungen an den Spaltenfiltern.

Wenn Ihre Zieltabelle beispielsweise SALES.ORDERS ist, könnte die Journaltabelle SALES.ORDERS_JOURNAL_1705320000_1 heißen.