DBAtlas · Atlas de operações de banco de dados

Rastreamento de alterações (CDC / change tracking)

Oracle

-- Read changes from redo logs with LogMiner:
-- 1) Add the archived/redo log file to analyze:
EXECUTE DBMS_LOGMNR.ADD_LOGFILE(
  LOGFILENAME => '/u01/arch/1_1234_1122334455.arc',
  OPTIONS => DBMS_LOGMNR.NEW);
-- 2) Start the session:
EXECUTE DBMS_LOGMNR.START_LOGMNR(
  OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG);
SELECT sql_redo, sql_undo FROM V$LOGMNR_CONTENTS
WHERE seg_name = 'ORDERS';
-- 3) When finished: EXECUTE DBMS_LOGMNR.END_LOGMNR;
-- For enterprise CDC/replication, Oracle GoldenGate is used.

O Oracle faz rastreamento de alterações baseado no redo log. O LogMiner traduz redo/archived logs em SQL para inspecionar DML passado; os arquivos de log a analisar são adicionados com DBMS_LOGMNR.ADD_LOGFILE. Para resultados significativos, pelo menos o supplemental logging mínimo deve estar habilitado (ALTER DATABASE ADD SUPPLEMENTAL LOG DATA). Para CDC contínuo de baixa latência e replicação heterogênea, o Oracle GoldenGate (um produto separado) é o padrão; os antigos recursos Streams/Change Data Capture estão obsoletos.

PostgreSQL

-- Create a logical replication (logical decoding) slot:
SELECT * FROM pg_create_logical_replication_slot(
  'cdc_slot', 'wal2json');
-- Consume changes as JSON:
SELECT data FROM pg_logical_slot_get_changes('cdc_slot', NULL, NULL);

O logical decoding do PostgreSQL transforma os registros do WAL em um fluxo legível de alterações por meio de um output plugin (wal2json, pgoutput, test_decoding); o replication slot garante que as alterações não sejam perdidas. wal_level deve ser logical. O Debezium usa esse mecanismo para fornecer CDC corporativo.

MySQL

-- The row-based binlog is the CDC source (binlog_format=ROW):
SHOW BINARY LOGS;
SHOW BINLOG EVENTS IN 'binlog.000042';
-- Usually Debezium/Maxwell reads the binlog and turns it into a stream.

No MySQL, a fonte de CDC é o binary log. Com binlog_format=ROW, toda alteração de linha é registrada. Ferramentas como Debezium ou Maxwell leem o binlog como uma réplica e produzem um fluxo de eventos para o Kafka. Habilitar o GTID facilita o rastreamento confiável de posição.

SQL Server

-- Enable Change Data Capture on the database and the table:
EXEC sys.sp_cdc_enable_db;
EXEC sys.sp_cdc_enable_table
  @source_schema = N'dbo', @source_name = N'orders',
  @role_name = NULL;
-- For lightweight tracking: ALTER DATABASE ... SET CHANGE_TRACKING = ON;

O SQL Server oferece dois mecanismos: o Change Data Capture (CDC) grava todo o DML (com valores antigos/novos) do transaction log em change tables e requer o SQL Server Agent. O Change Tracking apenas rastreia de forma leve quais linhas mudaram (net changes) e não mantém histórico completo dos dados.

MongoDB

// Watch changes in real time with Change Streams:
const stream = db.orders.watch([
  { $match: { operationType: { $in: ["insert", "update"] } } }
]);
while (stream.hasNext()) { printjson(stream.next()); }

Os Change Streams do MongoDB, construídos sobre o oplog, entregam eventos de insert, update e delete em nível de coleção/banco/cluster como um fluxo em tempo real. Requer um replica set ou um cluster com sharding. Com um resumeToken, um fluxo pode ser retomado de onde parou após uma interrupção; é a base das integrações de CDC.

Redis

# Listen for key changes with keyspace notifications:
CONFIG SET notify-keyspace-events KEA
# Subscribe to changed keys via Pub/Sub:
PSUBSCRIBE __keyevent@0__:set
PSUBSCRIBE __keyevent@0__:expired

As keyspace notifications do Redis publicam eventos sobre chaves (SET, DEL, EXPIRE etc.) por canais Pub/Sub; são habilitadas com a configuração notify-keyspace-events (K=keyspace, E=keyevent, A=todos os eventos). Para um fluxo de alterações confiável e durável, prefere-se o Redis Streams (XADD/XREAD).

Elasticsearch

-- Not applicable: there is no built-in CDC/change stream.
# Closest equivalent: incremental query on a timestamp field:
GET orders/_search
{ "query": { "range": { "updated_ts": { "gt": "2026-07-05T00:00:00" } } },
  "sort": [ { "updated_ts": "asc" } ] }

O Elasticsearch não oferece um fluxo de change data capture (CDC); não publica nativamente quando um documento mudou. A abordagem comum é adicionar um campo updated_ts a cada documento e executar consultas incrementais por timestamp (range + sort). Geralmente, o CDC do banco de origem é que alimenta o Elasticsearch.

Abrir no DBAtlas →