- Categorias:
CHANGES¶
A cláusula CHANGES permite consultar os metadados de rastreamento de alterações para uma tabela ou exibição dentro de um intervalo especificado sem ter que criar um fluxo com um offset transacional explícito. Consultas múltiplas podem recuperar os metadados de rastreamento de alterações entre diferentes pontos de extremidade iniciais e finais transacionais.
Nota
O rastreamento de alterações deve ser habilitado na tabela de origem ou na exibição da origem e suas tabelas subjacentes. Para obter mais detalhes, consulte as Notas de uso (neste tópico).
Em uma consulta, a cláusula CHANGES é especificada na cláusula FROM.
A palavra-chave opcional END especifica o carimbo de data/hora final para o intervalo de alteração.
Sintaxe¶
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> } ) ]
[ ... ]
INFORMATION => { DEFAULT | APPEND_ONLY }
Especifica o tipo de dados de rastreamento de alterações a serem retornados com base nos metadados registrados em cada um deles:
DEFAULT
Retorna todas as alterações da DML no objeto de origem, incluindo inserções, atualizações e exclusões (incluindo truncagem da tabela). Este tipo de rastreamento de alterações compara as linhas inseridas e excluídas no conjunto de mudanças para fornecer o delta de nível de linha. Como efeito líquido, por exemplo, uma linha que é inserida e depois excluída entre dois pontos de tempo transacionais em uma tabela é removida no delta (ou seja, não é retornada nos resultados da consulta).
APPEND_ONLY
Retorna somente as linhas anexadas; portanto, não é realizada nenhuma junção. Como resultado, consultar as alterações apenas em anexo pode ser muito mais eficiente do que consultar as alterações padrão (padrão) para extrair, carregar, transformar (ELT) e cenários semelhantes que dependem exclusivamente de inserções de linhas.
TIMESTAMP => timestamp
Especifica uma data e hora exatas a serem usadas para o Time Travel. Note que o valor deve ser convertido explicitamente em um TIMESTAMP.
OFFSET => time_difference
Especifica a diferença em segundos do tempo atual a ser usado para o Time Travel, na forma
-N
ondeN
pode ser uma expressão inteira ou aritmética (por exemplo,-120
é 120 segundos,-30*60
é 1800 segundos ou 30 minutos).STATEMENT => id
Especifica a ID de consulta de uma instrução a ser usada como ponto de referência para o Time Travel. Este parâmetro oferece suporte a qualquer instrução de um dos seguintes tipos:
DML (por exemplo, INSERT, UPDATE, DELETE)
TCL (transação BEGIN, COMMIT)
SELECT
STREAM => 'name'
Especifica o identificador (ou seja, nome) de um fluxo existente na tabela ou exibição consultada. O offset atual no fluxo é usado como o ponto
AT
no tempo para retornar os dados de alteração para o objeto de origem.
Notas de uso¶
A cláusula CHANGES não é suportada ao consultar alterações (que são resolvidas usando metadados de rastreamento de alterações) para tabelas de diretórios ou tabelas externas.
Atualmente, pelo menos um dos seguintes itens deve ser verdadeiro antes que os metadados de rastreamento de alterações sejam registrados para uma tabela:
O rastreamento de alterações está habilitado na tabela (usando ALTER TABLE … CHANGE_TRACKING = TRUE).
Um fluxo é criado para a tabela (usando CREATE STREAM).
Ambas as opções adicionam colunas ocultas à tabela que armazenam metadados de rastreamento de alterações. As colunas consomem uma pequena quantidade de armazenamento.
Para consultar os dados de alteração de uma exibição, o rastreamento de modificação deve ser habilitado na exibição de origem e em suas tabelas subjacentes. Para obter instruções, consulte Habilitação do rastreamento de alterações em exibições e tabelas subjacentes.
A cláusula AT | BEFORE é necessária e define o offset atual para os metadados de rastreamento de alterações.
A cláusula opcional END define o carimbo de data/hora final para o intervalo de alteração. Se nenhum valor END for especificado, o carimbo de data/hora atual é usado como o fim do intervalo de alteração.
Observe que a cláusula END é válida somente quando combinada com a cláusula CHANGES para consultar metadados de rastreamento de alterações (ou seja, esta cláusula não pode ser combinada com AT|BEFORE quando se usa o Time Travel para consultar dados históricos de outros objetos).
O valor para TIMESTAMP ou OFFSET deve ser uma expressão constante.
A menor resolução de tempo para TIMESTAMP é de milissegundos.
Se os dados solicitados estiverem além do período de retenção de Time Travel (o padrão é 1 dia), a instrução falha.
Além disso, se os dados solicitados estiverem dentro do período de retenção do Time Travel, mas não houver dados históricos disponíveis (por exemplo, se o período de retenção foi prorrogado), a instrução falha.
Exemplos¶
O exemplo a seguir consulta os metadados padrão (delta) e os metadados de rastreamento de alterações apenas para anexação para uma tabela. Não é fornecido nenhum valor END(), portanto o carimbo de data/hora atual é usado como o ponto de extremidade no intervalo transacional:
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 |
+----+-------+-----------------+-------------------+------------------------------------------+
O exemplo a seguir consome as mudanças apenas para anexação para uma tabela a partir de um ponto transacional antes das linhas serem excluídas da tabela:
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 |
+-------+
O exemplo a seguir é semelhante ao exemplo anterior. Este exemplo utiliza o offset atual para um fluxo na tabela de origem como ponto de partida temporal para preencher a nova tabela com dados de alteração da tabela de origem. Como um fluxo é criado no objeto de origem, você não precisa habilitar explicitamente o rastreamento de alterações no objeto:
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 |
+-------+