Skip to content

Commit cb4761b

Browse files
Merge pull request #1190 from redis/DOC-4852-rdi-heartbeat-mech
DOC-4852 added RDI heartbeat mechanism info
2 parents d0ec1b0 + adbe4ab commit cb4761b

File tree

1 file changed

+57
-0
lines changed

1 file changed

+57
-0
lines changed

content/integrate/redis-data-integration/reference/config-yaml-reference.md

Lines changed: 57 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -114,6 +114,63 @@ See the Debezium documentation for more information about the specific connector
114114
| `lob.enabled` | `string` | Oracle | Enables capturing and serialization of large object (CLOB, NCLOB, and BLOB) column values in change events.<br/>Default: `false` |
115115
| `unavailable.value.placeholder` | Special | Oracle | Specifies the constant that the connector provides to indicate that the original value is unchanged and not provided by the database (this has the type `__debezium_unavailable_value`). |
116116

117+
### Oracle heartbeat mechanism
118+
119+
{{< note >}} This section is only relevant for Oracle installations where many hours
120+
or days may pass between changes to the source database.
121+
{{< /note >}}
122+
123+
Oracle uses *system change numbers* (SCNs) to record the order in which events happen
124+
in a database. Any given event always has a higher SCN than any event that happened
125+
previously, so the SCNs form a logical "timeline". (See
126+
[Transactions](https://docs.oracle.com/cd/E11882_01/server.112/e40540/transact.htm#CNCPT016)
127+
in the Oracle docs for more information.)
128+
129+
For an Oracle source database, the RDI collector records the SCN of the most recent
130+
transaction it has captured. When it checks the source for changes, it
131+
uses this last recorded SCN to find all events that have happened in the meantime
132+
and catch up with processing them. However, Oracle internally discards its SCN
133+
information after a certain number of transactions have occurred. If these
134+
transactions are against tables that RDI is *not* capturing, the last SCN
135+
recorded by RDI might eventually be discarded by Oracle. When this happens,
136+
the collector is unable to use its last SCN to detect new changes and data
137+
may be lost as a result.
138+
139+
If you are using Oracle as a source database and you expect updates to the
140+
data to be very infrequent, you should enable the *heartbeat mechanism* in
141+
the RDI collector. This writes data to a "dummy" table in the source on a
142+
regular basis purely to generate a new SCN. To enable the heartbeat,
143+
first create the dummy table with the following SQL:
144+
145+
```sql
146+
CREATE TABLE rdi_heartbeat (
147+
id NUMBER PRIMARY KEY,
148+
last_heartbeat TIMESTAMP DEFAULT CURRENT_TIMESTAMP
149+
);
150+
```
151+
152+
Then, give WRITE/UPDATE permission to RDI on this table:
153+
154+
```sql
155+
GRANT INSERT, UPDATE ON rdi_heartbeat TO rdi_user;
156+
```
157+
158+
Finally, add the following lines to `config.yaml` under `sources.oracle.advanced`:
159+
160+
```yaml
161+
sources:
162+
oracle:
163+
advanced:
164+
source:
165+
heartbeat.interval.ms: 60000
166+
heartbeat.action.query: "MERGE INTO rdi_heartbeat t USING (SELECT 1 AS id FROM dual) s
167+
ON (t.id = s.id)
168+
WHEN MATCHED THEN UPDATE SET t.last_heartbeat = CURRENT_TIMESTAMP
169+
WHEN NOT MATCHED THEN INSERT (id, last_heartbeat) VALUES (1, CURRENT_TIMESTAMP);"
170+
```
171+
172+
This sets the appropriate heartbeat update to occur once every minute.
173+
117174
### Using custom queries in the initial snapshot {#custom-initial-query}
118175

119176
{{< note >}}This section is relevant only for MySQL, MariaDB, Oracle, PostgreSQL, and SQL Server.

0 commit comments

Comments
 (0)