Conference orarep::nomahs::dec_data_distributor

    
    One time during the last three weeks, we've seen this error at
    Dagab. Next time it occurs we'll send the files requested in .1
    to Oracle.
    
    Claude, could You explain a bit more on how DDAL finds out about
    this problem ?
    
    From reading the error message description I get the impression that
    a 'commit' record is missing in RDB$CHANGES table.
    
    Once a INVLOGTRN has appeared, every subsequent transfer is aborted
    with that error message, regradless of what the transfer contains.
    
    Is there  a global 'corrupt' flag, marking RDB$CHANGES as invalid or
    does all transfer processes read the same records from the RDB$CHANGES
    table ?
    (My novice understanding is that a copy process should only read the
    records from rdb$changes wich are relevant to the table it is
    replicating)
    
    Could You please clarify ?
    
    Release notes to 6.0-11 says in one section that SQL would hang
    waiting for a completion message from the transfer monitor.....
    Could this be a cause to get the INVLOGTRN error ?
    
    Regards
    
    Stefan

    Re: .-1
    
>    Once a INVLOGTRN has appeared, every subsequent transfer is aborted
>    with that error message, regradless of what the transfer contains.
>   
>    Is there  a global 'corrupt' flag, marking RDB$CHANGES as invalid or
>    does all transfer processes read the same records from the RDB$CHANGES
>    table ?
>    (My novice understanding is that a copy process should only read the
>    records from rdb$changes wich are relevant to the table it is
>    replicating)

Each transfer must read through all the records in the RDB$CHANGES table
and decide for itself if the record applies.  The records are not marked in
any way to say which transfers they apply to.  That's why once a corruption
occurs, all transfers are affected.
   
>    Release notes to 6.0-11 says in one section that SQL would hang
>    waiting for a completion message from the transfer monitor.....
>    Could this be a cause to get the INVLOGTRN error ?

No, I don't think this is the reason.  The most likely cause is that one
of the customer applications got a deadlock in the source database.  Instead
of rolling back the transaction, the application did a commit.  There is
something about this in the Rdb 6.0, 6.1 and 7.0 release notes.

    
    In order to research this problem further, we would like to obtain a
    copy of a source database in which the RDB$CHANGES table appears to be
    corrupt.  We'ld also need the after image journal files to go with it.
    Please respond if you have such evidence.

    
    Thanks for the explaination Claude. Currently we don't have any
    corrupt database (it's been restored to a proper state). 
    When (or rahter if) the problem occurs again, we'll make sure to
    save the source database. In that case You'll get a 
    	* a correct full database backup
    	* the AIJ's containing the transactions leading to the 
          corrupt database situation.
    
    Regards
    
    Stefan

 The error occured again last night so now the customer will be
 able to get the files requested.

 Stefan

    Stefan,
    
    We have been researching the INVLOGTRN error for a customer in the USA.
    We have an idea what is happening, but we need to figure out what to
    do.  It will require software changes in Replication Option and in Rdb
    most likely.
    
    Would you please find out from your customer if LOCK TIMEOUT is
    enabled for the source database either as a logical name or as a
    database option?
    
    Claude