Hi @faruko  !

My idea is to treat the initial load as a controlled batch backfill then start the CDC pipeline afterwards from a clear cutoff point.

You define a fixed cutoff timestamp or Oracle SCN for the initial snapshot and later load history in small time windows for example month by month or week by week or day by day depending on volume:

WHERE event_timestamp >= :start_ts
  AND event_timestamp <  :end_ts

and since you have many tag_ids you split each time window further by tag buckets for example:

WHERE event_timestamp >= :start_ts
  AND event_timestamp <  :end_ts
  AND ORA_HASH(tag_id, 15) = :bucket

This gives you controlled parallelism without needing a unique numeric ID.

Then store the progress in a control table for example table_name, start_ts, end_ts, bucket, status, row_count, load_time this way the load restartable if one chunk fails.

And later you write into a bronze delta table with idempotent key such as (tag_id, event_timestamp) or (tag_id, event_timestamp, source_id)

Once you finishthe historical backfill up to the cutoff timestamp or SCN,you can start the incremental ingestion from that same point.

I would not try to use the same streaming checkpoint for monthly historical loading and then later change it to continuous ingestion. I would keep the initial backfill and the ongoing ingestion as 2 separate pipelines.

You can find in the doc  the idea of doing initial hydration first then switching to triggered or continuous CDC processing afterwards. 

https://docs.azure.cn/en-us/databricks/ldp/what-is-change-data-capture