[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

229.0. "RDB-E-NO_DUP again" by NLVMS3::ADRIEL () Fri Jul 19 1996 12:06

    
    Hi,
    
    Oracle Rdb V6.1 ECO 2
    Data Distr. V6.0-0                      
    
    A customer encountered the same problem as described in # 121 of this
    notesfile.
    This means he got :DDAL-E-RDBERR, database error detected,
                       DDAL-E-SUPP, RDB-E-NO_DUP, index value already exist;
                       duplicates not allowed for DDAL$DBKEY_INDEX_9
    
    We provided him the workaround mentioned in #121 namely drop/recreate
    the transfer and hopefully this will not happen again.
    It's not possible to get a copy of source/target database (classified
    data) in order to reproduce the problem.
    By reading #121 I understand what the cause is of this error message
    (delete on source not applied in RDB$CHANGES, hence record not deleted
     target) but it's not clear to me whether this 'problem' should be
    fixed now.
    Rdb V6.1 ECO 1 mentions a fix for possible RDB$CHANGES corruptions.
    Is this related ?
    
    thanks in advance,
    
    Adri van Driel
    Oracle Rdb support
    The Netherlands
T.RTitleUserPersonal
Name		DateLines
229.1I think it does fix that problemBROKE::PROTEAUJean-Claude ProteauFri Jul 19 1996 13:244
    
    Yes, it is related.  I'm not 100% sure that that ECO fixes your
    customer's particular problem, but I think the odds are pretty good
    that it does.
229.2already using ECO 2 NLVMS3::ADRIELTue Jul 23 1996 08:089
    Jean-Claude,
    
    customer uses Rdb V6.1 ECO2 on both the source and target system.
    RDB$CHANGES 'corruption' fix is available (at least documented) in ECO1
    of 6.1. 
    Are there any any remaining problems in this area ??
    
    
    Adri
229.3HmmmmmmmBROKE::PROTEAUJean-Claude ProteauWed Jul 24 1996 08:4317
    
    I was only aware of one Rdb change in recent years that fixed
    corruption problems in the RDB$CHANGES table.  We have no open problem
    reports of such corruptions from other customers, so I assume that that
    fix really did take care of the problem.  Was it actually in ECO 1?  I
    don't know.  I suggest you post a note in the Rdb notes conference to
    get someone to confirm it.
    
    Ah, wait a minute.  I had a conversation with someone recently who
    expplained that the problem is not really fixed.  That is, the problem
    is explained and the customer application is supposed to behave a
    certain way to avoid the problem.  I think the writeup might a little
    less than clear on this, at least based on that conversation I had.
    I'll try to locate the person I talked to and ask him/her to post a
    reply here.
    
    Claude
229.4See section 2.2.12 of Rdb 6.0A release notesBROKE::BITHERWed Jul 24 1996 10:2850
Hi Adri,

There is a fix to rdb$changes mentioned in the Rdb 6.0A and Rdb 6.1 ECO 2 
release notes however, the errors you report in the base note are not
specifically mentioned.  But hopefully this will help clarify things.
The "fix" was to actually report an error under certain conditions rather 
than have it go undetected and cause the replication database to be wrong.

From the Release notes for Rdb 6.0A:

     2.2.12 Corruptions in table RDB$CHANGES after retrying a failed
           commit

          Table RDB$CHANGES is used by Rdb to keep track of updates
          to data that will be replicated to another Rdb database
          by DEC Data Distributor. Occasionally that table would
          become corrupt, resulting in DDD copy processes failing
          with various errors (%DDAL-E-INVLOGTYP, %DDAL-E-INVLOGCLA,
          %DDAL-E-PREMATUREEOF, etc).

          Corruptions only happened if a COMMIT statement failed
          (typically because of a lock conflict or deadlock), and the
          application would retry the commit instead of aborting.

          If a transaction updates data subjected to replication by
          the Data Distributor, and the commit of that transaction
          fails with a deadlock, then do not retry the commit.
          Instead, rollback the transaction and restart it entirely.


From Rdb note 4131:

"The behaviour of older versions of Rdb was to not write the transaction
 to RDB$CHANGES after a COMMIT after a DEADLOCK (at least some of the
 time). No error was produced, but the replication database would be
 wrong. Returning an error is an improvement."


This same "fix" is in ECO 2 for Rdb 6.1.  However, the documentation does
not mention the workaround, that is, to rollback after a deadlock condition
occurs.  This has been noted as a documentation error.

Additionally, on page 10-32 of the Guide to SQL Programming mentions
to rollback when you get a deadlock error.  Prior to Rdb 6.1-02 and 6.0A,
if you didn't follow this advice, no error would be reported
and the replication table could possibly be inconsistent with the source
table.

Hope this helps, 
Diane