Conference orarep::nomahs::dec_data_distributor

263.0. "DDAL-E-BADDBKSTO" by BROKE::GREEN () Thu Jan 16 1997 14:38

I've got a customer that's getting DDAL-E-BADDBKSTO running a replication 
update transfer.  Currently the transfer is suspended because of this.  The
customer says that this is an insert into his source db, and that the row
does not exist in the target table.  The row does exist in the source db.
I know of no way to verify that there isn't a target ddal$dbkey column value 
equal to this source dbkey value, but this target column should allow for 
duplicates anyway right?   This is a /with_no_delete transfer so there must
be rows in the target where ddal$dbkey columns contain null values.

This customer already has the DDD dumper utility so we have the ability to 
analyze RDB$CHANGES data if necessary.

What kind of conditions might cause this error?

Thanks as always,
Don
-------------------------------------------------------------------------

Subj:	Tar 9839662.5

$ SET VERIFY
$ SHOW = "SHOW"
$ RUN = "RUN"
$ LOGOUT = "LOGOUT"
$ SHOW PROCESS 

15-JAN-1997 13:24:44.49   User: SYSTEM           Process ID:   0000FAC3
                          Node: HQ               Process name: "DDAL_COPY_01   "

Terminal:           MBA9357:
User Identifier:    [SYSTEM]
Base priority:      4
Default file spec:  SYS$SYSROOT:[SYSMGR]
$ DEFINE DDAL$CP_CONTINUE "SUCCESS"
$ DEFINE/TRANS=TERMINAL DDAL$TRANSFER_NAME HQ_MRS_DAILY_SALES_TABLE_XFER
$ DDAL$CP_ACTION :== U
$ DDAL$CP_RETRY_ITERATION == 00
$ RUN DDAL$COPY_PROCESS

Product version:	DEC Data Distributor V6.0-11

----- 15-JAN-1997 13:24:44.85 ----- Process         -------------------------
Process name:  DDAL_COPY_01                  Priority:  5                       
Username:  SYSTEM                            UIC:  [SYSTEM]                     
Nodename:  HQ                                PID:  0000FAC3                     
Privileges currently enabled:
    CMKRNL, CMEXEC, SYSNAM, GRPNAM, ALLSPOOL, DETACH, DIAGNOSE, LOG_IO, GROUP, 
    ACNT, PRMCEB, PRMMBX, PSWAPM, ALTPRI, SETPRV, TMPMBX, WORLD, MOUNT, OPER, 
    EXQUOTA, NETMBX, VOLPRO, PHY_IO, BUGCHK, PRMGBL, SYSGBL, PFNMAP, SHMEM, 
    SYSPRV, BYPASS, SYSLCK, SHARE, UPGRADE, DOWNGRADE, GRPPRV, READALL, 
    SECURITY

Image privileges:
    SYSPRV, BYPASS, SYSLCK, SECURITY

Image name:
    HQ$DKF0:[SYS0.SYSCOMMON.][SYSEXE]DDAL$COPY_PROCESS.EXE

Transfer database = DISK$WSF_USER:[DDAL]DDAL$TR_DB
Transfer name     = HQ_MRS_DAILY_SALES_TABLE_XFER  
Transfer option   = U (Replication update transfer)

13:24:44  %DDAL-I-READTRDEF, reading the transfer definition from the transfer database
13:24:46  %DDAL-I-ATTACHSDB, attaching to source database POS_PROD:[DB]POSDB_PROD_HQ.RDB
13:24:46  %DDAL-I-ATTACHTDB, attaching to target database MRS::MRS_COMMON:[DB]MRSDB_DATABASE.RDB
13:24:47  %DDAL-I-STADATTRM, starting data transfer/modification
----- 15-JAN-1997 13:29:42.76 ----- Error           -------------------------
%DDAL-E-BADDBKSTO, store to the destination database failed (relation
 "TERMINAL_SALES_DATE" DBKEY "004900003BC00001")

$ LOGOUT
  SYSTEM       job terminated at 15-JAN-1997 13:29:43.23

  Accounting information:
  Buffered I/O count:             321         Peak working set size:  50000
  Direct I/O count:             98430         Peak page file size:   119248
  Page faults:                  81262         Mounted volumes:            0
  Charged CPU time:           0 00:03:20.97   Elapsed time:     0 00:04:59.07

    
    It has nothing to do with duplicate index values.  If it did, they
    would have gotten a message explicitly to that effect.
    
    I looked at the ROR logic that generates this error message.  In order
    to perform inserts, updates and deletes, ROR compiles one query in the
    target database and starts the query by sending information to the
    target database system to process the request.  Whenever a point is
    reached in the request processing where information is supposed to be
    sent from the database system back to the ROR program, ROR is supposed
    to do a read of that information.  It's a half-duplex conversation
    between the two.  When one does a send, the other is supposed to do a
    read, and vice versa.  At some point, both were doing a send (or a
    receive).  This is called a request synchronization error.  That's the
    error ROR got.  It spit out the BADDBKSTO message to indicate that when
    it tried to do an insert, it got the RDB$_REQ_SYNC error.
    
    How can a request sync error occur and what does this mean?  I can't
    think of any legitimate cause for such an error.  It has to be a
    software bug somewhere.
    
    The only way for the customer to get out of this bind is to REINITIALIZE
    the transfer and to restart it.  Since it is an archive transfer, the
    live data in the target database will be erased and replaced with the
    current live data from the source database.  Then the incremental
    transfers can continue.  Before doing so, I suggest they run the dumper
    utility to look for DELETES that have been made in the source database. 
    They'll have to perform those deletes by hand in the target.  That's
    because the copy process can't get beyond the error it is now seeing (I
    assume they've tried to rerun the update transfer and keep getting the
    baddbksto error).  Doing the deletes by hand means setting the
    DDAL$DBKEY column to null in the target database for each row deleted
    in the source.

    Thanks Claude.