Kategorien:

Abfragesyntax

CHANGES

Die CHANGES-Klausel ermöglicht das Abfragen der Änderungsverfolgungsmetadaten für eine Tabelle innerhalb eines bestimmten Zeitintervalls, ohne dass ein Tabellenstream mit einem expliziten Transaktionsoffset erstellt werden muss. Die Änderungsverfolgungsmetadaten zwischen verschiedenen Transaktionsstart- und -endpunkten können von mehreren Abfragen abgerufen werden.

Bemerkung

Entweder muss die Änderungsverfolgung für die Tabelle aktiviert sein, oder es muss ein Stream für die Tabelle erstellt werden. Weitere Details dazu finden Sie unter Nutzungshinweise (unter diesem Thema).

In einer Abfrage wird die CHANGES-Klausel in der FROM-Klausel unmittelbar nach dem Tabellennamen angegeben.

Das optionale Schlüsselwort END gibt den Endzeitstempel für das Änderungsintervall an.

Syntax

SELECT ...
FROM ...
   CHANGES ( INFORMATION => { DEFAULT | APPEND_ONLY } )
   AT( { TIMESTAMP => <timestamp> | OFFSET => <time_difference> | STATEMENT => <id> } ) | BEFORE( STATEMENT => <id> )
   [ END( { TIMESTAMP => <timestamp> | OFFSET => <time_difference> | STATEMENT => <id> } ) ]
[ ... ]
INFORMATION => { DEFAULT | APPEND_ONLY }

Gibt den Typ der Änderungsnachverfolgungsdaten an, die basierend auf den jeweils aufgezeichneten Metadaten zurückgegeben werden sollen:

DEFAULT

Gibt alle DML-Änderungen an der Quelltabelle wie Einfügungen, Aktualisierungen und Löschungen (einschließlich Tabellenkürzungen) zurück. Dieser Typ von Änderungsverfolgungsdaten führt eine Verknüpfung (Join) für eingefügte und gelöschte Zeilen im Änderungsset durch, um das Delta auf Zeilenebene bereitzustellen. Als Gesamteffekt wird beispielsweise eine Zeile, die zwischen zwei Transaktionszeitpunkten in einer Tabelle eingefügt und dann gelöscht wird, im Delta entfernt (d. h. sie wird nicht im Abfrageergebnis zurückgegeben).

APPEND_ONLY

Gibt nur angehängte Zeilen zurück. Daher wird kein Join ausgeführt. Infolgedessen kann das Abfragen von Nur-Anfügen-Änderungen viel leistungsfähiger sein als das Abfragen von Standardänderungen für Extraktions-, Lade-, Transformations- (ELT) und ähnliche Szenarien, die ausschließlich von Zeileneinfügungen abhängen.

TIMESTAMP => Zeitstempel

Gibt ein genaues Datum und eine genaue Zeit für Time Travel an. Beachten Sie, dass der Wert explizit in einen TIMESTAMP umgewandelt werden muss.

OFFSET => Zeitunterschied

Gibt für Time Travel die Differenz in Sekunden von der aktuellen Zeit im Format -N an, wobei N eine Ganzzahl oder ein arithmetischer Ausdruck sein kann (z. B. entspricht -120 120 Sekunden; -30*60 entspricht 1.800 Sekunden oder 30 Minuten).

STATEMENT => ID

Gibt die Abfrage-ID einer Anweisung an, die als Referenzpunkt für Time Travel verwendet werden soll. Dieser Parameter unterstützt alle Anweisungen eines der folgenden Typen:

  • DML (z. B. INSERT, UPDATE, DELETE)

  • TCL (BEGIN, COMMIT-Transaktion)

  • SELECT

Nutzungshinweise

  • Derzeit muss mindestens eine der folgenden Bedingungen erfüllt sein, bevor Änderungsverfolgungsmetadaten für eine Tabelle aufgezeichnet werden:

    • Die Änderungsverfolgung ist für die Tabelle aktiviert (mit ALTER TABLE … CHANGE_TRACKING = TRUE).

    • Für die Tabelle wird ein Stream erstellt (mit CREATE STREAM).

    Beide Optionen fügen der Tabelle ein Paar versteckter Spalten hinzu und beginnen mit dem Speichern von Metadaten zur Änderungsverfolgung. Die Spalten verbrauchen wenig Speicherplatz.

    Für den Zeitraum, bevor eine dieser Bedingungen erfüllt ist, sind keine Änderungsverfolgungsmetadaten für die Tabelle verfügbar.

  • Die Klausel AT | BEFORE ist erforderlich und legt den aktuellen Offset für die Änderungsverfolgungsmetadaten fest.

  • Die optionale END-Klausel legt den Endzeitstempel für das Änderungsintervall fest. Wenn kein END-Wert angegeben ist, wird der aktuelle Zeitstempel als Ende des Änderungsintervalls verwendet.

    Beachten Sie, dass die END-Klausel nur in Kombination mit der CHANGES-Klausel gültig ist, um Änderungsverfolgungsmetadaten abzufragen (d. h. diese Klausel kann nicht mit AT|BEFORE kombiniert werden, wenn Time Travel zum Abfragen historischer Daten für andere Objekte verwendet wird).

  • Der Wert für TIMESTAMP oder OFFSET muss ein konstanter Ausdruck sein.

  • Die kleinste Zeitauflösung für TIMESTAMP sind Millisekunden.

  • Wenn die angeforderten Daten die Aufbewahrungsfrist von Time Travel überschreiten (der Standardwert ist 1 Tag), schlägt die Anweisung fehl.

    Wenn außerdem die angeforderten Daten innerhalb der Aufbewahrungsfrist von Time Travel liegen, aber keine historischen Daten verfügbar sind (z. B. wenn der Aufbewahrungszeitraum verlängert wurde), schlägt die Anweisung fehl.

