[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference orarep::nomahs::dec_data_distributor

Title:	The Replication Option for Rdb
Notice:	Product renamed to Replication Option for Rdb
Moderator:	BROKE::PROTEAU

Created:	Wed Mar 02 1994
Last Modified:	Wed Jun 04 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	287
Total number of notes:	1231

231.0. "Rollback during deletion phase of a reinitialized transfer" by itvms1.it.oracle.com::ITOTA () Thu Jul 25 1996 13:11

	Hi,

	I've a question related to initial replication transfer 
	behavior.

	We experienced a problem doing a reinit on an already executed 
	transfer.

	An error occured during the initial data deletion phase, so the
	transfer failed without sending new records.

	In this situation target database had some ddal tables
	with the old datas and other ones with no datas.

	My question is :

	if something fails during deletion phase Data Distributor 
	doesn't rollback this deletion ( to rollback all records
	deletion )?

	Thanks	a lot,

				Ivo Tota

				Oracle Turin,	Italy

T.R Title User Personal
Name Date Lines

231.1 No, we don't roll back the deletes BROKE::PROTEAU Jean-Claude Proteau Thu Jul 25 1996 14:59 35

T.R	Title	User	Personal Name	Date	Lines
231.1	No, we don't roll back the deletes	BROKE::PROTEAU	Jean-Claude Proteau	`Thu Jul 25 1996 14:59`	35
	Ivo, During reinitialized replication transfers and extraction transfers that are repeated to existing target databases, data deletion is performed on each table in a separate transaction. So, if a failure occurs, you can indeed end up in a state where some tables are empty and others are not. That is why, before embarking on this operation, we first set a flag in the target database's RDB$VINTAGE table (this is the table name if the target is an Rdb database). The "transfer busy" column is set to "T", meaning true, when such a transfer operation is underway. When the transfer completes successfully, the flag is set to "F", meaning false. The purpose of this is to alert users or applications that a transfer is underway and that while this state of affairs exists the target database is in an inconsistent state. I don't think it makes sense in most cases to do the deletes and then the writes in a single transaction for all tables. The size of the RUJ file and possibly the SNP files would grow quite large, and that could cause other problems. I did add an option in version 7.0 of the ROR to allow all this to be done in a single transaction, but using that option one must say "caveat emptor." One of the reasons we don't delete the data and then write the new data in a single transaction is this. At one time it was true of Rdb that deleted space in a database was not reused until you disconnected from the database. That is what we do: we delete the data from all target tables, commit after each one, and then disconnect/reattach. Then we transfer the new data. Perhaps current versions of Rdb do not have this limitation, but we've had to write the replication option assuming that we could be talking to some older version of Rdb at a remote site. Claude

    
    Ivo,
    
    During reinitialized replication transfers and extraction transfers
    that are repeated to existing target databases, data deletion is
    performed on each table in a separate transaction.  So, if a failure
    occurs, you can indeed end up in a state where some tables are empty
    and others are not.
    
    That is why, before embarking on this operation, we first set a flag in
    the target database's RDB$VINTAGE table (this is the table name if the
    target is an Rdb database). The "transfer busy" column is set to "T",
    meaning true, when such a transfer operation is underway.  When the
    transfer completes successfully, the flag is set to "F", meaning false.
    The purpose of this is to alert users or applications that a transfer
    is underway and that while this state of affairs exists the target
    database is in an inconsistent state.
    
    I don't think it makes sense in most cases to do the deletes and then
    the writes in a single transaction for all tables.  The size of the RUJ
    file and possibly the SNP files would grow quite large, and that could
    cause other problems.  I did add an option in version 7.0 of the ROR to
    allow all this to be done in a single transaction, but using that
    option one must say "caveat emptor."
    
    One of the reasons we don't delete the data and then write the new data
    in a single transaction is this.  At one time it was true of Rdb that
    deleted space in a database was not reused until you disconnected from
    the database.  That is what we do:  we delete the data from all target
    tables, commit after each one, and then disconnect/reattach.  Then we
    transfer the new data.  Perhaps current versions of Rdb do not have
    this limitation, but we've had to write the replication option assuming
    that we could be talking to some older version of Rdb at a remote site.
    
    Claude