CDC Subscription question concerning transactional consistency

Question

Hi
Hopefully a quick question: can anyone confirm whether or not it is the subscription that controls transactional consistency when accessing change records in the change views?
For example, if you have 20 source tables that you are capturing changes for and create one change source, one change set containing 20 change tables and one subscription for which you have 20 change views then because it is the subscription that you specify when performing the extend and purge operationa and hence it is the one subscription than ensures that when an extend is issued then all change records across the 20 change views will be transactionally consistent.
I have had an alternative design proposed to me that is to use 20 separate subscriptions - one for each source table and change table. My concern is that this will not ensure transactional consistency across the 20 tables and that any ETL design (for example 20 separate threads running in parallel and each doing an extend, process, purge sequence) cannot ensure that the change records in the change views correspond to the same transaction across the tables in the source database.
I hope that this is clear - any views and opinions on this will be very gratefully received.
Many thanks
Pete

Answer 1

>
Apologies if this appears to be belabouring the point - but it is an important bit of understanding for me.
>
The issue is not that you are belabouring the point but that you are not reading the doc quote I cited or the last paragraph on my last reply.
Creating a consistent set of data and USING (querying) a consistent subset of that data are two different things. The publisher is responsible for creating a change set that includes the data you will want and the change set will make sure that a consistent set of data is available.
Whether a subscriber makes proper use of that change set data or not is another thing altogether.
If you create 20 subscriptions then those are totally independent of one another just lilke 20 people subscribing to the Wall Street Journal; those subscribers and subscriptions have NOTHING to do with one another. If you want to try to synchronize the 20 yourself have at it but as far as Oracle is concerned each subscriber is unique and independent.
If you want to subscribe to, and use, a consistent subset of the change set then, as the doc quote said, you have to JOIN the tables together.
Read the documentation - you can't understand it if you don't read the doc and go through the examples in it.
Step 4 Subscribe to a source table and the columns in the source table shows you exactly how you have to do the join.
The second step of that example says this
>
Therefore, if the subscriber wants to subscribe to columns in both publications, using EMPLOYEE_ID to join across the subscriber views, then the subscriber must use two calls, each specifying a different publication ID:
>
'. . . join across the subscriber views . . .'
Don't be afraid of breaking Oracle by trying things!
The SCOTT EMP and DEPT tables might currently have a consistent set of data in the two tables. But if I query EMP from one session (subscription) and query DEPT form another session (subscription) the results I get might not be consistent between them because I used to independent operations to get the data and the data might have changed in between the two steps.
However if I query DEPT and EMP using a JOIN then Oracle guarantees that the data from both tables will reflect the same instant in time.
Not a perfect analogy but close to the subscription use. If you want to subscribe to data from mutiple tables/views in the change set AND get a consistent set of data you need to join the tables/views together. The mechanism for doing this is not the same as SQL but is shown in the above example in the doc.