[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

218.0. "Performance Impact" by ORAREP::CHEFS::FAGG_L () Fri May 31 1996 05:25

    Thanks for your prompt response to my network capacity questions. 
    
    Now for some queries on the performance impact of using DDD.
    
    I understand that if you set up data distributor to do replication 
    transfers, there is a performance overhead on the source database 
    because it has to record changes when the database is updated. Is it 
    safe to assume that this performance overhead only applies to 
    transactions which update tables which are being replicated, and not to 
    other parts of the database?
    
    Also with replication transfers, I understand that data distributor 
    requires exclusive access to the database to get started, and to ensure 
    data consistency. For what sort of time is this exclusive access 
    required, and does data distributor ensure exlusive access itself, or 
    does this have to be done externally?
    
    Thanks in advance
    Lesley Fagg
       
    
    
T.RTitleUserPersonal
Name
DateLines
218.1AnswersBROKE::PROTEAUJean-Claude ProteauFri May 31 1996 10:1742
Lesley,

>    I understand that if you set up data distributor to do replication 
>    transfers, there is a performance overhead on the source database 
>    because it has to record changes when the database is updated. Is it 
>    safe to assume that this performance overhead only applies to 
>    transactions which update tables which are being replicated, and not to 
>    other parts of the database?

Yes and no.  If at a given time you have only transactions operating on non-
replicated tables, the overhead is minimal.  Rdb must do some checking to see
if the transaction is touching any of the replicated tables.  That checking
should have a negligible impact on performance.

If you have both types of transaction executing concurrently, those that don't
touch the replicated tables may still experience some interference from those
that do.  That's because both need to update information in the system tables,
such as cardinality.  For the Replication Option for Rdb (aka Data Distributor)
6.0 (the current shipping version), the replication changes are written into
a table that resides in the RDB$SYSTEM storage area.  Once Rdb 7.0 is released,
you'll be able to move this table to its own storage area, reducing the impact
on performance to update transactions.

>    Also with replication transfers, I understand that data distributor 
>    requires exclusive access to the database to get started, and to ensure 
>    data consistency. For what sort of time is this exclusive access 
>    required, and does data distributor ensure exlusive access itself, or 
>    does this have to be done externally?

Data Distributor insures exclusive access itself.  That is, if it finds it
can't gain exclusive access, it goes to sleep for a bit and tried again until
it finally gets through.

Exclusive access is needed only long enough to write the transfer definition
in the source database.  Usually this takes under a minute.  However, this has
a big impact if you have to execute several initial replication transfers in
parallel on the same source database.  For version 6.0 and earlier, initial
replication transfers in effect happen serially, not in parallel, because of
the need for exclusive access.  For version 7.0, we've added an option that
effectively allows these transfers to run in parallel.

Claude