Kategorien:: Abfragesyntax

CHANGES¶

Die CHANGES-Klausel ermöglicht das Abfragen der Änderungsverfolgungsmetadaten für eine Tabelle oder Ansicht 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

Die Änderungsverfolgung muss für die Quelltabelle oder die Quellansicht und deren zugrunde liegenden Tabellen aktiviert sein. Weitere Details dazu finden Sie unter Nutzungshinweise (unter diesem Thema).

In einer Abfrage wird die CHANGES-Klausel in der FROM-Klausel 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> | STREAM => '<name>' } ) | BEFORE ( STATEMENT => <id> )
   [ END( { TIMESTAMP => <timestamp> | OFFSET => <time_difference> | STATEMENT => <id> } ) ]
[ ... ]

Copy

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 Änderungsverfolgung vergleicht eingefügte und gelöschte Zeilen im Änderungsset, 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 => timestamp

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 => time_difference

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

STREAM => 'name'

Gibt den Bezeichner (d. h. den Namen) eines vorhandenen Streams auf der abgefragten Tabelle oder Ansicht an. Der aktuelle Offset im Stream wird als AT-Zeitpunkt für die Rückgabe von Änderungsdaten für das Quellobjekt verwendet.

Nutzungshinweise¶

Die CHANGES-Klausel wird nicht unterstützt, wenn Änderungen (die mithilfe der Änderungsverfolgungsmetadaten aufgelöst werden) an Verzeichnistabellen oder externen Tabellen abgefragt werden.
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).
Bei beiden Optionen werden der Tabelle verborgene Spalten hinzugefügt, in denen Metadaten zur Änderungsverfolgung gespeichert werden. Die Spalten verbrauchen wenig Speicherplatz.

Um die Änderungsdaten für eine Ansicht abzufragen, muss die Änderungsverfolgung für die Quellansicht und die ihr zugrunde liegenden Tabellen aktiviert sein. Eine Anleitung dazu finden Sie unter Aktivieren der Änderungsverfolgung für Ansichten und zugrunde liegende Tabellen.
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 |
 +----+-------+-----------------+-------------------+------------------------------------------+

Copy

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 'start timestamp' variable for the current timestamp.
SET ts1 = (SELECT CURRENT_TIMESTAMP());

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

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

DELETE FROM t1;

-- Create a table populated by the change data between the start and end timestamps.
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 |
+-------+

Copy

Das folgende Beispiel ähnelt dem vorherigen. In diesem Beispiel wird der aktuelle Offset für einen Stream in der Quelltabelle als zeitlicher Startpunkt für das Auffüllen der neuen Tabelle mit Änderungsdaten aus der Quelltabelle verwendet. Da ein Stream auf dem Quellobjekt erstellt wird, müssen Sie die Änderungsverfolgung auf dem Objekt nicht explizit aktivieren:

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

-- Create a stream on the table.
CREATE OR REPLACE STREAM s1 ON TABLE t1;

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

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

DELETE FROM t1;

-- Create a table populated by the change data between the current
-- s1 offset and the end timestamp.
CREATE OR REPLACE TABLE t2 (
  c1 varchar(255) default NULL
  )
AS SELECT C1
  FROM t1
  CHANGES(INFORMATION => APPEND_ONLY)
  AT(STREAM => 's1')
  END(TIMESTAMP => $ts2);

SELECT * FROM t2;

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

Copy