Conference orarep::nomahs::dec_data_distributor

    
    Scenrio:   Five transfers are executed on a daliy bases.
    
    		From my understandning this would leave one days worth
    		of transfer data in RDB$CHANGES:
    
    			Day n
    			RDB$transfers table
    
    			TRansfer name		vintage_tser
    			t_1			100
    			t_2			101
    			t_3			102
    			t_4			103
    			t_5			104
    
    			Day n + 1
    			TRansfer name		vintage_tser
    			t_1			105
    			t_2			106
    			t_3			107
    			t_4			108
    			t_5			109
    
    		At this point in time all rows up to tser 105 would be
    		gone in RDB$CHANGES (day n's data), but data from day n+1
    		would still be in the table, although it was transfered
    		successfully to the target.
    
    		Is this correctly understood ? If so, what is the reason
    		for this implementation ? (A novice view is that one 
    		a transfer is complete, all the corresponding rows in
    		RDB$changes should be removed).
    
    		Am I missing something ?
    
    	Stefan

Stefan,

>    Scenrio:   Five transfers are executed on a daliy bases.
>    
>    		From my understandning this would leave one days worth
>    		of transfer data in RDB$CHANGES:
>    
>    			Day n
>    			RDB$transfers table
>    
>    			TRansfer name		vintage_tser
>    			t_1			100
>    			t_2			101
>    			t_3			102
>    			t_4			103
>    			t_5			104
>    
>    			Day n + 1
>    			TRansfer name		vintage_tser
>    			t_1			105
>    			t_2			106
>    			t_3			107
>    			t_4			108
>    			t_5			109
>    
>    		At this point in time all rows up to tser 105 would be
>    		gone in RDB$CHANGES (day n's data), but data from day n+1
>    		would still be in the table, although it was transfered
>    		successfully to the target.

From your earlier replies, I assume that transfer t_5 is the last to run and
is the one for which purging of RDB$CHANGES rows is enabled.  Assuming that
all transfers execute without error, once transfer t_5 completes on day n + 1,
all rows in RDB$CHANGES associated with vintage_tser 108 or lower would be
erased.  We always leave one transaction in RDB$CHANGES (even though that
transaction had been replicated to the target databases) so that we can perform
a sanity test the next time a transfer is run.

>    		Is this correctly understood ? If so, what is the reason
>    		for this implementation ? (A novice view is that one 
>    		a transfer is complete, all the corresponding rows in
>    		RDB$changes should be removed).

No, this is not correct.  If I understand you correctly, you're saying that
after transfer t_5 completes on day n + 1 and having purged RDB$CHANGES, that
table still has rows in it for vintage_tser 105 through 109.  That should not
be.  If your customer is seeing this behavior, I need to see some evidence to
corroborate the story.  I need to see:

1) Output from a SELECT in RDB$CHANGES that lists the TSER column

2) The copy process log for the last transfer of the day that is run

3) Output from a SELECT * FROM RDB$TRANSFERS.

Claude

    
    (from 166.1)
    !			RDB$TRANSFERS table
!
!    		RDB$TRANSFER_NAME	RDB$VINTAGE_TSER
!
!    		       A		       50
!    		       B		      100
!
!When a copy process decides to delete (purge) rows from the RDB$CHANGES table,
!it first finds the lowest TSER value of all the rows in RDB$TRANSFERS.  Then,
!all rows with a TSER value below that number are deleted.  In this case, any
!transaction with a TSER value of 49 or lower will be erased.  A warning in case
!you ever think to do the deletion yourself.  Transactions in the RDB$CHANGES
!table can take up multiple rows.  Only the last row for a given transaction
!will have the TSER number in it.  That's because the TSER value is not assigned
!until the transaction commits.
    
    	Claude,
    	this is Your explaination of how it works (from .1). I read this as
    		1. Find the lowest possible TSER in TRANSFERS.
    		2. Delete all rows from rdb$chnages belonging to transfers
    	           having a tser which is =< Min(TSER) from TRANSFERS.
    
    	Is this correct ?
    
    	
    	Stefan
    
    	(I'll get the necessary data from the cusomter, but I'll do a
    	 select distinct rdb$transaction_tser from rdb$changes since it
    	 contains 26 000 records.)

    
    Stefan,
    
    You are almost right.
    
    It is not =<.  We only erase rows associated with TSERs < the minimum
    value, even though the transaction associated with the = case has
    already been transferred to all target databases that need to see it.
    In the example from 166.1, then, tser=50 is the minimum number, and we
    erase all transactions in RDB$CHANGES whose TSER is 49 or less.
    
    When looking at RDB$CHANGES, watch out for rows which do not have a
    TSER assigned to them.  These are rows in a multi-row transaction.
    Only the last row for a given transaction actually has a TSER assigned
    to it.  That's because this is done when the transaction commits.
    
    Claude

    
    Jean-Claude,
    how would this translate to my scenario in .11 ? On day n+1, having
    executed all transfers with no purge on t_1 to t_4, but with
    the purge enabled on t_5 ? In this case would TSERs lower than
    105 be purged ?
    
    Stefan

    
    Stefan
    
    At the end of day n, after execution of transfer t_5, which is the only
    transfer enabled to perform purging, transactions associated with TSER's
    lower than 104, not 105, would be purged.
    
    To keep the discussion simple, let us assume that each source
    transaction results in only a single row being written to the
    RDB$CHANGES table.  Given the table you provided, only 5 transactions
    per day get written to RDB$CHANGES, a very small number.  I doubt that
    your table is illustrative of a real example, but that was no doubt not
    your intent.  If each transfer is supposed to send out the same
    transactions to the different target databases, then at the end of each
    day, you would expect to see the same TSER value in the RDB$TRANSFERS
    table for each transaction.  It would not be normal to see numbers
    assigned consecutively, as you have shown, unless only 5 trasnactions
    are entered into the RDB$CHANGES table, each one meant for a different
    transfer.
    
    I hope I am not making things more confusing.
    
    Claude