SCN Recovery & LogMiner Gap Diagnosis
Interactive troubleshooting tool for "SCN Not Found" errors. Simulate log retention failures, diagnose gaps, and follow step-by-step recovery playbooks for Debezium on Kubernetes.
What is Debezium?
Debezium is an open-source CDC tool built by Red Hat. Instead of querying your database to find what changed, it reads the transaction log directly - which means it sees every insert, update, and delete in the exact order they happened, with the full before and after state of each row. It does this without touching your application schema or adding load to your queries.
It ships with a connector for each supported database. The Oracle connector reads redo logs via LogMiner or XStream, the PostgreSQL connector uses logical replication slots, and MySQL uses the binary log. There are no triggers, no polling queries, and nothing changes in your source database.
You can deploy Debezium in three ways. Debezium Kafka Connect runs inside a Kafka Connect cluster and publishes events to Kafka topics - the right choice if Kafka is already in your stack. Debezium Server is a standalone process that delivers events directly to HTTP, AWS Kinesis, Google Pub/Sub, or Redis without needing Kafka at all. Debezium Engine is a Java library you embed directly in your own application.
Debezium with Oracle LogMiner
LogMiner is built into Oracle Database - no extra license, no additional software. It's the most common starting point for Oracle CDC and works well for most production workloads.
Performance Tuning Studio
Generate optimised application.properties configurations for High Throughput, Low Latency, Low CPU, and Low Memory profiles. Visualise trade-offs with radar charts.
Oracle Archive Log Management
Interactive guide to configuring archive log retention for Debezium LogMiner. Covers the RMAN conflict, dual-destination strategy, and SCN-aware cleanup to prevent missing log errors.
LogMiner JDBC Config Generator
Generate production-ready Debezium Server config with JDBC-backed offset and schema history storage. Covers profiles, snapshot modes, CDB/PDB topology, and validation steps.
Oracle DDL Mining Strategy
Compare redo_log_catalog and online_catalog strategies for managing DDL changes with Debezium. Step-by-step playbooks for safe schema evolution with no data loss.
Oracle EBR CDC Analysis
Feasibility analysis for Debezium LogMiner CDC in Edition-Based Redefinition environments. Covers redo_log_catalog strategy, concurrent edition constraints, and DDL parsing.
LogMiner Performance Tuning
Interactive risk analyzer and tuning guide for Debezium Oracle LogMiner throughput: redo log sizing, logminer_unbuffered mode, and Kafka producer settings.
Oracle Redo Log Sizing
Architecture flow, performance simulation, and SCN recovery guide for sizing Oracle redo logs to support stable Debezium LogMiner CDC pipelines.
Debezium with Oracle XStream
XStream is faster and lower-latency than LogMiner, but you need an Oracle GoldenGate license to use it. Worth considering if you need sub-second latency or are dealing with very high transaction volumes.
XStream Configuration Explorer
Dashboard-style explorer for Debezium Server with Oracle XStream. Covers connection pooling, JDBC offset/schema history storage, RegexRouter SMT simulation, and HTTP sink configuration.
GoldenGate vs. Debezium: Oracle CDC Comparison
Architecture, cost, and consistency trade-offs for Oracle CDC. Covers XStream licensing, multi-tenant CDB/PDB configuration, latency, and an interactive recommendation engine.
GoldenGate Licensing Calculator
Model Oracle GoldenGate license costs by processor count and target type, explore K8s node scoping compliance rules, and build a per-tenant pricing strategy.
XStream vs LogMiner Migration Guide - coming soon
Decision framework and step-by-step migration path for switching between Oracle XStream and LogMiner modes in Debezium.
Concurrency & Scaling
Running multiple Debezium Oracle connectors at the same time is not straightforward. The rules are different for LogMiner vs XStream, and change again when you're reading from multiple schemas. Get this wrong and you'll end up with duplicate events or conflicts.
Concurrency & Scaling Analysis
Interactive comparison of XStream vs LogMiner for multiple concurrent readers. Covers same-schema conflict constraints, per-schema scale-out patterns, and Kubernetes HA strategies.
Kubernetes Deployment Best Practices - coming soon
StatefulSet vs Deployment trade-offs, resource sizing, liveness probes, and rolling update strategies for Debezium Server on Kubernetes.
Frequently Asked Questions
Debezium supports Oracle, PostgreSQL, MySQL, SQL Server, MongoDB, Db2, Cassandra, Vitess, and Spanner. Each database gets its own connector that reads the native transaction log. For Oracle specifically, you can use LogMiner (built-in, no extra license) or XStream (requires a GoldenGate license).
Debezium Server is a standalone process that runs any Debezium connector without Kafka. It delivers change events directly to HTTP endpoints, AWS Kinesis, Google Pub/Sub, Redis Streams, or Pulsar. If you don't have Kafka in your stack, this is usually the simplest way to get started.
Debezium uses the LogMiner SQL API to read through Oracle's redo and archive logs. For each change in a captured table, it produces an event with the operation type, SCN, timestamp, and the before and after values of every column. No GoldenGate license needed - LogMiner ships with every Oracle Database edition.
No. If you use Kafka Connect mode, then yes - it publishes events to Kafka topics. But Debezium Server runs standalone without any Kafka dependency and delivers events to HTTP, Kinesis, Pub/Sub, or Redis. And if you want to process changes inside your own application, Debezium Engine is a Java library you can embed directly.
Yes, and it's used widely in production. The main things to get right: keep enough archive log retention so the connector doesn't fall behind and lose its SCN position, decide between LogMiner and XStream based on your latency and licensing situation, tune batch sizes for your throughput, and make sure your Kubernetes setup can restart the connector without losing offset state.