Beispiele

Im folgenden Beispiel werden die Standard- (Delta) und Nur-Anhängen-Änderungsverfolgungsmetadaten für eine Tabelle abgefragt. Es wird kein END()-Wert angegeben, daher wird der aktuelle Zeitstempel als Endpunkt im Transaktionszeitintervall verwendet:

 CREATE OR REPLACE TABLE t1 (
   id number(8) NOT NULL,
   c1 varchar(255) default NULL
 );

-- Enable change tracking on the table.
 ALTER TABLE t1 SET CHANGE_TRACKING = TRUE;

 -- Initialize a session variable for the current timestamp.
 SET ts1 = (SELECT CURRENT_TIMESTAMP());

 INSERT INTO t1 (id,c1)
 VALUES
 (1,'red'),
 (2,'blue'),
 (3,'green');

 DELETE FROM t1 WHERE id = 1;

 UPDATE t1 SET c1 = 'purple' WHERE id = 2;

 -- Query the change tracking metadata in the table during the interval from $ts1 to the current time.
 -- Return the full delta of the changes.
 SELECT *
 FROM t1
   CHANGES(INFORMATION => DEFAULT)
   AT(TIMESTAMP => $ts1);

 +----+--------+-----------------+-------------------+------------------------------------------+
 | ID | C1     | METADATA$ACTION | METADATA$ISUPDATE | METADATA$ROW_ID                          |
 |----+--------+-----------------+-------------------+------------------------------------------|
 |  2 | purple | INSERT          | False             | 1614e92e93f86af6348f15af01a85c4229b42907 |
 |  3 | green  | INSERT          | False             | 86df000054a4d1dc64d5d74a44c3131c4c046a1f |
 +----+--------+-----------------+-------------------+------------------------------------------+

 -- Query the change tracking metadata in the table during the interval from $ts1 to the current time.
 -- Return the append-only changes.
 SELECT *
 FROM t1
   CHANGES(INFORMATION => APPEND_ONLY)
   AT(TIMESTAMP => $ts1);

 +----+-------+-----------------+-------------------+------------------------------------------+
 | ID | C1    | METADATA$ACTION | METADATA$ISUPDATE | METADATA$ROW_ID                          |
 |----+-------+-----------------+-------------------+------------------------------------------|
 |  1 | red   | INSERT          | False             | 6a964a652fa82974f3f20b4f49685de54eeb4093 |
 |  2 | blue  | INSERT          | False             | 1614e92e93f86af6348f15af01a85c4229b42907 |
 |  3 | green | INSERT          | False             | 86df000054a4d1dc64d5d74a44c3131c4c046a1f |
 +----+-------+-----------------+-------------------+------------------------------------------+

Im folgenden Beispiel werden die Nur-Anhängen-Änderungen einer Tabelle ab einem Transaktionszeitpunkt verwendet, bevor die Zeilen aus der Tabelle gelöscht wurden:

CREATE OR REPLACE TABLE t1 (
  id number(8) NOT NULL,
  c1 varchar(255) default NULL
);

-- Enable change tracking on the table.
ALTER TABLE t1 SET CHANGE_TRACKING = TRUE;

-- Initialize a session variable for the current timestamp.
SET ts1 = (SELECT CURRENT_TIMESTAMP());

INSERT INTO t1 (id,c1)
VALUES
(1,'red'),
(2,'blue'),
(3,'green');

SET ts2 = (SELECT CURRENT_TIMESTAMP());

DELETE FROM t1;

CREATE OR REPLACE TABLE t2 (
  c1 varchar(255) default NULL
  )
AS SELECT C1
  FROM t1
  CHANGES(INFORMATION => APPEND_ONLY)
  AT(TIMESTAMP => $ts1)
  END(TIMESTAMP => $ts2);

SELECT * FROM t2;

+-------+
| C1    |
|-------|
| red   |
| blue  |
| green |
+-------+